This is no different than failing to validate input parameters, and letting an attacker take a dump of your database. A service connecting to a remote location should have checked the URI scheme.
If your code accepts URIs as input, filter out “file://”
81–90 of 161 posts
Re: If your code accepts URIs as input, filter out “file://”
#82The u= parameter in the OPs article also is vulnerable (even if http/https are whitelisted, file:// blacklisted, etc) to the #10 vulnerability on the OWASP Top Ten 2013 list, namely Unvalidated Rediredcts and Forwards. https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_...
I can easily get you to click the link to drive-by malware, adult sites, pharma, phishing, etc. because the site doesn't ensure where the link is actually going to.
Re: If your code accepts URIs as input, filter out “file://”
#83Earlier quoted context omitted.
I certainly am weary of bug branding...
I only started seeing this weary/wary misspelling in recent years. They don't sound alike, and they don't really look alike. Did cell phone spellcheckers give rise to this one?
I think that this one:
> I certainly am weary of bug branding...
means exactly what it says: the poster is tired of, not apprehensive about, it.
EDIT: Oops, sorry, I guess you meant your grandparent's
> Also be weary of imagetragick-type bugs
For what it's worth, I have seen this as a genuine confusion, not typo, of non-native English speakers. (Think, for example, of 'compose' versus 'comprise', and even of 'who' versus 'whom', which neither sound nor look alike, but which are frequently confused even by native speakers.)
Re: If your code accepts URIs as input, filter out “file://”
#84Earlier quoted context omitted.
guarantee that the input is valid with a parser generator OK, that works really well... until you learn how much non-RFC-specified behavior is built in to web browsers. Simply building a parser to the RFC will leave you wide open to all sorts of nastiness! The is_safe_url() internal function in Django is a bit of a historical dive into things we've learned about how browsers interpret (or, arguably, misinterpret) var…
> non-RFC-specified behavior I never said anything about limiting the parser to what's defined in an RFC. The acceptable input to "quirks mode" is just another (non-RFC) grammar, which still needs to be defined and validated.
Then I do wish you luck, but I don't think you'll ever be able to produce a suitably complete grammar since parts of it will require knowledge of undocumented proprietary internals of Internet Explorer.
Hence we scrape along doing our best with what we can figure out from observing behavior and collecting bug reports. But even with that, is_safe_url() is one of the most prone-to-security-issues functions in Django's codebase.
Re: If your code accepts URIs as input, filter out “file://”
#85Earlier 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.
Isn't that missing the point of the robustness principle, which is more related to say, networking, and accepting things that aren't strictly to RFC spec, but when sending things, you match the spec to the letter?
Re: If your code accepts URIs as input, filter out “file://”
#86Earlier quoted context omitted.
https://en.m.wikipedia.org/wiki/Robustness_principle
It should be pointed out that while this was once accepted as gospel, it has been coming under a lot of fire lately. HTML, once arguably the flagship of this principle and its greatest success (I say "arguably" because you can also argue TCP), no longer works this way. HTML5 specifies how bad input should be handled, and if you accept that "how to process nominally bad input" as the "real" standard, HTML is now stric…
> HTML5 specifies how bad input should be handled, and if you accept that "how to process nominally bad input" as the "real" standard, HTML is now strict in what it accepts.
HTML5 is a shining example of "be liberal in what you accept", and its improved documentation of how to handle bad input (note that bad input is still permitted!) greatly expands HTML's "be conservative in what you send". I think HTML5 is a perfect example of the Robustness Principle.
Re: If your code accepts URIs as input, filter out “file://”
#87Earlier quoted context omitted.
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…
I agree with the approach. However, specific examples of different badnesses are useful for testing the final product.
I.e. move enumeration of badness from code into test-cases.
Re: If your code accepts URIs as input, filter out “file://”
#88Also make sure you don't follow 301/302, or someone can set up a http link which redirects to file:// .
Wait, what? Really!? Can this be used to get shell access somehow? I'm having trouble figuring out how you go from Chrome opening a remote file to _bad thing happens_.
Re: If your code accepts URIs as input, filter out “file://”
#89Earlier quoted context omitted.
Right - you accept URIs. That's fairly liberal. > Be conservative in what you do However, you only handle specific schemes and ignore the rest.
Isn't that missing the point of the robustness principle, which is more related to say, networking, and accepting things that aren't strictly to RFC spec, but when sending things, you match the spec to the letter?
I've found it useful in software design in general.
Re: If your code accepts URIs as input, filter out “file://”
#90Wrong 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…
Exception: passwords. Do not enumerate goodness when accepting a new password.