merge_slashes and decoding of the path

[Maxim Dounin]

Hello!

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:
> 
> http://www.mysite.com/search/http%3A%2F%2Fexample.com%2F
> 
> 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: http://www.mysite.com/search/http:/example.com/
> 
> I found the merge_slashes setting, and on setting it to off, Passenger now
> receives URLs like this: http://www.mysite.com/search/http://example.com/ .
> 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 (http://nginx.org/r/merge_slashes):

: 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 

    http://www.mysite.com/search/http%3A%2F%2Fexample.com%2F

URL becomes equivalent to

    http://www.mysite.com/search/http%3A%252F%252Fexample.com%252F

which isn't really consistent and may produce unexpected results.

-- 
Maxim Dounin
http://nginx.org/en/donation.html