[est]

I am replying to ams6110. Mind the context please.

> 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

[BobVerg]

No, it won't be %20. It isn't encoded. You should mkdir or touch "name ", not "name%20".

[est]

Seriously? Hello? We are talking about nginx....

[BobVerg]

A few quotes from the link, if you didn't read: "Some checks on a request URI were not executed on a character following an unescaped space character (which is invalid per HTTP protocol, but allowed for compatibility reasons since nginx 0.8.41)." [..] "by requesting a file as "/foo /../protected/file" (in case of static files, only if there is a "foo " directory with a trailing space)"

[est]

In case you don't read the sentence right before you quoted one:

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

[BobVerg]

Ok. To exploit any vulnerability the attacker have to do something. It's just obvious. I don't understand what you're trying to make clear.

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