一位国外白帽小哥近期在一个 SaaS 平台（ExampleCenter）发现了一个 访问控制失效 / 权限提升漏洞。该漏洞允许低权限用户（调度员角色）通过直接调用 API 来执行 编辑级别的管理操作。
因这一发现，白帽小哥获得了 700 美元的赏金，外加 100 美元的复测奖金。接下来将探讨这个漏洞的原理、其利用过程以及它为何如此重要。
了解目标
ExampleCenter 是一个用于管理组织内部团队、日程安排和工作流的 SaaS 平台。它遵循基于角色的访问控制模型：
- 编辑/管理员 → 可以管理团队、组织结构和权限
- 调度员 → 仅能将人员分配到现有团队中
为了维持适当的安全边界，只有 编辑和管理员 应该能够：
该平台的前端界面正确地执行了这一限制，显示着：
“只有编辑可以创建团队。”
至此，一切看起来都正确无误。
但根据其经验，小哥深知一个重要的事实：
如果某个功能在前端界面上被阻止……这并不意味着它在后端也被阻止。
好奇心的瞬间
小哥并未止步于此，而是打开了 Burp Suite，开始观察应用程序如何与后端通信。
他注意到，当切换选项卡或加载团队相关数据时，应用程序会调用某些 API 端点。这引发了一个想法：
如果团队创建功能在 API 中仍然存在，只是在前端界面中被隐藏了呢？
因此，小哥决定进行手动测试：先使用更高层级用户账号的请求来了解团队创建 API，然后尝试用调度员用户账号调用它。
漏洞所在：后端未执行授权检查
白帽小哥用其 调度员账户令牌，构造了一个指向团队创建端点的请求：
POST /api/services/v2/service_types/{id}/teams HTTP/2
Host: api.examplecenter.com
Authorization: Bearer <scheduler_token>
Content-Type: application/json
{
"data": {
"type": "team",
"attributes": {
"name": "SchedulerTeam",
"copy_team_members": true,
"secure_team": true,
"team_leader_ids": [attacker_id]
}
}
}
通常情况下，预期会收到 403 禁止 的响应。
但结果却是……
👉 200 成功 — 团队创建成功
不仅如此：
- 团队被成功创建
- 本人（即攻击者）被指派为 团队负责人
那一刻，情况变得清晰：
这不仅仅是前端界面的问题 —— 这是一个完全的授权绕过。
深入探索：能做到什么程度？
确认了这个初始漏洞后，白帽小哥开始探索能实际控制多少内容。
1. 复制现有团队
小哥注意到了一个参数：
"copy_from": "<team_id>"
于是其尝试克隆一个现有的团队。
结果：
- 完整的团队结构被复制
- 成员和配置被继承
- 小哥可以将自己指定为负责人
这使得漏洞从 简单的绕过 → 结构化的权限提升
2. 指派领导权
通过修改：
"team_leader_ids": [my_user_id]
小哥可以：
基本上就是控制了系统内部的层级结构
3. 批量创建团队
接着小哥测试了限制……
小哥可以快速地创建 成百上千个团队
这可能会导致：
4. 重复的团队名称
另一个虽小但有趣的问题：
导致混淆 + 潜在的误用
根本原因
这个漏洞归结于一个经典错误：
授权检查仅在前端界面上执行，未在后端 API 中执行
- 前端界面 → 正确地限制了调度员
- API → 盲目地接受请求
这种不匹配正是大多数 访问控制失效（BAC）漏洞的藏身之处。
影响
这不仅仅是理论上的，它有着实际的影响：
安全影响
- 权限提升（调度员 → 类似管理员控制）
- 未经授权的结构性更改
- 自我指派的领导角色
运营影响
- 批量创建团队 → 工作流程中断
- 重复团队 → 混淆
- 增加了清理开销
商业风险
- 损害基于角色的权限信任
- 违反最小权限原则
- 可能导致滥用或内部不正当使用
赏金与项目方回应
- 报告日期: 2025年12月20日
- 跟进处理日期: 2026年1月5日
- 严重性: 高 → 中
- 赏金: 700 美元 + 100 美元奖金
- 复测: 确认修复（API 现在返回 403）
关键要点
- 永远不要相信前端限制，一定要测试 API
- 后端授权才是 真正的安全层
- 权限提升漏洞常隐藏在：创建、复制和指派操作中
- 缺乏速率限制会放大影响
- 观察 API 调用 / JS 端点可以揭露隐藏的攻击面
结论
这个漏洞完美地展示了 前端的限制如何制造一种虚假的安全感。
从用户界面看，一切都很安全。
但在底层，API 允许低权限用户执行 管理员级别的操作。
这类漏洞在现代 SaaS 平台中极为常见——尤其是在存在复杂角色系统的地方。
对于漏洞猎人而言，应始终思考：
👉 “如果后端不关心（授权）呢？”
保持探索，祝你“黑得”愉快！🚀
类似的漏洞挖掘经验与工具分享，欢迎在 云栈社区 深入讨论。
原文：https://infosecwriteups.com/800-bounty-privilege-escalation-via-api-from-scheduler-to-team-admin-810bb8401a0f
发表于 3 小时前
|
查看: 6|
回复: 0
