Nginx
Last updated
Was this helpful?
Last updated
Was this helpful?
NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. But there is some common Nginx misconfigurations that, if left unchecked, leave the web site vulnerable to attack.
There are several tools available, such as and , which can automate the process of identifying misconfigurations in Nginx.
is a tool to analyze Nginx configuration. The main goal of Gixy is to prevent security misconfiguration and automate flaw detection. This is a static files analyzer.
The root directive specifies the root folder for Nginx. In the following example, the root folder is /etc/nginx
which means that we can reach files within that folder.
In the above example, the root folder is /etc/nginx
which means that we can reach files within that folder. The configuration does not have a location for / (location / {...})
With the Off-by-slash misconfiguration, it is possible to traverse one step up the path due to a missing slash. Inside the Nginx configuration look the "location" statements, if someone looks like:
Some frameworks, scripts and Nginx configurations unsafely use the variables stored by Nginx. This can lead to issues such as XSS, bypassing HttpOnly-protection, information disclosure and in some cases even RCE.
With a configuration such as the following:
The misconfiguration related is to use $uri
or $document_uri
instead of $request_uri
which results in a CRLF injection. This is because this two variables contain the normalized URI whereas the normalization in Nginx includes URL decoding.
In Nginx, proxy_pass
you can intercept errors and HTTP headers created by the backend. This is very useful if you want to hide internal error messages. But if client sends an invalid HTTP request, it will be forwarded as-is to the backend, the backend will answer with its raw content, and then Nginx wonโt understand the invalid HTTP response and just forward it to the client.
With a configuration such as the following:
The proxy_pass
directive can be used to redirect internally requests to other servers internal or external. The use of this directive isn't a vulnerability but you should check how it's configured.
If the regular expressions used in that directive are weak, they allow HTTP splitting to happen.
With a configuration such as the following:
the problem with this regular expressions is that it also allows newlines per default. In this case, the [^/]*
part actually also includes encoded newlines.
In some setups, a matching path is used as part of the hostname to proxy to.
Since the bucket is attacker controlled (part of the URI path) this leads to XSS but also has further implications.
We could make proxy_pass
connect to a local unix socket as it supports proxying requests to local unix
sockets. What might be surprising is that the URI given to proxy_pass
can be prefixed with http://
or as a UNIX-domain socket path specified after the word unix
and enclosed in colons:
learn more about CRLF and TTP response splitting
will serve a custom response if the backend has a response status greater than 300. In our uWSGI application above, we will send a 500 Error which would be intercepted by Nginx. is pretty much self explanatory; it will hide any specified HTTP header from the client.
The directive is set to on
by default which is a mechanism to compress two or more forward slashes into one, so ///
would become /
. If Nginx is used as a reverse-proxy and the application thatโs being proxied is vulnerable to local file inclusion, using extra slashes in the request could leave room for exploit it. This is described in detail by
Arbitrary Redis command execution vulnerability may be abuse using the command from Redis. We can execute Redis commands from EVAL using two different Lua functions: redis.call()
and redis.pcall()