Nginx 解析漏洞复现

该漏洞与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;
        }

1. 上述代码的可以简理解为:Nginx解析到.php的后缀名就会交给fastcgi处理，fastcgi可以简单的理解为python解释器一样的东西，负责php代码的执行渲染
   但是现在还不会导致Nginx解析的漏洞，需要配合另外一个配置文件php.ini构成Nginx解析漏洞
2. 在Nginx解析到后缀r名为.php会交给php处理，php在处理文件的时候会受到php.ini配置文件的影响，在php.ini配置文件中含有一个默认配置cgi.fix_pathinfo=1，该配置项的作用是如果访问的.php文件不存在，则采用上层路径，例如访问/test.png/.php,一般情况下.php文件是不存在的就会将/test.png解析
3. 最重要的配置就是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

实验结束。