On Mon, Nov 25, 2013 at 11:08 AM, Maxim Dounin <[email protected]> wrote:
> 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. > 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. > > 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. > 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?
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
