merge_slashes and decoding of the path

Maxim Dounin mdounin at
Mon Nov 25 17:08:02 UTC 2013


On Mon, Nov 25, 2013 at 10:44:15AM -0600, Jason Barnabe wrote:

> On my site, I accept full URL-encoded URLs as part of the path, for example:
> I recently moved my site to nginx and I found that it was decoding and
> collapsing the slashes before passing it on to Passenger. It would pass
> along the URL like this:
> I found the merge_slashes setting, and on setting it to off, Passenger now
> receives URLs like this: .
> So the slashes are kept, but the path is still decoded. The nginx
> documentation [1] says "However, for security considerations, it is better
> to avoid turning the compression off."
> What are the security considerations here?

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.

> 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.

Maxim Dounin

More information about the nginx mailing list