漏洞描述:
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常见漏洞)。
但这种关闭cgi.fix_pathinfo功能的修复方案,也可能会造成相关功能异常。虽然目前并未出现异常,但先记录下来,应对以后可能出现的问题。


cgi.fix_pathinfo
这个参数一定害人不浅吧
深有同感。
对于楼上两位,
官方的修复方案一定想不到这会成为用户的大问题啊。
眼尖的应该能够解决问题,自动处理软件用惯了的话,倒可能不够细心。