Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If your code accepts URIs as input, filter out “file://”

blog.steve.fi

Post reply on HN
Print view View original

141–150 of 161 posts

Re: If your code accepts URIs as input, filter out “file://”

#141

Post by ajanuary »

idbehold wrote: post #112
byuu wrote: post #50

Also be very wary of ../ or possibly ..\ in URIs. Say you have http://example.org/download?file=release/software-1.0.zip so that you can log download statistics. If you just fetch GET["download"] and return it, you're gonna have a bad time if they try http://example.org/download?file=../../../../../etc/hosts (browsers strip it out automatically, but it's easy enough to type such a request into a telnet session.) And…

I've done something similar in node to ensure URIs like those cannot walk up past a base directory: function saferesolve(base, target) { var targetPath = '.' + path.posix.normalize('/' + target) return path.posix.resolve(base, targetPath) } saferesolve("./datasource", "a/b") === "./datasource/a/b" saferesolve("./datasource", "a/b/../c") === "./datasource/a/c" saferesolve("./datasource", "../..") === "./datasource" sa…

I've done something similar in Java, though more focused on file paths https://github.com/aJanuary/basepath

Re: If your code accepts URIs as input, filter out “file://”

#142

Post by int_19h »

I think handling (rejecting) this in the libraries that handle URIs would be the wrong fix. While this is a vulnerability in a web app, it is a handy feature in an app that runs locally, and the library doesn't really know the context. It's up to the app to filter the URLs according to its isolation requirements.

Re: If your code accepts URIs as input, filter out “file://”

#143

Post by pg_is_a_butt »

23andwalnut wrote: post #98
kuschku wrote: post #71

Earlier quoted context omitted.

The issue is more that if so many people have already found it, who else has?

Disclosing it publicly before it's been fixed only increases the number.

not disclosing it publicly when it's likely already known, only increases the number of victims as lack of pressure doesn't get the issue fixed immediately.

am i doing it right?

if you want to offer always on public services, then you have to have an always on company. always.

Re: If your code accepts URIs as input, filter out “file://”

#144

Post by eridius »

zrm wrote: post #121
pdkl95 wrote: post #33

Earlier 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…

> Can we please stop trying to enumerate badness [1]? No. Because we don't know what goodness looks like. The world can be separated into good, bad and unknown. If you classify anything unknown as bad then anything new is DOA. People aren't going to add new things to the whitelist before they're popular which means they can never become popular. It's stasis. But people do that anyway, which makes the good guys have t…

If a new URL scheme shows up that actually makes sense to be used with sites like these, then these sites will have to be updated anyway to support that scheme, at which point you can easily whitelist it.

Re: If your code accepts URIs as input, filter out “file://”

#145

Post by dragonwriter »

eridius wrote: post #144
zrm wrote: post #121

Earlier quoted context omitted.

> Can we please stop trying to enumerate badness [1]? No. Because we don't know what goodness looks like. The world can be separated into good, bad and unknown. If you classify anything unknown as bad then anything new is DOA. People aren't going to add new things to the whitelist before they're popular which means they can never become popular. It's stasis. But people do that anyway, which makes the good guys have t…

If a new URL scheme shows up that actually makes sense to be used with sites like these, then these sites will have to be updated anyway to support that scheme, at which point you can easily whitelist it.

> If a new URL scheme shows up that actually makes sense to be used with sites like these, then these sites will have to be updated anyway to support that scheme, at which point you can easily whitelist it.

If you aren't using a whitelist, and the URL handling is relying on the underlying platform and not application code, than a new URL scheme takes no changes to the application code.

Re: If your code accepts URIs as input, filter out “file://”

#146

Post by eridius »

dragonwriter wrote: post #145
eridius wrote: post #144

Earlier quoted context omitted.

If a new URL scheme shows up that actually makes sense to be used with sites like these, then these sites will have to be updated anyway to support that scheme, at which point you can easily whitelist it.

> If a new URL scheme shows up that actually makes sense to be used with sites like these, then these sites will have to be updated anyway to support that scheme, at which point you can easily whitelist it. If you aren't using a whitelist, and the URL handling is relying on the underlying platform and not application code, than a new URL scheme takes no changes to the application code.

