该漏洞与php和nginx版本无关，是配置错误导致的问题
漏洞描述
通常在nginx.conf的配置文件或者include包含的其他配置文件下有以下信息
location ~ \.php$ {fastcgi_index index.php;include fastcgi_params;fastcgi_param REDIRECT_STATUS 200;fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;fastcgi_param DOCUMENT_ROOT /var/www/html;fastcgi_pass php:9000;}
- 上述代码的可以简理解为:
Nginx解析到.php的后缀名就会交给fastcgi处理，fastcgi可以简单的理解为python解释器一样的东西，负责php代码的执行渲染
但是现在还不会导致Nginx解析的漏洞，需要配合另外一个配置文件php.ini构成Nginx解析漏洞 - 在
Nginx解析到后缀r名为.php会交给php处理，php在处理文件的时候会受到php.ini配置文件的影响，在php.ini配置文件中含有一个默认配置cgi.fix_pathinfo=1，该配置项的作用是如果访问的.php文件不存在，则采用上层路径，例如访问/test.png/.php,一般情况下.php文件是不存在的就会将/test.png解析 - 最重要的配置就是
php-fpm的配置文件中的security.limit_extensions配置项默认为空，该文件规定了什么后缀名当做php代码执行
所以通过这一连贯的默认配置，我们可以访问一个/test.png的文件，后方加入/.php或者是任意不存在的a.php,就会由于Nginx解析漏洞导致php代码执行
漏洞利用
使用vulhub复现靶机
cd /vulhub/nginx/nginx_parsing_vulnerability
sudo docker-compose up -d
随便上传一个含有php代码的图片
访问该图片成功上传
在最后加入/.php或者任意一个不存在的文件名例如：/a.php
成功利用
漏洞修复
修改php-fpm配置文件项security.limit_extensions加入只有.php后缀名解析为php代码执行
[www]
security.limit_extensions = .php
重启服务器再次漏洞利用失败
sudo docker-compose restart
实验结束。
