Examples of common Nginx misconfigurations

Nginx is the current mainstream Web service. The following are some of the most common misconfigurations.

Missing root location

server {
  root /etc/nginx;

  location /hello.txt {
    try_files $uri $uri/ =404;
    proxy_pass http://127.0.0.1:8080/;
  }
}

root directive specifies the Nginx root directory. In the above example, the root directory is /etc/nginx, which means we can access files under that directory. The above configuration has no location for / ( location / {...} ), only the location for /hello.txt. Therefore, the root directive will be set globally, which means that requests to / will take you to the local path /etc/nginx.

A simple request like GET /nginx.conf will display the contents of the Nginx configuration file stored in /etc/nginx/nginx.conf. If the root is set to /etc, a GET request to /nginx/nginx.conf will display the configuration file. In some cases, other configuration files, access logs, and even encrypted credentials for HTTP Basic Authentication may be accessed.

Among the nearly 50,000 Nginx configuration files we collected, the most common root paths are as follows:

Off-By-Slash

server {
  listen 80 default_server;

  server_name _;

  location /static {
    alias /usr/share/nginx/static/;
  }

  location /api {
    proxy_pass http://apiserver/v1/;
  }
}

With the Off-by-slash configuration error, it was possible to move one step up the path due to the missing /. This technique was made popular by Orange Tsai in his Blackhat talk "Breaking Parser Logic!" In this talk he shows how the missing slash of the location directive combined with the alias directive makes it possible to read the source code of a web application. What is less well known is that it can also be used in conjunction with other directives such as proxy_pass. Let’s break down what’s happening and why it works.

  location /api {
    proxy_pass http://apiserver/v1/;
  }

If the following configuration is accessible to the Nginx server, you can assume that only paths under http://apiserver/v1/ are accessible.

http://server/api/user -> http://apiserver/v1//user

When a request is made to http://server/api/user, Nginx will first normalize the URL. It then looks to see if the prefix /api matches the URL, in which case it does. The prefix is ​​then removed from the URL, so the /user path remains. This path is then added to the proxy_pass URL, resulting in a final URL of http://apiserver/v1//user. Note that there are double slashes in the URL because the location directive does not end with a slash, and proxy_pass URL path ends with a slash. Most web servers will normalize http://apiserver/v1//user user to http://apiserver/v1/user, which means that even if there is a configuration error, everything will still work as expected and it may not be noticed.

This misconfiguration can be exploited by requesting http://server/api../, which will cause Nginx to request the URL http://apiserver/ which is normalized to http://apiserver/v1/../. The impact this might have depends on what can be achieved by exploiting this misconfiguration. For example, this could result in the Apache server status being exposed via the URL http://server/api../server-status, or could make paths accessible that you do not wish to be publicly accessible.

One sign that your Nginx server is misconfigured is that when the slashes in the URL are removed, the server still returns the same response. For example, if http://server/api/user and http://server/apiuser return the same response, the server may be vulnerable. This will result in the following request being sent:

http://server/api/user -> http://apiserver/v1//user
http://server/apiuser -> http://apiserver/v1/user

Unsafe variable use

Some frameworks, scripts, and Nginx configurations use Nginx stored variables insecurely. This can lead to issues such as XSS, bypassing HttpOnly protection, information disclosure, and even RCE in some cases.

SCRIPT_NAME

The configuration is as follows:

  location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
  }

The main problem is that Nginx will send all URLs ending in .php to the PHP interpreter, even if the file does not exist on disk. This is one of many Nginx misconfigurations listed in the Pitfalls and Common Mistakes document created by Nginx.

If a PHP script attempts to define a base URL based on SCRIPT_NAME, XSS will occur.

<?php

if(basename($_SERVER['SCRIPT_NAME']) ==
basename($_SERVER['SCRIPT_FILENAME']))
 echo dirname($_SERVER['SCRIPT_NAME']);

?>

GET /index.php/<script>alert(1)</script>/index.php
SCRIPT_NAME = /index.php/<script>alert(1)</script>/index.php

Usage of $uri can lead to CRLF Injection

Another misconfiguration related to Nginx variables is using $uri or $document_uri instead of $request_uri. $uri and $document_uri contain the normalized URI, and normalization in Nginx includes URL decoding of the URI. Volema discovered that creating redirects in Nginx configurations can lead to CRLF injections, often using $uri.

An example of a vulnerable Nginx configuration is as follows:

location / {
 return 302 https://example.com$uri;
}

The newline characters for HTTP requests are \r (carriage return) and \n (line feed). URL encoding the new line character will result in the representation of the following characters ％0d％0a . If these characters are included in a misconfigured request to a server (for example, http://localhost/%0d%0aDetectify:%20clrf), the server will respond with a new header named Detectify because $uri variable contains the newline characters after URL decoding.

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

Any variable

In some cases, user-supplied data can be treated as Nginx variables. It is not clear why this happens, but as shown in this H1 report, it is not uncommon or easy to test for. If we search for the error message, we can see that it is found in the SSI filter module, thus indicating that this is due to SSI.

The test method is as follows:

$ curl -H 'Referer: bar' http://localhost/foo$http_referer | grep 'foobar'

Raw backend response reading

Using Nginx's proxy_pass , you can intercept errors and HTTP headers created by the backend. This is useful if you want to hide internal error messages and headers so that they can be processed by Nginx. If the backend fails to respond to a request, Nginx will automatically serve a custom error page. But what if Nginx doesn't understand that this is an HTTP response?

If a client sends an invalid HTTP request to Nginx, the request will be forwarded as is to the backend, which will answer with its original content. Nginx will then not understand the invalid HTTP response and will forward it to the client. Imagine a uWSGI application like this:

def application(environ, start_response):
 start_response('500 Error', [('Content-Type',
'text/html'),('Secret-Header','secret-info')])
 return [b"Secret info, should not be visible!"]

Nginx configuration is as follows:

http {
 error_page 500 /html/error.html;
 proxy_intercept_errors on;
 proxy_hide_header Secret-Header;
}

proxy_intercept_errors will provide a custom response if the backend's response status is greater than 300. In the uWSGI application above, we will send a 500 error, which will be intercepted by Nginx.

proxy_hide_header: Can hide any specified HTTP header from the client.

If we send a normal GET request, Nginx will return:

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: close

However, if we send an invalid HTTP request such as:

GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close

We will receive the following response:

XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info

Secret information, should not be visible!

merge_slashes set to off

By default, the merge_slashes directive is set to on , which is a mechanism that compresses two or more forward slashes into one, so /// will become / . If Nginx is used as a reverse proxy and the proxied application is vulnerable to local file inclusion, the use of extra slashes in the request may leave room for exploitation. Danny Robinson and Rotem Bar describe this in detail.

The above are the details of some common Nginx misconfigurations. For more information about Nginx misconfigurations, please visit 123WORDPRESS.COM for other related articles!