PHP环境下FastCGI解析漏洞修复方案

漏洞描述：

Nginx默认是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。当访问http://192.168.1.1/phpinfo.jpg/1.php这个URL时，$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”，然后构造成SCRIPT_FILENAME传递给PHP CGI。如果PHP中开启了fix_pathinfo这个选项，PHP会认为SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就会将phpinfo.jpg作为PHP文件来解析了。

漏洞危害：

利用该漏洞，攻击者可以将任意文件类型作为PHP文件解析，攻击者通常利用该漏洞来获取到一个WebShell。

修复方案：（Nginx用户可以选择方案一或方案二，IIS用户请使用方案一）

方案一，修改php.ini文件，将cgi.fix_pathinfo的值设置为0。完成后请重启PHP和NGINX（IIS）。
方案二，在Nginx配置文件中添加以下代码：
if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}
这行代码的意思是当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。修改完成后请重启Nginx。

在我进行漏洞修复时，按照以上官方方案一，关闭cgi.fix_pathinfo功能后，漏洞仍然存在（/favicon.ico/a.php以及/robots.txt/a.php常见漏洞）。

经过详细分析，发现php.ini文件默认是将cgi.fix_pathinfo功能注释掉的，也就是将其值设为0无法直接修复该漏洞。

正确的方式，是在cgi.fix_pathinfo的值设为0之后，把这一行的行首“:”注释符号去掉，才能使解析方案生效。

我真是挺粗心的。

但这种关闭cgi.fix_pathinfo功能的修复方案，也可能会造成相关功能异常。虽然目前并未出现异常，但先记录下来，应对以后可能出现的问题。