Stream: implementers
Topic: Path traversal attacks
Danielle Friend (Apr 19 2018 at 23:05):
Has anyone encountered a FHIR client, parser, API managers, etc. that will error if two sequential periods ".." are found in the FHIR url?
My question comes from someone using some sort of middleware which errors if the FHIR id contains two periods in a row ".." - as it considers it a potential path traversal security attack (even though path traversal attacks are "../")
Example read that causes the failure:
https://baseurl/Patient/Pdiq..dQID
Where Pdiq..dQID is a patient FHIR id.
I'm curious if others have come across similar checks or if this is a one off case.
Danielle Friend (Apr 19 2018 at 23:05):
Where I read about path traversal attacks: https://www.owasp.org/index.php/Path_Traversal
Grahame Grieve (Apr 20 2018 at 00:28):
it would be an error if there is a sequential period outside a search parameter value
Danielle Friend (Apr 20 2018 at 14:30):
@Grahame Grieve can you clarify? You're saying - it is valid for a search parameter to have a sequential period. If there are sequential periods elsewhere, that is not allowed.
Danielle Friend (Apr 20 2018 at 14:30):
So a read ID with sequential periods is acceptable
Łukasz Dywicki (Apr 20 2018 at 14:57):
So a read ID with sequential periods is acceptable
@Danielle Friend Path traversal attack is possible if you traverse something which can be navigated with typical path syntax. FHIR resources are not organized in hierarchy which have predictable nesting levels, in fact there is fhir server root (https://example.com/dstu3/), resource type (Patient) and its identifier (Pdiq). There is no correlation between identifier and server root so you can not move "up" from identifier value to patient. Specification defines what is proper identifier and what should be accepted, in principle switching paths usualy requires slash which will then be interpted by server to go deeper into resource (ie to fetch its historical representation) but not up.
Such kind of attack is very popular for web applications displaying resources located on the disk and in theory, somewhere out there might be a FHIR server implementation which is relying on static files. If it will not parse properly identifiers (specified after resource type) then it will be vulnerable.
However specification itself can not address such things because how identifiers are handled depends on actual provider implementation.
Lloyd McKenzie (Apr 20 2018 at 15:04):
I don't think the question was whether there's a real risk in terms of how FHIR is designed. The issue is that an implementation has decided to mitigate the risk of traversal path attacks in general by banning URLs that contain "..". So the question is whether that's going to create grief. The answer seems to be "only if you're doing a search and the value of one of your search parameters contains '..'", which seems like a pretty remote edgecase.
Danielle Friend (Apr 27 2018 at 22:13):
Exactly @Lloyd McKenzie - have you heard of any other implementations having a problem with this?
Danielle Friend (Apr 27 2018 at 22:18):
Because our FHIR patient IDs can have '..' (just as likely as having any 2 characters in a row), there will be cases where any search by patient has '..' in the search query.
Lloyd McKenzie (Apr 27 2018 at 23:03):
I haven't, but I don't generally play in circles where I would have...
Grahame Grieve (Apr 27 2018 at 23:50):
because of the way that I process paths, it will not be a problem for me. but I guess if you have a file based server, you'd need to ensure that your server either stopped checking for .. at the first ? or that you didn't create ids with a .. in them
Kevin Shekleton (May 02 2018 at 20:07):
I would expect any identifier in the URL path to be URL encoded. This includes forward slashes, etc
Grahame Grieve (May 05 2018 at 04:45):
I suspect that your expectations would often not be met. but '.' would not be escaped by any library I know
Last updated: Apr 12 2022 at 19:14 UTC
