本文共 1420 字,大约阅读时间需要 4 分钟。
声明
好好学习,天天向上
漏洞描述
由于一些不安全的配置引起的漏洞
影响范围
无
复现过程
这里使用1版本
使用vulhub
cd /app/vulhub-master/nginx/insecure-configuration
使用docker启动
docker-compose builddocker-compose up -d
运行成功后,Nginx将会监听8080/8081/8082三个端口,分别对应三种漏洞。
Mistake 1. CRLF注入漏洞
Nginx会将$uri进行解码,导致传入%0a%0d即可引入换行符,造成CRLF注入漏洞。
错误的配置文件示例(原本的目的是为了让http的请求跳转到https上):
location / { return 302 https://$host$uri;}
Payload如下,可注入Set-Cookie头。
http://192.168.239.129/%0a%0dSet-Cookie:%20a=1%0a%0d%0a%0d%0a
可以看到,其实代码已经注入,但是我这里没执行,不过set-cookie头还是被改变了
Mistake 2. 目录穿越漏洞
Nginx在配置别名(Alias)的时候,如果忘记加/,将造成一个目录穿越漏洞。
错误的配置文件示例(原本的目的是为了让用户访问到/home/目录下的文件):
location /files { alias /home/;}
Payload如下,成功穿越到根目录,访问etc下的passwd
http://192.168.239.129:8081/files../
Mistake 3. add_header被覆盖
Nginx配置文件子块(server、location、if)中的add_header,将会覆盖父块中的add_header添加的HTTP头,造成一些安全隐患。
如下列代码,整站(父块中)添加了CSP头:
add_header Content-Security-Policy "default-src 'self'";add_header X-Frame-Options DENY;location = /test1 { rewrite ^(.*)$ /xss.html break;}location = /test2 { add_header X-Content-Type-Options nosniff; rewrite ^(.*)$ /xss.html break;}
但/test2的location中又添加了X-Content-Type-Options头,导致父块中的add_header全部失效:
POC(IE中触发XSS)
http://192.168.239.129:8082/test2#
关闭镜像(每次用完后关闭)
docker-compose down
docker-compose常用命令
拉镜像(进入到vulhub某个具体目录后)
docker-compose builddocker-compose up -d
镜像查询(查到的第一列就是ID值)
docker ps -a
进入指定镜像里面(根据上一条查出的ID进入)
docker exec -it ID /bin/bash
关闭镜像(每次用完后关闭)
docker-compose down
转载地址:https://blog.csdn.net/zy15667076526/article/details/111414038 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!