标签：Nginx url 中间件 jpg nginx php 漏洞
nginx篇
1.介绍
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like
协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中
表现较好。
3.1.文件解析漏洞
1.漏洞描述
该漏洞是由于Nginx中php配置不当而造成的，与Nginx版本无关，但在高版本的php中，由于security.limit_extensions的引入，使得该漏洞难以被成功利用。
在已经上传了恶意1.jpg文件后，访问/1.jpg/xxx.php，（路径修复cgi.fix_pathinfo=1后使得Nginx将其解析为php文件传给php-cgi程序
（传给路径位于SERVER["SCRIPT_FILENAME"]，修复去除路径位于SERVER["PATH_INFO"]），但cgi程序将其解析为1.jpg并执行。
2.漏洞复现
使用phpstudy nginx php5.2
当cgi.fix_pathinfo=1时存在此漏洞
3.漏洞原理分析
Nginx的处理程序和FastCGI处理程序不同导致
Nginx拿到URI为/1.jpg/xxx.php后，识别处后缀是.php，认为是php文件，转交给PHP FastCGI处理程
序去处理。PHP FastCGI处理程序识别该URI： /1.jpg/xxx.php不存在，按照PHP FastCGI处理程序自己
的规则，删去最后的/xxx.php，又看/1.jpg存在，就将/1.jpg当成要执行的文件，就成功解析。
Nginx传送给PHP FastCGI处理程序的路径可以在phpinfo中查看【传送路径查看】
cgi.fix_pathinfo为php中的一个选项，默认开启为1，作用为修理路径，也就是对路径URI的处理规范
当php遇到文件路劲为/1.jpg/xxx.php/ss.001时，该文件不存在，会删除最后的/ss.001，再判
断/1.jpg/xxx.php是否存在，若存在则将/1.jpg/xxx.php当作/1.jpg/xxx.php/ss.001文件，若不存在，则
继续删除最后一个路径。删除的多余路径会存在PATH_INFO中，在这里为ss.001
4.修复方案
1、 将php.ini文件中的cgi.fix_pathinfo的值设置为0,这样php再解析1.php/1.jpg这样的目录时,只要1.jpg
不存在就会显示404页面
2、 php-fpm.conf中的security.limit_extensions后面的值设置为.php
目录遍历漏洞
Nginx的目录遍历与apache一样,属于配置方面的问题,错误的配置可导致目录遍历与源码泄露。
漏洞原理
修改nginx.conf,在如下图位置添加autoindex on
autoindex on;
autoindex on 开启目录浏览 autoindex off关闭目录浏览 默认是关闭状态
漏洞复现
在nginx的配置文件中
可目录遍历
4.漏洞修复
1.设置 autoindex off 关闭目录浏览
2.删除 autoindex on
空字节代码执行漏洞
漏洞描述
在使用PHP-FastCGI执行php的时候，URL里面在遇到%00空字节时与FastCGI处理不一致，导致可在非
php文件中嵌入php代码，通过访问url+%00.php来执行其中的php代码。如：
http://local/robots.txt.php会把robots.txt文件当作php来执行。
影响版本：
nginx 0.5.*
nginx 0.6.*
nginx 0.7 <= 0.7.65
nginx 0.8 <= 0.8.37
漏洞复现
开启nginx
在网站目录下添加1.jpg文件
访问该文件
4）抓包，添加%00
这里由于该图非正常，在抓包时最后面添加..，可以让burpsuite抓到
将请求修改为：
/1.jpg..php
发包即可
3.漏洞修复
1.在nginx虚拟机配置或者fcgi.conf配置加如下代码：
if ($request_filename ~* (.*)\.php) {
set $php_url $1;
}
if (!-e $php_url.php) {
return 403;
}
2.升级 nginx
整数溢出漏洞（CVE-2017-7529）
漏洞描述
在 Nginx 的 range filter 中存在整数溢出漏洞，可以通过带有特殊构造的 range 的 HTTP 头的恶意请求
引发这个整数溢出漏洞，并导致信息泄露。
该漏洞影响所有 0.5.6 - 1.13.2版本内默认配置模块的Nginx只需要开启缓存攻击者即可发送恶意请求进
行远程攻击造成信息泄露。当Nginx服务器使用代理缓存的情况下攻击者通过利用该漏洞可以拿到服务
器的后端真实IP或其他敏感信息。
通过我们的分析判定该漏洞利用难度低可以归属于low-hanging-fruit的漏洞在真实网络攻击中也有一定
利用价值。
漏洞复现
https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2017-7529
检测脚本
#!/usr/bin/env python
import sys
import requests
if len(sys.argv) < 2:
print("%s url" % (sys.argv[0]))
print("eg: python %s http://your-ip:8080/" % (sys.argv[0]))
sys.exit()
headers = {
'User-Agent': "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"
}
offset = 605
url = sys.argv[1] file_len = len(requests.get(url, headers=headers).content) n = file_len + offset
headers['Range'] = "bytes=-%d,-%d" % (
n, 0x8000000000000000 - n)
r = requests.get(url, headers=headers)
3.漏洞修复
升级版本
CRLF注入漏洞
漏洞描述
Nginx将传入的url进行解码，对其中的%0a%0d替换成换行符，导致后面的数据注入至头部，造成CRLF
注入漏洞。
2.漏洞复现
设置https跳转，这样就可以接收到url，进而进行处理。在
C:\phpStudy\PHPTutorial\nginx\conf\nginx.conf文件中添加下面一行话。
location / {
return 302 https://$host$uri;
}
一个正常的302跳转包如下图：
抓包发送repeater模式下修改包的内容（注入一个换行，在http头里注入了cookie，如下图）与url直接（上面）访问抓包，他们的返回包都是一样的。
http://192.168.189.139:8080/ Set-cookie:JSPSESSID%3Ddrops
此时的返回包如下图：
查看恶意数据是否在响应头中输出
将修改后的请求包提交给服务器端，查看服务器端的响应。发现响应首部中多了个Set-Cookie字段。这就证实了该系统存在CRLF注入漏洞，因为我们输入的恶意数据，作为响应首部字段返回给了客户端。
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。 当然，CRLF并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。 比如一个网站接受url参数http://192.168.189.137:8080/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是：
http://192.168.189.137:8080/url=
/
我们的返回包就会变成这样：
这样就造成了反射型xss
参考：https://www.cnblogs.com/null1433/p/12725776.html
文件名逻辑漏洞（CVE-2013-4547）
1.漏洞描述
这一漏洞的原理是非法字符空格和截止符（\0）会导致Nginx解析URI时的有限状态机混乱，此漏洞可导
致目录跨越及代码执行，其影响版本为：nginx 0.8.41 – 1.5.6
漏洞影响版本
Nginx 0.8.41~1.4.3
Nginx 1.5.0~1.5.7
2.漏洞复现
创建 1.jpg 文件，并上传
以vulnhub提供的漏洞环境为例，我们首先看一下前端页面
可以看到上传成功
访问该文件，burpbuite抓包处理
访问URL：http://192.168.112.111/1.jpg...php
在burp的hex页面中将第一个点.改成20，第二个改为00
3.漏洞修复
1.升级nginx
参考：https://www.cnblogs.com/yuzly/p/11221564.html
https://www.cnblogs.com/bmjoker/p/9838600.html
标签：Nginx,url,中间件,jpg,nginx,php,漏洞 来源： https://www.cnblogs.com/mwyw/p/15473678.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。