Stream: implementers
Topic: URL Parsing
Kevin Shekleton (Jan 31 2018 at 17:38):
I mentioned this in a FHIR-I meeting today and several folks expressed interest in this. So, posting this for whomever is interested. :-)
Here are the materials for the talk I saw from Orange Tsai at the DefCon security conference last July 2017. In his talk, Orange Tsai illustrated just how broken URL parsers are in every major language and library. One of the root problems is the complexity of the URL RFC(s!) and how the RFCs have ambiguity resulting in implementation differences/gaps.
Blog post where he talks about chaining several URL parsing vulnerabilities to smuggle a remote code exploit to root a Github.com backend server:
http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html
Video of Orange Tsai's talk (including video of his exploit):
https://www.youtube.com/watch?v=D1S-G8rJrEk
John Moehrke (Jan 31 2018 at 18:08):
We have added specific security considerations to the FHIR spec before... (xml inclusion of script)... should this be similarly pointed to? If so, how would you describe it? I ask you for that description as you best represent our FHIR 'reader', so you might be best able to describe it... Security wg would clearly fix your wording if it isn't good.
Michel Rutten (Jan 31 2018 at 18:12):
Very interesting, thank you for sharing this Kevin!
Kevin Shekleton (Jan 31 2018 at 18:23):
@John Moehrke - While we could post a note about this, I feel the same could be said with lots of other vulnerability categories. Are you thinking this one is an especially important/unique consideration to call out?
Grahame Grieve (Jan 31 2018 at 18:27):
@John Moehrke you should make a task to add a note about this where we talk about XML. @Kevin Shekleton what else should we note?
Lloyd McKenzie (Jan 31 2018 at 19:02):
Presumably we should ensure that all of the reference servers address this
Kevin Shekleton (Jan 31 2018 at 20:30):
@Lloyd McKenzie - The tricky part is that one of the messages of Orange Tsai's work is that the standard, widely used URL parsers are broken in subtle ways...largely due to the inherent complexities in the possibilities in URLs. So, references servers really would be hard pressed to do anything as either a) they are using these potentially vulnerable libraries and b) writing your own URL parser will have the same bugs all of the other libraries have. :stuck_out_tongue:
We are discussing in the FHIR-I/Sec mtg now about perhaps establishing a rubric or criteria for when a particular security topic or risk should be documented.
Personally, I think we should only address security risks that are directly actionable by implementers or have specific or unique implications to FHIR. I feel like this particular issue is broader. But, I haven't been thinking too deeply about this.
Michel Rutten (Jan 31 2018 at 20:41):
Is there a list of malcrafted url's that could help server builder to at least identify risks, and potentially try to mitigate?
Grahame Grieve (Jan 31 2018 at 20:42):
https://www.lookout.net/test/url/
Michel Rutten (Jan 31 2018 at 20:44):
Cool, thanks
Michel Rutten (Jan 31 2018 at 20:44):
@Christiaan Knaap please take note
Grahame Grieve (Feb 01 2018 at 17:15):
I've been playing with turning the examples into unit tests.. but really, most of them are not flaws in URL parsing so much as URL processing - much more difficult to unit test
Kevin Shekleton (Feb 01 2018 at 17:37):
Good point. It is a bit of both
Last updated: Apr 12 2022 at 19:14 UTC
