Nginx+PHP 配置漏洞

这个漏洞严格上说并不是 Nginx 和 PHP 本身的漏洞造成的，而是由配置造成的。在我之前写的许多配置中，都普遍存在这个漏洞。
简易检测方法：
打开 Nginx + PHP 服务器上的任意一张图片，如：
http://blog.lrenwang.com/test.png
如果在图片链接后加一串 /xxx.php （xxx为任意字符）后，如：
http://blog.lrenwang.com/test.png/xxx.php
图片还能访问并且输出的 Content-Type 为 text/html 的话，说明你的配置存在漏洞。
分析原因
Nginx 传给 PHP 的值为 /var/www/lrenwang/test.png/xxx.php，即 $_SERVER 中 ORIG_SCRIPT_FILENAME 的值，但是 $_SERVER 中 SCRIPT_FILENAME 却是 /var/www/test/test.png。
原因是，/var/www/lrenwang/test.png/xxx.php 并不存在，对于这些不存在的路径，PHP 会检查路径中存在的文件，并将多余的部分当作 PATH_INFO。
这里，/var/www/lrenwang/test.png 被 PHP 解析为 SCRIPT_FILENAME，/xxx.php 被 PHP 解析为 PATH_INFO 后被丢弃，因此并没有在 $_SERVER 中出现。
解决方法：
解决这个漏洞的方法很显然：关闭上面所述的解析即可。
这个解析可以在 PHP 的配置文件中设置，默认为开启。在这里我们需要将它关闭：
;cgi.fix_pathinfo=1
cgi.fix_pathinfo=0
其中 cgi.fix_pathinfo=0 为新增的配置行，表示关闭 PHP 的自动 PATH_INFO 检测。关闭后，该配置漏洞即可消除。
更好的解决方案？
以上方案并不是最完美的，如果你先前有用到 cgi.fix_pathinfo 这个特性，影响会很大，比如关闭后，Wordpress文章的 URL 目录形式就得用 rewrite 来实现了。
如果可以将 PHP 设置成只解析 .php 为扩展名的文件，那么这个问题解决起来会更合理。
不过我没找到相关的设置项，或许今后应该出现在 php-fpm 的配置文件中？
总结：
这类问题基本上是无法预料的，但是如果架构设计良好的话，即使存在这个问题，也不会影响安全性。这里给出架构上的安全建议：
* 尽可能使动静内容分离，所有的静态内容存在于静态内容服务器，静态内容服务器上不解析PHP，这样静态文件就永远不能被解析了。