文章总结： 本文记录了一次漏洞赏金实战：通过路径遍历漏洞将只读查看者账户提权为管理员。核心在于Action参数值被直接拼入内部URL路径且未清理，同时内部调用默认被信任而跳过角色验证。作者通过./确认路径解析，再用…/遍历至管理员接口，最终成功提权。文章强调深入探究响应原因而非止步于表面200状态码。 综合评分： 85 文章分类： 漏洞分析,WEB安全,渗透测试,红队
通过../../ 提权为管理员
Adhamkhairy Adhamkhairy
漏洞集萃
2026年9月12日 21:18 山东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
本公众号所发布的文章内容仅供学习与交流使用，禁止用于任何非法用途；如有侵权烦请告知，我们会立即删除并致歉，谢谢
在测试一个私有漏洞赏金计划时，我遇到了一个
作者: Adhamkhairy
原文链接: https://infosecwriteups.com/to-admin-for-a-bounty-b946f781607f
该目标承担着两个角色。
管理员：设置、用户管理、计费、促销。基本上涵盖了整个应用程序。大约有 150 个接口。
观众：看几篇资料就回家吧。10 个端点。猜猜哪个是我的账号。
有140个端点我不被允许触碰。这一差距并非限制，而是一份待办事项清单。
没人会发帖提到的无聊部分
那么，以下就是我实际所做的，我想如实相告，因为大多数技术报告都会跳过这部分，直接切入巧妙的有效载荷。
我在第二个租户上创建了一个管理员账户，逐一测试了每个功能，并记录了 Burp 捕获到的所有请求。随后，我提取了浏览器的会话 cookie，将其添加到这 150 个请求中，然后逐一重放了这些请求。
就这么简单。不需要定制工具，也不需要 12 个阶段的重构流程。只需一个查看器 cookie 和大量右键点击操作。
Press enter or click to view image in full size
我知道我应该重命名这些标签页，把重点放在寻找伴侣上
其中149人给出了相同的回答：
HTTP/1.1 403 Forbidden
.........
.........
.........
.........
{"error":"Insufficient permissions"}
一遍又一遍又一遍。到了一定时候，你就不去看回复内容了，而是开始根据状态码列的颜色来匹配模式。而这正是容易漏看细节的时候，所以我强迫自己放慢速度，认真查看每一条。
幸好我这么做了，因为137号是绿色的。
第 0 步：回答者
POST /api/admin/action HTTP/1.1
Host: app.example.com
Cookie: session=<viewer_session>
Content-Type: application/x-www-form-urlencoded
Action=ViewSettings
HTTP/1.1 200 OK
.......
.......
.......
{"success":true,"settings":{...}}
一位查看者刚刚读取了存储库设置。
这已经算是一份报告了。访问控制存在漏洞，仅具有只读权限的角色也能访问管理员功能，写份报告，领走 500 美元的 Medium 漏洞赏金，然后继续前进。
但这件事总让我觉得有些别扭。
再看一下这个请求。其中既没有资源 ID，也没有对象引用，更没有查询条件。整个请求就是字符串中一个 VERB 动词 。 Action=ViewSettings……服务器接收一个名称，然后……就执行那个名称所代表的操作了吗？
如果那是一个普通的 switch语句或白名单，那也行，无所谓。但它看起来不像一个 switch 语句。看起来像是将该值拼接成了某个东西 。
而且，那些被拼接进路径中的元素是可以遍历的。
第一步：最愚蠢的测试
在采取任何巧妙措施之前，我想先弄清楚到底是哪一种情况：白名单还是路径解析。
于是，我发送了能想到的最没用的有效载荷。
POST /api/admin/action HTTP/1.1
Cookie: session=<viewer_session>
.......
.......
.......
Action=./ViewSettings
HTTP/1.1 200 OK
.......
.......
.......
{"success":true,"settings":{...}}
Still 200。
而这就是整个研究结果，就浓缩在这个一个字符里。
./ViewSettings这不是一个有效的操作名称。如果后端将我的输入与允许字符串列表进行比对，这会立即被拒绝，因为它根本不在列表中。没有任何一种情况会允许白名单接受它。
但 ./表示“同一目录，不移动”。这是一个无操作。对于路径解析器而言， ./ViewSettings和 ViewSettings指的是同一个位置。
服务器将它们视为同一个地方。
所以它是一条路径。它从来都不是一个操作名称，而是一段被附加到某个内部 URL 上的路径，并在内部调用发出之前被解析。
第 2 步：走上去
现在我不再去猜测动作名称了。我正在进行导航。
如果 ./问题解决了， ../就解决了。向上提升一级，然后回到管理员所在的位置：
POST /api/admin/action HTTP/1.1
Cookie: session=<viewer_session>
..........
..........
..........
Action=../admin/viewsettings
HTTP/1.1 200 OK
无论内部基数是什么，它最终都简化成了类似于以下的形式：
/internal/action/../admin/viewsettings
↓
/internal/admin/viewsettings
又是两百。
到了这一步，我已经完全不在乎设置了。设置从来都不是最终目标。真正的收获在于：我现在能够以内部 API 的身份 ，从一个查看者会话中向内部 API 发送请求，而无论另一端是什么服务，它都完全不知道是查看者在操控。
第3步：我一直致力于实现的这一步
还记得我在“无聊阶段”映射的那些管理路由吗？其中一个是晋升端点。它在路径中接受一个用户 ID，并将该用户晋升为管理员。
向上两层到达 API 根目录，然后直接进入：
POST /api/admin/action HTTP/1.1
Host: app.example.com
Cookie: session=<viewer_session>
Content-Type: application/x-www-form-urlencoded
..........
..........
..........
Action=../../api/admin/promote/<my_user_id>
HTTP/1.1 200 OK
..........
..........
..........
{"message":"User promoted to admin successfully"}
刷新了仪表盘。
管理员。$X,000。
顺便提个让我忍俊不禁的小插曲：几个月前，在回应 FahemSec 的挑战时，我几乎用了完全一样的手法
userId，通过遍历一个机器人的参数转换为/api/admin/promote/。真心向他们致敬，他们的挑战绝非那种“谜题盒”式的无稽之谈，而是基于真实应用中实际存在的错误构建的。我记得当时还想，这种代码绝对没人会部署。结果，真有人把它部署了。
为什么这招真的奏效了
两个不同的错误，而你都需要这两个错误。
Action 值被直接放入路径中，未进行任何清理。既未进行规范化处理，也未去除 ../，也没有针对已知操作名称的允许列表检查。该开发者显然认为，该值只会是其自身前端发送的字符串之一。
内部调用默认被视为可信。公共网关正确地执行了角色验证，这就是为什么 149 个端点返回了 403 错误。但其背后的服务间调用完全跳过了这一验证，因为显然内部调用者已经获得了授权。因此，当我能够发起内部请求时，我以“非特定用户”的身份预先通过身份验证，而后端将此识别为“可信”。
仅凭其中任何一种情况都能应付。如果进入一个仍会检查角色的服务，你什么也得不到。一个可信的内部网状网络，如果其中没有用户控制的路由，你什么也得不到。将这两者结合起来，一个只读账户就能给自己写入管理员角色。
我想让你从中得到的启示是
这个漏洞最巧妙之处就在于它只有一个字符长。 .
真正发现问题的原因在于，系统重新播放了 150 个带有错误 Cookie 的请求，并且在第 118 个请求时没有走神。
当第一个端点响应时，报告已经生成——仅凭“查看器读取管理员设置”这一事实本身就已成立。那$X,000 的奖励，源于我多问了一个问题，即询问它为何会响应，而不是直接截图显示 200 状态码并点击提交。这与我获得的第一笔赏金时的直觉如出一辙：当时也是在回过头来再次向该端点发起请求后，一个“中等”级别的漏洞才最终转化为实际的奖金。
不要止步于最初的200。这200只是门，而不是房间。
觉得本文内容对您有启发或帮助？ 点个关注➕，获取更多深度分析与前沿资讯！
👉 往期精选
逻辑漏洞：邮箱注册 tips #11
非常用403绕过 Tips
Android IPC 漏洞利用系列
新技术绕过文件上传
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：漏洞集萃 Adhamkhairy Adhamkhairy《通过../../ 提权为管理员》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论