文章总结： 文档披露了ExampleCenterSaaS平台存在的API权限提升漏洞，调度员角色可通过直接调用团队创建端点绕过前端限制，执行创建团队、复制团队结构、指派团队负责人等管理员操作。漏洞根本原因是后端缺乏授权检查，导致低权限用户可获得类似管理员控制权，白帽小哥因此获得800美元赏金。文章强调后端授权才是真正安全层，建议测试时勿依赖前端限制。 综合评分： 82 文章分类： 漏洞分析,WEB安全,红队,渗透测试,安全开发
【$800】通过API实现的权限提升 —— 从调度员到管理员
原创
骨哥说事 骨哥说事
骨哥说事
2026年4月24日 09:32 上海
在小说阅读器读本章
去阅读
| | | — | | 声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。 |
#
#
防走失：https://gugesay.com
不想错过任何消息？设置星标↓ ↓ ↓
#
一位国外白帽小哥近期在一个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
- END –
感谢阅读，如果觉得还不错的话，动动手指给个三连吧～
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：骨哥说事 骨哥说事 骨哥说事《【$800】通过API实现的权限提升 —— 从调度员到管理员》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论