Three cases to see Nginx configuration security

Previously, an open source program https://github.com/yandex/gixy was recommended in Sec-News to detect problems in the Nginx configuration file. It just so happened that Pwnhub also had a problem in last week's game, including a vulnerability caused by a misconfiguration of Nginx.

So I choose what I think is more

Three typical cases that are interesting and likely to make mistakes, let’s talk about the security of Nginx configuration files.

In addition, the three cases involved in this article have all been online to Vulhub ( https://github.com/phith0n/vulhub/tree/master/nginx/insecure-configuration ). You can test it yourself while reading this article.

`$uri`The resulting CRLF injection vulnerability

The following two scenarios are very common:

User visits http://example.com/aabbcc, automatically jump tohttps://example.com/aabbcc
User visits http://example.com/aabbcc, automatically jump tohttp://www.example.com/aabbcc

For example, my blog, visit http://www.leavesongs.com/other/tinger.html, will be redirected to 301 https://www.leavesongs.com/other/tinger.html. With the popularity of https now, many sites are forced to use https access, and such jumps are very common.

The second scenario is mainly to unify the domain names that users visit, which is more conducive to SEO optimization.

In the process of jumping, we need to ensure that the page accessed by the user remains unchanged, so we need to obtain the file path requested by the user from Nginx. Looking at the Nginx documentation, you can find that there are three variables representing uri:

1 $ s

2. $ document_uri

3.$request_uri

To explain, 1 and 2 indicate the request path after decoding, without parameters; 3 indicates the complete URI (without decoding). Then, if the operation and maintenance is configured with the following code:

location / {

return 302 https://$host$uri;

}

Because $uri is the request path after decoding, it may contain line breaks, which creates a CRLF injection vulnerability. (For CRLF injection vulnerabilities, please refer to my old article https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html )

This CRLF injection vulnerability can lead to session fixation vulnerabilities, CSRF vulnerabilities caused by cookie settings, or XSS vulnerabilities. Among them, we can control the HTTP body for XSS by injecting two \r\n, but because the browser thinks this is a 300 jump, it will not display the content we injected.

In this case, we can use some techniques: for example, use the CSP header to the address of the iframe, so that the browser will not jump, and then execute the HTML we inserted:

For the above methods of use, you can refer to another article of mine

" Exploring the Bottle HTTP Header Injection Vulnerability ."

How to fix this CRLF vulnerability? The correct approach should be as follows:

location / {

return 302 https://$host#request_uri;

}

In addition, the $uriresulting CRLF injection vulnerability may not only appear in the above two scenarios, but theoretically, this problem will occur as long as the HTTP header can be set.

Directory traversal vulnerability

This is common when Nginx is used as a reverse proxy. The dynamic part is passed to the back-end port by proxy_pass, while static files need to be processed by Nginx.

Assuming that static files are stored in the /home/ directory, and the directory is named files in the url, then you need to use alias to set the alias of the directory:

location /files {

alias /home/;

}

At this time, visit http://example.com/files/readme.txt, you can get the /home/readme.txt file.

But we noticed that there is no suffix / for /files on the url, and /home/ set by alias has a suffix /. This / causes us to travel from the /home/ directory to its upper directory:

Then we got an arbitrary file download vulnerability.

This interesting loophole appeared in Pwnhub's last contest " Finding SNH48 ", @Ricter Master's topic.

How to solve this loophole? It is only necessary to ensure that the values of location and alias have a suffix /or neither have this suffix.

Http Header is covered

As we all know, Nginx's configuration file is divided into some configuration blocks such as Server, Location, If, and there are inclusion relationships, which are similar to programming languages. If some options are configured on the outer layer, they can be inherited to the inner layer.

But the inheritance here also has some features, such as add_header. After being configured in the child block, all HTTP headers added by add_header in the parent block will be overwritten , causing some security risks.

As in the following code, the CSP header is added to the Server block:

server {
    ...
    add_header Content-Security-Policy "default-src 'self'";
    add_header X-Frame-Options DENY;

    location = /test1 {
        rewrite ^(.*)$ /xss.html break;
    }

    location = /test2 {
        add_header X-Content-Type-Options nosniff;
        rewrite ^(.*)$ /xss.html break;
    }
}

However, the X-Content-Type-Options header was added to the location of /test2, which caused all add_headers in Fu Kuaizhong to fail:

At this point, the csp of test2 is completely invalid, and we successfully triggered the XSS:

to sum up

Nginx configuration files cause more than these three types of vulnerabilities. For example, the previously popular parsing vulnerability ( https://github.com/phith0n/vulhub/tree/master/nginx_parsing_vulnerability ) is also related to the Nginx configuration.

Solve this kind of vulnerability,

There are some solutions on Baidu.com. Many mistakes are spread one after another and finally spread.

In addition, we can also use the tool gixy mentioned at the beginning of this article. Scan the website before it goes live, and you may be able to find some possible problems.

Reference article:

The most fundamental way is to read the official documentation carefully, which explains many configuration file errors and correct usage.