Nginx错误配置引发的解析漏洞复现

首先说明，漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞，也就是增加`/.php`后缀，被解析成PHP文件。还是用的vulhub的漏洞环境，先看提供的图片。

图片最后是写入了phpinfo的代码的，我们浏览器打开这张图片。这里我就不演示文件上传部分了，因为漏洞本身不在上传部分。

图片是正常加载的，但是如果在图片url后增加`/.php`后缀会怎样呢？

现在看看nginx的配置文件时如何写的，漏洞出现在哪里。

    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处理，所以我们构造的http://ip/uploadfiles/nginx.png/.php也是交给fastcgi处理的。

通过phpinfo查看cgi.fix_pathinfo=1，PHP里经常要获取当前请求的URL路径信息。一般可以通过环境变量$_SERVER[‘PATH_INFO’]获取，而配置文件中的cgi.fix_pathinifo选项则与这个值的获取相关。

cgi.fix_pathinfo的默认值是1。nginx默认是不会设置PATH_INFO环境变量的的值，需要通过正则匹配设置SCRIPT_FILENAME，但这样会带来安全隐患，需要把cgi.fix_pathinfo=0设置为0。但是一旦关闭这个，PHP就获取不到PATH_INFO信息，那些依赖PATH_INFO进行URL美化的程序就失效了。

所以fastcgi在处理’.php’文件时发现文件并不存在,这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用,这项配置用于修复路径,如果当前路径不存在则采用上层路径。这里’/nginx.png’就交由fastcgi处理了。

另外php-fpm.conf中的security.limit_extensions配置项限制了fastcgi解析文件的类型，此项设置为空的时候才允许fastcgi将’.png’等文件当做代码解析。所以我们可以限制fpm允许解析的脚本扩展名，这样就能预防web服务器配置的错误。

我们修改配置文件后再重启环境，此时相当于设置了白名单，仅允许php的后缀可以解析执行。

所以对于该漏洞的处理办法，如果实在不能关闭cgi.fix_pathinifo选项的情况下，就将php-fpm.conf中的security.limit_extensions后面的值设置为.php，尽可能降低漏洞危害。