<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 25, 2013 at 11:08 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Example of a vulnerable configuration is given in the directive<br>
description you've linked (<a href="http://nginx.org/r/merge_slashes" target="_blank">http://nginx.org/r/merge_slashes</a>):<br>
<br>
: Note that compression is essential for the correct matching of<br>
: prefix string and regular expression locations. Without it, the<br>
: “//scripts/one.php” request would not match<br>
:<br>
: location /scripts/ {<br>
:     ...<br>
: }<br>
: and might be processed as a static file. So it gets converted to<br>
: “/scripts/one.php”.<br>
<br>
That is, with merge_slashes switched off, restrictions like<br>
<br>
    location /protected/ {<br>
        deny all;<br>
    }<br>
<br>
can be easily bypassed by using a request to "//protected/file".<br>
It should be taken into account while writing a configuration for<br>
a server with merge_slashes switched off.<br></blockquote><div><br></div><div>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 problems.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Why does nginx not allow the<br>
> encoded slashes to be passed through (like Apache does[2]), and if it did<br>
> so, would that negate the security concerns?<br>
<br>
</div>While not decoding slashes is probably a better than not merging<br>
them, it's not really a good aproach either.  This way, the<br>
<br>
    <a href="http://www.mysite.com/search/http%3A%2F%2Fexample.com%2F" target="_blank">http://www.mysite.com/search/http%3A%2F%2Fexample.com%2F</a><br>
<br>
URL becomes equivalent to<br>
<br>
    <a href="http://www.mysite.com/search/http%3A%252F%252Fexample.com%252F" target="_blank">http://www.mysite.com/search/http%3A%252F%252Fexample.com%252F</a><br>
<br>
which isn't really consistent and may produce unexpected results.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
</div></div></div>