Nginx Alias Traversal

Known as ‘off-by-slash’, this is seen as a configuration issue by the Nginx developers and not an issue to be fixed – which makes it particularly interesting functionality!

The NGINX alias directive defines a replacement for the specified location.
For example, with the following configuration:

location /i/ {
    alias /data/w3/images/;
}

on request of /i/top.gif, the file /data/w3/images/top.gif will be sent.

But, if the location doesn’t ends with directory separator (i.e. /):

location /i {
    alias /data/w3/images/;
}

on request of /i../app/config.py, the file /data/w3/app/config.py will be sent.

Detection:

Vulnerable: https://example.com/assets

assets/ => 403 Forbidden
assets../ => 403 Forbidden
assets.../ => 404 Not found
alias../../ => 403 Forbidden
alias../../../../../../../../../../../ => 400 bad request

After doing some research of my own, the really interesting thing is that this issue isn’t just detected by a status code of 403, but if any status code with the exception of 404 stays the same after .. has been added to the end of the path.

Technically, even 404s can display this issue, but due to the nature of the response it becomes a lot harder to detect without then having to bruteforce a path. I think that we can probably exclude 400 and 500 too, on the basis of whatever is causing the error is likely prevalent both times. It all comes down to situation, in fairness.

I don’t think that for any of the tools I’ve found it looks for any non-404 response, it seems to just look at 403 responses. The Off-by-slash Burp Plugin could be modified for this purpose, potentially.

Detection:

References: