merge_slashes and decoding of the path

Jason Barnabe jason.barnabe at
Mon Nov 25 17:30:46 UTC 2013

On Mon, Nov 25, 2013 at 11:08 AM, Maxim Dounin <mdounin at> wrote:

> Example of a vulnerable configuration is given in the directive
> description you've linked (
> : Note that compression is essential for the correct matching of
> : prefix string and regular expression locations. Without it, the
> : “//scripts/one.php” request would not match
> :
> : location /scripts/ {
> :     ...
> : }
> : and might be processed as a static file. So it gets converted to
> : “/scripts/one.php”.
> That is, with merge_slashes switched off, restrictions like
>     location /protected/ {
>         deny all;
>     }
> can be easily bypassed by using a request to "//protected/file".
> It should be taken into account while writing a configuration for
> a server with merge_slashes switched off.

I'm not sure that applies in my configuration, where I'm using Passenger
and have no "protected" locations, but I can see how this could lead to

> > Why does nginx not allow the
> > encoded slashes to be passed through (like Apache does[2]), and if it did
> > so, would that negate the security concerns?
> While not decoding slashes is probably a better than not merging
> them, it's not really a good aproach either.  This way, the
> URL becomes equivalent to
> which isn't really consistent and may produce unexpected results.

I don't see how this would necessarily be the case, but I'll defer to your
knowledge. However, I don't think we should let perfect be the enemy of
"better", especially if the thing "better" would replace is a potential
security concern.

I do have this worked around in my app code (look for http:/, replace with
http://) so it's not a functional issue for me at the moment. It would be a
nice feature if it could be done sensibly - should I file an issue in trac?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list