if ($request_uri ~ " ") {
return 403;
}
Or am I misunderstanding this?
That would be /mydir%20/ or /%20mydir/ in URL, not literaly a space.
> this only works if you actally have a corresponding directory with a literal trailing space in the name
This won't work event if you have space in name because space would actually be %20. Only a carefully hand crafted HTTP packet would cause the vulnerability
> by using a specially crafted request.
It means you have to manually purposefully make an RFC2616 invalid HTTP request. Period.
Which means, even for a folder name with a trailing space, normal user wouldn't trigger this vulnerability, an attacker must use lower level tools/libraries. For example wget will auto encode URL for you, while cURL won't.
I tried to reply to ams6110, this vulnerability only works if you have dir with a trailing space and the attacker handcraft an http request packet, bypassing encode and sanity checking which is required in most HTTP client implementations.
And the vulnerability is not cause by or about trailing spaces in dirs, we can deal with those dirs fine. It's about how to make nginx config rules apply to obscure invalid URL s. It's a pitfall in nginx rule checking engine. Are we clear now?
> and attacker handcraft an http request packet, bypassing encode and sanity checking which is required in most HTTP client implementations
Well, it's not something hard to do. You don't have to dwell on this. To talk HTTP you don't even need HTTP client (sic!). Telnet or netcat can be easily used instead. I usually use them while configuring web-servers, most admins and devs usually do so.
But if you just so happen to run nginx on Windows, you can loose the trailing space requirement as any file is accessible with a space at the end. Also in "/foo /../protected/file" scenario, foo doesn't need to exist.