nginx常见漏洞解析_nginx漏洞

web中间件用于提供系统软件和应用软件之间的连接，以便于软件各部件之间的沟通，其可以为一种或多种应用程序提供容器。

web容器:
web容器用于给处于其中的应用程序组件（JSP，SERVLET）提供一个环境，是中间件的一个组成部分，它实现了对动态语言的解析。比如tomcat可以解析jsp，是因为其内部有一个jsp容器。

常见的组件：

web服务器：IIS、Apache、nginx、tomcat、weblogic、websphere等。
web中间件：apache tomcat、BEA WebLogic、IBM WebSphere等。
web容器：JSP容器、SERVLET容器、ASP容器等。

注意：web中间件与web服务器是有重叠的，原因在于tomcat等web中间件也具备web服务器的功能。

说白了，web中间件就是运行在服务器上的一个程序，它的作用是为服务器提供一个解析http或者https请求的方案。由它充当中间人，确定前端传输的信息应该交给后端哪一个文件进行处理，并向前端返回结果。

对于其的操控我们大多数时候是在LINUX环境下采用配置文件对其进行控制。这就意味着某些错误的配置会引发一些安全漏洞。并且作为一款程序，也一定会存在着一些自身的安全漏洞。以上两个方向就是我们研究任何一个中间件漏洞应该具有的基本认知。

今天我们先来看一看nginx出现过的一些漏洞，环境均来自vulhub官网，其为基于docker的漏洞环境集成库，对我们的学习很有帮助~

三个配置不当导致的nginx漏洞

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

作为配置不当引起的漏洞，自然对所有版本的nginx都影响，这种小的问题反而很容易引起忽视。

1.$uri导致的crlf注入漏洞

下面两种情景十分常见：

1. 用户访问http://example.com/aabbcc，自动跳转到https://example.com/aabbcc
2. 用户访问http://example.com/aabbcc，自动跳转到http://www.example.com/aabbcc

第二个场景主要是为了统一用户访问的域名，更加有益于SEO优化。

在跳转的过程中，我们需要保证用户访问的页面不变，所以需要从Nginx获取用户请求的文件路径。查看Nginx文档，可以发现有三个表示uri的变量：

1. $uri
2. $document_uri
3. $request\_uri

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

解释一下，1和2表示的是解码以后的请求路径，不带参数；3表示的是完整的URI（没有解码）。那么，如果运维配置了下列的代码：

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

因为**$uri**和**$document_uri**是解码以后的请求路径，所以可能就会包含换行符，也就造成了一个CRLF注入漏洞。

1.1利用方式：

我们在请求的过程中发送一个带有%0d%0a编码的请求：

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

我们通过上述手段对请求进行了修改，利用此漏洞可以看到返回了一个set-cookie，也就是说错误的使用$uri配置会是用户的请求被黑客悄无声息的篡改掉。

我们使用burp抓包可以看到另一种可能性：在我们发送两个连续的换行\r\n后，可以直接修改返回报文的返回体。插入js代码引发xss。

1.2修改方案：

在获取用户的请求路径时，配置文件内出现的配置应当是**$request_uri**,例如：

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

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

另外，由$uri导致的CRLF注入漏洞不仅可能出现在上述两个场景中，理论上，只要是可以设置HTTP头的场景都会出现这个问题。

测试一下效果：

#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. 目录穿越漏洞：

这个常见于Nginx做反向代理的情况，动态的部分被proxy_pass传递给后端端口，而静态文件需要Nginx来处理。

假设静态文件存储在/home/目录下，而该目录在url中名字为files，那么就