Stream: implementers
Topic: Sanitizing narrative
nicola (RIO/SS) (Oct 19 2019 at 06:35):
FHIR spec says .narrative.div should be sanitized for html injection. From users of aidbox we learned this server behaviour is confusing people by modifying original content; different systems want different sanitization rules; we have problems with digital signatures. From design point of view doing sanitization right in place you inject foriegn html is better. Should i create an issue to discuss removal of this feature :)?
Lloyd McKenzie (Oct 19 2019 at 11:24):
I think sanitization just means you need to apply the schema rules - no buttons, scripts or other elements that contain active content. If you're doing signatures, the digital signature algorithm should handle the rest
Grahame Grieve (Oct 19 2019 at 11:39):
I'm not sure - can you describe the specific changes that are needed and why they are confusing?
Grahame Grieve (Oct 19 2019 at 11:39):
and which section exactly you are quoting?
Brian Postlethwaite (Oct 20 2019 at 00:33):
Could we suggest that there be 2 outcomes here then, a failure or correction. If the save detects active content return validation error rather than stripping it.
John Moehrke (Oct 21 2019 at 12:59):
The reason we left it vague is because the things hackers learn change over time. If we said simply "do not allow javascript", which is all we cared about originally, then we would not be recognizing that cyber-security is a risk-mitigation art that changes as the attacks change.
John Moehrke (Oct 21 2019 at 13:02):
However, any sanitization would indeed break a signature that existed on the 'un-sanitized' input. This is predictable. So, one should create a new version of the resource that has been sanitized, create a Provenance indicating the sanitization activity, and in that new Provenance include a new signature with linkage to the previous signature to show that the sanitization activity is verifiability linked to the unsanitized data.
John Moehrke (Oct 21 2019 at 13:04):
Could we suggest that there be 2 outcomes here then, a failure or correction. If the save detects active content return validation error rather than stripping it.
Good point, the sanitization activity was originally envisioned on an initial Create action; so that was also our simple world back then.
nicola (RIO/SS) (Oct 21 2019 at 13:36):
Could we suggest that there be 2 outcomes here then, a failure or correction. If the save detects active content return validation error rather than stripping it.
A validation error is better than original content modification!
John Moehrke (Oct 21 2019 at 14:19):
and an OperationOutcome can express the reason is due to unsafe content in the text html...
John Moehrke (Oct 21 2019 at 14:23):
but if you MUST import, then you need to make the content safe... which is where I recommended a version with safe content and a Provenance indicating the reason for change with signature linkage to the original signature
John Moehrke (Oct 21 2019 at 15:09):
Nicola, I know of the content on sanitizing on the security page... http://build.fhir.org/security.html#narrative
It is very specific, and would not include further removal of content that is simply not valid FHIR xhtml.
Grahame Grieve (Oct 21 2019 at 15:50):
A validation error is better than original content modification!
I am not aware of any text in the specification that suggests that content modification is a good or necessary thing
John Moehrke (Oct 21 2019 at 15:51):
That is why I pointed out the only place I know of which is the security narrative page. Which I think implies validation-error... but could be said more blunt if that helps
Michael Lawley (Oct 23 2019 at 01:34):
So let's say the content is sanitized and passes validation for the CREATE. What happens when the threat landscape shifts and the (possibly signed) and stored content is no longer safe?
John Moehrke (Oct 23 2019 at 18:26):
find those resources with bad narrative, and deal with them. Likely revising them, and keeping a Provenance record to the policy change
John Moehrke (Oct 23 2019 at 18:27):
this is not likely to be needed, as the narrative is already highly constrained. but, never say never.
Michael Lawley (Oct 23 2019 at 22:43):
I am not aware of any text in the specification that suggests that content modification is a good or necessary thing
https://www.hl7.org/fhir/updates.html ?
In particular https://www.hl7.org/fhir/updates.html#7.14
Without any other agreement between exchange partners, FHIR systems are not obligated to store and return data as it was received.
and https://www.hl7.org/fhir/updates.html#7.14.7
The SUBSETTED Security Label can be used to flag data that has had information removed.
Grahame Grieve (Oct 23 2019 at 22:56):
those suggest that it's a possible thing, and is in general no different to any content in a resource. I don't believe that these provide any reason to think that narrative modification is a good or necessary thing
Last updated: Apr 12 2022 at 19:14 UTC
