Also make sure you don't follow 301/302, or someone can set up a http link which redirects to file:// .
If your code accepts URIs as input, filter out “file://”
31–40 of 161 posts
Re: If your code accepts URIs as input, filter out “file://”
#32Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
Exactly. Whitelist only trusted schemes, do not wait to blacklist untrusted. I wrote the Go HTML sanitizer: https://github.com/microcosm-cc/bluemonday and have a rule for user generated (untrusted) content that basically does whitelist just the things that one can trust: https://github.com/microcosm-cc/bluemonday/blob/master/helpe... That states that URIs must be: 1. Parseable 2. Relative 3. Or one of: mailto http ht…
Might want to add tel to the whitelist. It works in roughly the same way as mailto but interfaces with telephone apps instead of email clients.
Re: If your code accepts URIs as input, filter out “file://”
#33Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
Can we please stop trying to enumerate badness[1]? When parsing input it is possible to define the set of valid input, not all possible invalid inputs.
Also, anybody accepting input from an untrusted source (such as anything from a network or the user) that isn't verifying the data with a formal recognizer is doing it wrong[2]. Instead of writing another weird machine, guarantee that the input is valid with a parser generator (or whatever) recognize the input and drop anything even slightly invalid.
[1] http://www.ranum.com/security/computer_security/editorials/d...
[2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit...
Re: If your code accepts URIs as input, filter out “file://”
#34Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
Just as a concrete example of why this is the right approach, there is at least one enterprise CMS that installs a custom protocol handler that can be use to access any object stored in the CMS if you know or can guess/discover its URI. It's worth assuming there are others that you don't know about.
The other advantage of the whitelist approach here is that you know exactly which protocols you think you support and can design tests for them. For instance to support https, you'll want to check you have decent error handling and do not silently accept potential MitM certificates.
Re: If your code accepts URIs as input, filter out “file://”
#35Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
> filtering out anything thats not letters, numbers, slash or dot is probably a good idea.
This is highly non-trivial once you realize that the world speaks more than ASCII and things like http://www.xn--n3h.net exist.
Re: If your code accepts URIs as input, filter out “file://”
#36Earlier quoted context omitted.
https://en.m.wikipedia.org/wiki/Robustness_principle
> https://en.m.wikipedia.org/wiki/Robustness_principle You need to be careful of where you place the emphasis on that, though: Be - liberal - in what you accept. vs Be liberal in what you - accept -.
Be liberal in a well-defined way in what you accept. Accepting a variety of input is fine, as long as it is formally defined and recognized. The robustness principle is not an excuse to be sloppy with the input.
(why? see [2] in my other post, "The Science of Insecurity")
Re: If your code accepts URIs as input, filter out “file://”
#37Earlier quoted context omitted.
> https://en.m.wikipedia.org/wiki/Robustness_principle You need to be careful of where you place the emphasis on that, though: Be - liberal - in what you accept. vs Be liberal in what you - accept -.
Right - you accept URIs. That's fairly liberal. > Be conservative in what you do However, you only handle specific schemes and ignore the rest.
Yeah, apologies, I was being pretty petty.
My hopefully-better-expressed point is that it's easy to interpret the robustness principle in different ways, some of which lead to better code, and some of which... don't.
Re: If your code accepts URIs as input, filter out “file://”
#38Wrong way around: only allow http:// and https:// (and generally filtering out anything thats not letters, numbers, slash or dot is probably a good idea. Remove any sequences of more than one slash or dot.
> filtering out anything thats not letters, numbers, slash or dot is probably a good idea. This is highly non-trivial once you realize that the world speaks more than ASCII and things like http://www.xn--n3h.net exist.
>This is highly non-trivial once you realize that the world speaks more than ASCII and things like http://www.xn--n3h.net exist.
I was under the impression that requests to and from the server still used ASCII?
That is, the server would see a host header as this:
Host: www.xn--n3h.net
Host: www.[snowman icon].net
Edit for completeness: in my server logs, the GET request for a /[snowman icon] URL is url encoded to
GET /%E2%98%83 HTTP/1.1Re: If your code accepts URIs as input, filter out “file://”
#39"Despite reporting the problem to the author on Friday, and following up the report via Twitter this has not yet been fixed, but after four days I assume I'm not alone in spotting this." Giving someone a weekend to fix something doesn't exactly sound like responsible disclosure. I understand if you get excited because you found a flaw but if you find something like this please be more responsible with publishing your…
Well, I found the same by pure chance before reading this article, and I suspect many more in the HN crowd did.
If already half a dozen people on HN report they’ve found it and emailed the person about it, it’s likely it’s too late for responsible disclosure.
Re: If your code accepts URIs as input, filter out “file://”
#40Also make sure you don't follow 301/302, or someone can set up a http link which redirects to file:// .
Or just, when following 301/302, call the same function again – which then validates the link completely again.