That's precisely the danger that the whitelist is supposed to guard against. Just because the underlying platform can handle a URL type doesn't mean that it's safe for your software to accept that URL type. Using a blacklist instead of a whitelist means that what should be a safe update of the OS your software runs on can suddenly cause a security vulnerability in your app, even if you properly blacklisted every potentially-vulnerable URL scheme at the time your software was written.

Re: If your code accepts URIs as input, filter out “file://”

#147

Post by dragonwriter »

eridius wrote: post #146
dragonwriter wrote: post #145

Earlier quoted context omitted.

> If a new URL scheme shows up that actually makes sense to be used with sites like these, then these sites will have to be updated anyway to support that scheme, at which point you can easily whitelist it. If you aren't using a whitelist, and the URL handling is relying on the underlying platform and not application code, than a new URL scheme takes no changes to the application code.

That's precisely the danger that the whitelist is supposed to guard against. Just because the underlying platform can handle a URL type doesn't mean that it's safe for your software to accept that URL type. Using a blacklist instead of a whitelist means that what should be a safe update of the OS your software runs on can suddenly cause a security vulnerability in your app, even if you properly blacklisted every pote…

> That's precisely the danger that the whitelist is supposed to guard against.

Be that as it may, the suggestion that there would be a need to update the code independent of the whitelist, and that the whitelist could be updated at the same time, is incorrect. The need to update is a cost of the choice to use a whitelist (maybe a justifiable cost, but certainly a cost.)

Re: If your code accepts URIs as input, filter out “file://”

#148

Post by eridius »

dragonwriter wrote: post #147
eridius wrote: post #146

Earlier quoted context omitted.

That's precisely the danger that the whitelist is supposed to guard against. Just because the underlying platform can handle a URL type doesn't mean that it's safe for your software to accept that URL type. Using a blacklist instead of a whitelist means that what should be a safe update of the OS your software runs on can suddenly cause a security vulnerability in your app, even if you properly blacklisted every pote…

> That's precisely the danger that the whitelist is supposed to guard against. Be that as it may, the suggestion that there would be a need to update the code independent of the whitelist, and that the whitelist could be updated at the same time, is incorrect. The need to update is a cost of the choice to use a whitelist (maybe a justifiable cost, but certainly a cost.)

No, it's the cost of choosing to support a new URL scheme. You have to validate your app to make sure it makes sense to allow the use of the new URL scheme anyway, updating a whitelist should be pretty trivial. And you only pay the cost if a new URL scheme shows up that you actually want to support. Meanwhile the blacklist approach not only exposes you to security vulnerabilities, but imposes a cost every time the underlying platform adds support for a new URL type because now you have to update your blacklist to block it.

Re: If your code accepts URIs as input, filter out “file://”

#149

Post by dragonwriter »

eridius wrote: post #148
dragonwriter wrote: post #147

Earlier quoted context omitted.

> That's precisely the danger that the whitelist is supposed to guard against. Be that as it may, the suggestion that there would be a need to update the code independent of the whitelist, and that the whitelist could be updated at the same time, is incorrect. The need to update is a cost of the choice to use a whitelist (maybe a justifiable cost, but certainly a cost.)

No, it's the cost of choosing to support a new URL scheme. You have to validate your app to make sure it makes sense to allow the use of the new URL scheme anyway, updating a whitelist should be pretty trivial. And you only pay the cost if a new URL scheme shows up that you actually want to support. Meanwhile the blacklist approach not only exposes you to security vulnerabilities, but imposes a cost every time the un…

> You have to validate your app to make sure it makes sense to allow the use of the new URL scheme anyway

No, you don't, necessarily. A URL is a means of locating a resource; if your app makes sense for the kinds of resources and representations it handles independently of their origin, you don't need to validate anything about a URL scheme.

(The security problem with some file:// URLs actually is a completely different problem, it is not one that there is a question of whether the application makes sense with that scheme -- which it does.)

> Meanwhile the blacklist approach not only exposes you to security vulnerabilities, but imposes a cost every time the underlying platform adds support for a new URL type because now you have to update your blacklist to block it.

No, you only have to update the blacklist if it should be blocked. In many applications. Whether this is a cost that is paid more often than whitelist driven updates depends on whether in the particular application it is more likely that a new URL scheme will be allowed or prohibited.

Post reply on HN