Stream: Security and Privacy
Topic: XSS Attack
Shovan Roy (Jun 04 2020 at 05:00):
Hi All,
This is regarding FHIR resource validation and XSS attack. I would like to seek advice from the community about suggestion and recommendations on FHIR input validation on cross site scripting (XSS) attack.
For instance a client can interpret JavaScript instructions used by a threat actor to conduct a cross site scripting (XSS) attack . For example, the datatype for 'givenName' under HumanName is string and the attacker can send it as <script> somescript</script> which may blow up the portal screen when the resource is read.
I guys these rules varies from project to project but just wanted to check with the group to understand if there is any common FHIR guideline in this space
Lloyd McKenzie (Jun 04 2020 at 05:03):
@John Moehrke
Grahame Grieve (Jun 04 2020 at 07:43):
the attacker can send it as <script> somescript</script>
how would they do that?
Grahame Grieve (Jun 04 2020 at 07:44):
however: there is no conformant way to do this, and there is no way to do this that is not tested by the validator.
Grahame Grieve (Jun 04 2020 at 07:44):
one of my todo items is to add a flag to the validator so that it runs in security mode - it only enforces security related rules (very very fast compared to everything else it does)
John Moehrke (Jun 04 2020 at 12:49):
I presume you are asking about elements in FHIR Resources that can carry XHTML? http://build.fhir.org/security.html#narrative
In these cases we have limited the xhtml capabilities. http://build.fhir.org/narrative.html#security
Are you asking for advice on how to do that check in your code? That would be an implementation detail, you might find solutions in some of the open-source projects, but it would not be something that would be said in the core FHIR spec.
Shovan Roy (Jun 05 2020 at 00:22):
Grahame Grieve said:
the attacker can send it as <script> somescript</script>
how would they do that?
Hi @Grahame Grieve I will collect more information about the scenario from our project security team and provide the details.
Shovan Roy (Jun 05 2020 at 00:44):
John Moehrke said:
I presume you are asking about elements in FHIR Resources that can carry XHTML? http://build.fhir.org/security.html#narrative
In these cases we have limited the xhtml capabilities. http://build.fhir.org/narrative.html#security
Are you asking for advice on how to do that check in your code? That would be an implementation detail, you might find solutions in some of the open-source projects, but it would not be something that would be said in the core FHIR spec.
Hi @John Moehrke This can be applied at any element in a FHIR resource which is defined as String. I am trying to findout if there is generic guideline from FHIR on XSS Attack
Grahame Grieve (Jun 05 2020 at 01:49):
yes our generic guidance is: don't allow it. I don't understand this:
This can be applied at any element in a FHIR resource which is defined as String
Unless you mean, someone could be foolish enough to forget to escape a user-supplied string value when building an output html page... sure. That could happen. We can't stop stupid. I suppose it would be good to provide some attack examples
John Moehrke (Jun 05 2020 at 12:08):
@Shovan Roy I welcome a Change Request with the words you would like to see at the location you would like to see them. The specification is a work of the community, you are part of that community.
John Moehrke (Jun 05 2020 at 12:15):
I tend to think that all of these are not unique to FHIR, and are already better covered in general IT web app and API security frameworks.
Shovan Roy (Jun 08 2020 at 22:32):
Thanks @John Moehrke @Grahame Grieve
@John Moehrke I agree that "XSS Attack" is more of a general IT web app and API security topic. As I mentioned in my initial post, "XSS Attack" prevention strategy may highly vary from project to project and may not be appropriate to say something generic, but thought of verifying this with the community.
When I looked at the security page(https://www.hl7.org/fhir/security.html), I can see good degree of details provided already. For an example clarity is provided on 'Digital Signature". (Though I am unclear on how to use Provenance resource as signature of a HTTP Read in a JSON based interaction, but that's a separate topic to this one. That something I have to explore more)
I can see another point "11. Input Validation" which talks about injection attack, however clicking that link on "Input Validation" is taking me to "Narrative"
@Grahame Grieve , in our project, we are trying to ensure we block receiving information which may contain script attack (e.g.:<script> somescript</script>) before persisting in our database. I am yet to receive more details on the attack example from the project security team and I will keep you updated on this.
Grahame Grieve (Jun 08 2020 at 23:30):
the only place you can get <script> somescript</script> is in the narrative - that's why we talk about it
Vassil Peytchev (Jun 09 2020 at 00:05):
the only place you can get
<script> somescript</script>is in the narrative - that's why we talk about it
I think for the XML representation, it is the only place that passes schema validation - maybe that is a detail that may not be always obvious...
Grahame Grieve (Jun 09 2020 at 00:10):
well, I think that you can make up any kind of xml you like, but it won't be valid. The standard has to assume that the resources are valid.
Grahame Grieve (Jun 09 2020 at 00:11):
but that's why there's going to be a security checks version in the validator
Shovan Roy (Jun 09 2020 at 00:13):
In our implementation, we are using JSON. I will have to check if "lastName": "abcd<script>somescript</script>" is valid as data.
will wait for the security check version of the validator
Grahame Grieve (Jun 09 2020 at 00:18):
the validator will call that valid content, unless you apply a regex to the element in your profile. However, the fact that this contains a character sequence that is meaningful html in a plain string reminds me of this: https://xkcd.com/327/
Always escape your inputs when rendering to HTML
Grahame Grieve (Jun 09 2020 at 00:18):
.. and we didn't write this into the spec because, honestly... how could you not?
Shovan Roy (Jun 09 2020 at 00:32):
Thanks Grahame, in our implementation, since we are data hub, we don't know in what form and in which level data tampering can happen. Our source of data could be varies client systems (web based/integration system etc) who are not controlled by us. We are trying to make sure that once we receive the data, we validate it and thus the whole point of rejecting the request if it has any injection attack content. I will explore applying regex to the profile content.
Grahame Grieve (Jun 09 2020 at 04:03):
all right the next release of the validator will support the parameter -security-checks. In this mode, it will return an error if any string value has anything that looks like an HTML tag in it. Note that this check doesn't apply to xhtml, obviously, since that will contain HTML tags. Note that it already checks that there's no active content in the xhtml, and it'd be nice if your security team tried to penetrate the validator on this
Technically, for those interested, the content is considered a security risk if the string content contains any text between a < and a > that meets this regex: [a-zA-Z]\w*(((\s+)(\S)*)*)
Grahame Grieve (Jun 09 2020 at 04:03):
this is not the same as 'security checks only' - I'll work on that later
Lloyd McKenzie (Jun 09 2020 at 04:38):
Will the security checks run for default validation too - e.g. when using the publisher?
Grahame Grieve (Jun 09 2020 at 06:21):
no. Rules are different there
John Moehrke (Jun 09 2020 at 12:18):
I think that is a wrong test. This is valid string. To add a random html script check while not looking for 100% scripting languages is security-theater. Why not look for UNIX command-line script, DOS command-line script, adobe postscript script, even fonts have script (ADV200006).
John Moehrke (Jun 09 2020 at 12:19):
further you would only be finding single depth attacks. What about double escaping attacks?
John Moehrke (Jun 09 2020 at 12:20):
doing more than validating against the FHIR datatype definition may seem like a good idea, but it is something that you must do completely, while not having false-positives or false-negatives.
Grahame Grieve (Jun 09 2020 at 12:41):
Why not look for UNIX command-line script, DOS command-line script, adobe postscript script,
because no one asked. And HTML+SQL issue is 99%+ of non-movie threats
Grahame Grieve (Jun 09 2020 at 12:42):
but maybe you could explain how double escaping attacks are in scope here?
John Moehrke (Jun 09 2020 at 13:10):
my point was not to encourage you to add more tests, but rather to stop at validating purely to the datatype specification. As soon as you try to go beyond, you go over a cliff.
Lloyd McKenzie (Jun 09 2020 at 14:20):
If security validation is going to yell about an example, the publisher should yell about it too. (In part so we can check if the security validation is being over-zealous.)
Grahame Grieve (Jun 09 2020 at 19:49):
by default, the validator stops at the data type specfication
Lloyd McKenzie (Jun 09 2020 at 20:23):
For performance reasons?
Grahame Grieve (Jun 09 2020 at 20:27):
no for conformance reasons. If you want more, you have to ask for it
Lloyd McKenzie (Jun 09 2020 at 20:32):
I'm not really following. My concern is creating an implementation guide that contains an example that would trigger this security validation issue. Wouldn't we want to know if we were publishing content that was going to create a security warning? (Either because we'd done something inappropriate in the example, or because the security warning was being triggered in inappropriate circumstances.)
Lloyd McKenzie (Jun 09 2020 at 20:33):
I certainly don't expect IG authors t manually trigger validation with custom settings when they're authoring their stuff...
Grahame Grieve (Jun 09 2020 at 20:52):
umm, I was explaining why the validator defaults to conformance to the specification
Lloyd McKenzie (Jun 09 2020 at 21:34):
So the publisher could check this too?
Grahame Grieve (Jun 09 2020 at 21:52):
it could.
Lloyd McKenzie (Jun 09 2020 at 21:57):
Is there any reason why we think it shouldn't?
John Moehrke (Jun 10 2020 at 12:37):
I think there are diminishing returns to adding this kind of a check to the IG build. We don't have any evidence that an IG author is going to be including an attack like this, and if they were they would just escape it around the validator. Thus we would just be slowing down 100% of legitimate IG publishing for the sake of the non-existent chance.
Lloyd McKenzie (Jun 10 2020 at 14:50):
I'm actually more interested in IGs containing tags in text that are there for legitimate reason and making sure our validation process doesn't yell about them.
Grahame Grieve (Jun 10 2020 at 20:02):
that'll still crop up as a hint not an error
Grahame Grieve (Jun 10 2020 at 20:19):
actually, maybe the most useful thing I could do would be autogenerate a set resources that include exploit text as part of generating an IG
Lloyd McKenzie (Jun 10 2020 at 21:39):
I don't understand what you're proposing...
Last updated: Apr 12 2022 at 19:14 UTC
