文章总结： 作者分享了一起因RBAC配置错误导致获得超2万美元赏金的案例。测试中通过绕过移动端防护发现其与Web后台共用API，利用后端只校验Token不校验角色的逻辑缺陷，攻击者成功从普通用户提权为超级管理员并接管多个门户。文章强调了移动端资产的重要性及权限校验缺失的严重后果，并提及利用AI辅助分析JS文件以提高挖掘效率。 综合评分： 90 文章分类： 渗透测试,SRC活动,漏洞分析,实战经验,移动安全

---

一个简单的 RBAC 错误如何导致超过 2 万美元的管理员接管

haidragon haidragon

安全狗的自我修养

2026年3月6日 12:12 湖南

官网：http://securitytech.cc

2025 年年底，我发现了多个漏洞，而它们都源自一个非常简单的根本问题。有趣的是：这并不是疯狂的远程代码执行，也不是零日漏洞，更不是高级加密绕过，而是看起来非常正常的东西。正常到一开始我几乎忽略了它。

---

阶段 1：对私人项目的侦察（YesWeHack）

目标是 YesWeHack 上的一个私人项目，范围很大。大部分使用了通配域名，比如 *.[tldr.com](http://tldr.com/)，意味着有大量子域需要探索。 所以我先用自动化工具开始：

按 Enter 或点击查看原图

经过一番挖掘，我发现了一个有趣的东西：一个后台 管理员门户（Backoffice Admin Portal）。

---

阶段 2：React JS、JS 文件与隐藏 API 映射

该门户基于 ReactJS 构建。如果你做过 SPA 应用侦察，就知道套路：JavaScript bundle 往往会暴露 API 接口。 我开始分析 JS 文件，果然发现很多端点。

按 Enter 或点击查看原图

问题是：

所有接口都需要认证，而门户没有注册功能。我尝试了一些常规方法：

• SQL 注入
• 默认凭证
• 认证篡改
• 等等

都没有成功。我暂停了，但在 Burp 和 Google Docs 里仔细记录了所有操作。这一决定后来救了我。

---

阶段 3：一个月后，感觉不对

大约一个月后，我回到同一私人项目，复查旧笔记时有种感觉：“可能我漏掉了什么。” 于是我重新开始，这次检查主域 [tldr.com](http://tldr.com/)，发现了之前没关注的东西：移动应用。

为什么之前没看？因为技术上移动应用不在范围内，我以为只是浪费时间。结果……这就是改变游戏规则的关键 🙂

---

阶段 4：移动应用分析

我下载并安装了移动应用，先正常运行以理解流程。

发现了一个新的 注册功能。 为了更深入，我尝试用 Burp Suite 截取流量，但应用有：

• Root 检测
• 模拟器检测
• SSL Pinning
• Frida 检测

所以我必须绕过这些保护：

• 使用 KernelSU 绕过 root 检测
• 使用混淆 Frida 绕过检测

绕过 SSL Pinning 后拦截流量，分析 API 调用，发现移动端访问的是：

api-ddd.tldr.com

和后台管理员门户使用的后端完全相同。事情变得有趣起来。

---

阶段 5：被忽略的逻辑漏洞

我用移动应用注册了一个普通用户，然后尝试用相同凭证登录后台门户。UI 登录失败，但 Burp 历史记录显示：

GET /user/v2/me

成功返回。

按 Enter 或点击查看原图

说明：后端接受了我的 Token。 这时我怀疑存在权限隔离问题，或者更糟——访问控制失效。

---

阶段 6：完全提权与多门户接管

当时我还没完全确认，只知道：

• 我的 Token 被后端接受
• 后端只在登录 API 上做 RBAC 验证
• /user/v2/me 请求成功 感觉不对

于是我测试假设：如果后端只验证 Token 而不验证角色，直接访问管理员接口会发生什么？

我回到之前提取的 JS API 列表，用普通用户 Token 测试：

GET /user/v2/users
GET /user/v2/acl/internal

按 Enter 或点击查看原图

惊讶地发现……普通用户 Token 就能访问 :))))

按 Enter 或点击查看原图

这已经很糟糕了，但后来我发现更严重的问题。

---

🔥 完全提权：将自己设为超级管理员

我发现一个可以修改自己访问权限的接口：

POST /user/v2/acl

按 Enter 或点击查看原图

请求体可以指定角色，我尝试发送：

按 Enter 或点击查看原图

天啊 :)))) 没有角色验证，没有授权检查，竟然成功了。 我成功将自己的账户添加为 超级管理员。 这不再只是数据泄露，而是：

• 垂直权限提升
• RBAC 崩溃
• 完整管理员账户创建

我可以：

• 管理所有用户
• 修改角色
• 访问敏感数据
• 控制系统配置

按 Enter 或点击查看原图

---

意外发现：另一个后台也用同一 API

深入挖掘时，我发现另一个环境：

invoice.tldr.com

测试后发现，它使用同一后端 API。

这意味着： 一个提权 Token 可以同时接管 两个管理员门户，大幅提升了影响：

• 跨门户提权
• 共享后端，无隔离
• 多租户授权失败

根本原因仍是：

• 后端只验证 Token 是否有效
• 从未验证角色是否被授权

按 Enter 或点击查看原图

---

使用 AI 扩展分析

由于范围庞大，JS bundle 很大，我怕遗漏。 我用 Claude AI 辅助：

• 分析提取的 JS 文件
• 系统化映射所有 API
• 识别请求体结构
• 按权限等级分组 API
• 整理与清理报告

注意： 所有漏洞验证仍由 Burp 手动完成，AI 仅加快分析和报告速度，使我从一个漏洞扩展到多条高质量漏洞报告。

按 Enter 或点击查看原图

---

报告与奖励更新

我将报告拆分为：

• 不同 API 端点
• 访问类型（读/写/管理员控制）
• 严重性
• 受影响门户

Alhamdulillah，确认总奖励已达 💰 20,000+ 美元，还有 9 条报告待处理，可能还会增加。

按 Enter 或点击查看原图

---

核心问题其实很简单

一切源于一个简单错误： 后端没有正确实施基于角色的授权（RBAC）。

缺失：

• 正确的 RBAC 验证
• 门户之间的角色隔离
• 权限边界控制

关键问题：

后端是只验证 Token 是否有效，还是同时验证角色权限？

在这个案例中，只验证了 Token。 另一个重要教训是：有时候我们会忽略一些东西，因为认为它不重要。 我最初忽略移动应用，因为它不在范围内，认为只是浪费时间。但正是移动应用连接了整个漏洞链，成为真正的突破点。

有时候，最大的突破并非来自复杂技术，而是重新审视我们曾经忽略的部分。

• 公众号:安全狗的自我修养
• vx:2207344074
• http://gitee.com/haidragon
• http://github.com/haidragon
• bilibili:haidragonx

#

• 

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon haidragon《一个简单的 RBAC 错误如何导致超过 2 万美元的管理员接管》