Nginx 漏洞利用
Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。尽管还是测试版，但是，Nginx 已经因为它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名了。因为 Nginx 的文档大部分是俄文的，Nginx 的中文维基的目的是帮助使用中文世界的用户安装、配置和交换有关 Nginx 的使用经验。大部分文档源自Aleksandar Lazic 的工作。有关本维基本身的问题请直接询问Cliff Wells 。
Nginx 可以在大多数 Unix like OS 上编译运行，并有 Windows 移植版。目前 Nginx 的开发版为 0.7.x，稳定版为 0.6.x，历史稳定版为 0.5.x，建议使用 0.6 系列作为生产版本。 Nginx 的源代码使用 2-clause BSD-like license。
nginx默认以cgi的方式支持php的运行，譬如在配置文件当中可以以
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}
的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.ihonker.org/some.jpg，我们以如下的方式去访问
http://www.ihonker.org/some.jpg/some.php
得到/some.jpg/some.php
系统将解析
/some.jpg
/some.php
系统将会把some.jpg使用php解析器解析其中代码，
那么首相将php后门代码放入some.jpg，上次到服务器上，然后访问http://www.ihonker.org/some.jpg/some.php，即可实现执行php后门。
两年前，还是三年前，好像大家应该看过这个了。{:soso_e101:} 下次放点好的 遇到未成功
Re: Nginx 漏洞利用
感谢楼主的分享，这个漏洞分析得很清楚。确实，如果服务器开启了 `cgi.fix_pathinfo`，并且 Nginx 的 `location` 匹配规则不够严格，攻击者可以通过上传看似无害的图片文件（内含 PHP 代码）并构造特殊 URL 来执行恶意脚本。 对于使用 Nginx + PHP-FPM 的站点，建议将 `cgi.fix_pathinfo` 设置为 `0` 来关闭路径信息修复，同时在 Nginx 配置中对 `\.php$` 的 location 块里加上 `try_files $uri =404;` 来确保请求的文件真实存在，避免被非正常路径绕过。另外，上传目录可以单独配置不允许执行 PHP，这样更安全。 希望对大家加固服务器有帮助。Re: Nginx 漏洞利用
楼主分享的这个Nginx配合PHP解析时的安全隐患很经典，确实需要引起注意。关键点在于`fastcgi_param SCRIPT_FILENAME`直接由URI控制，加上PHP的`cgi.fix_pathinfo`开启后，会把非PHP文件（如jpg）当作脚本来解析，从而被利用。修复方法通常是在Nginx配置中添加`try_files`指令来校验文件是否存在，比如： ```nginx location ~ \.php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; ... } ``` 或者将`SCRIPT_FILENAME`改为`$document_root$fastcgi_script_name`并确保路径安全。另外，上传目录尽量禁止执行PHP也是常见防御手段。感谢楼主的详细分析，对理解这类漏洞原理很有帮助。Re: Nginx 漏洞利用
感谢分享这个Nginx的安全分析。这个利用方法的原理确实比较经典，核心在于 `SCRIPT_FILENAME` 由用户请求的 URI 直接生成，结合 PHP 的 `cgi.fix_pathinfo` 选项，让非脚本文件（如图片）被当作 PHP 解析。对于还在使用类似配置的生产环境，这个提醒很有价值，建议检查 `fastcgi_param` 的传入规则以及 PHP 的 `cgi.fix_pathinfo` 是否关闭，避免被利用。
页:
[1]