0x01 故事背景
作为一名整天泡在代码里的安全专业大学生，最兴奋的事莫过于凌晨收到某知名国际众测平台的 Private Program邀请。
这次的目标是一个大型人力资源 SaaS 平台。这类平台承载着海量的候选人隐私：简历、联系方式、甚至是面试时的敏感评价。对于安全研究者来说，这不仅是技术挑战，更是对系统权限模型的一次“深度体检”。我当时就在想：在如此庞大的业务逻辑下，后端的越权防护真的能做到滴水不漏吗？
0x02 信息收集
进入测试环境后，我首先通过 Admin（管理员） 权限登录，观察系统的核心业务流。我发现该平台的核心功能之一是“候选人对话系统”。
在管理员视角下，每当我们点击一个候选人的对话框，浏览器都会向后端发送一个获取对话列表的 API 请求。
GET /app/companies/B4h-aSrUeJk/api/conversations我注意到这个请求的 EndPoint 非常标准，逻辑极度清晰。按照以往的经验，越是逻辑清晰、看起来“理所当然”的接口，往往越容易让开发者忽略掉深层的鉴权校验。
我心里萌生了一个疑问：如果我是一个完全没有权限的“白身”用户，直接通过脚本去撞这个接口，它会拦住我吗？
0x03 漏洞利用
为了验证这个猜想，我准备了两个账号：
- 高权限 Admin： 用于获取正常的 API 路径。
- 低权限 User： 没有任何查看候选人权限的普通员工账号。
第一步：捕获低权限 Session
我先登录了那个几乎“空壳”的低权限账号，拿到他的cookie这些登录凭证，便于后续测试
第二步：构造“越位”请求
我放弃了前端界面，直接在 Repeater 模块中手工构造了一个针对敏感接口的 GET 请求。我保留了接口路径，但把 Cookie 换成了那个低权限用户的凭证。
关键 Payload 示意（已脱敏）：
GET /app/companies/[REDACTED_COMPANY_ID]/api/conversations HTTP/2
Host: api.target-system.com
Cookie: session_token=[LOW_PRIVILEGE_USER_TOKEN];
X-Requested-With: XMLHttpRequest
User-Agent: Security-Research-Bot
Accept: */*
结果跳了出来：200 OK！
屏幕上弹出了一串长长的 JSON 报文，里面包含了该项目下所有候选人的私密数据：
{
"conversations": [
{
"id": 8XXX2,
"assigned_user_id": 1XX1,
"candidate_id": 4XXX3,
"email": "te*****st@example.com",
"first_name": "张*",
"last_name": "三",
"status": "answered",
"message_snippet": "这是候选人的私密对话内容..."
},
...
]
}那一刻的思考：
这简直是教科书级的 IDOR（水平越权）！后端虽然检查了我的 Session 是否有效（确定我是个合法用户），但它并没有检查我这个用户是否有权访问这个特定的公司资源。我像是一个拿着普通门票的游客，却因为后门没锁，直接走进了银行的保险库。
0x04 漏洞影响
不要小看这一个 API 接口。在实战场景下，这意味着：
只要攻击者拥有该平台的任意一个普通账号，就可以利用自动化脚本，遍历或直接调用该接口，瞬间导出全站的候选人隐私名单。对于一家人力资源公司来说，这种大规模的数据泄露不仅是品牌信誉的毁灭，更可能面临巨额的法律罚款。
0x05 防御与反思
从一名网安学生的视角来看，这个漏洞的产生并非因为技术有多复杂，而是因为“信任”。
漏洞根源（Root Cause）：
开发者在开发 API 时，往往采用了“隐式权限管理”，即认为：只要前端 UI 不显示这个按钮，普通用户就不会知道这个接口。但对于极客来说，UI 只是参考，API 才是真相。
加固建议：
- 强制性权限校验： 每一个涉及敏感数据的 Controller 动作，都必须包含一行权限检查代码，例如：authorize!(current_user, :read, Conversation)。
- 不可预测的 ID： 虽然不是根本解决办法，但使用 UUID 代替自增 ID 可以大幅增加攻击者遍历数据的难度。
- 零信任架构： 永远不要假设已登录的用户就是受信任的用户。每次请求，都要重新评估“他是谁”以及“他能做什么”。
结语：
这次挖掘再次印证了那句话：“安全不是一个产品，而是一个过程。” 哪怕是成熟的 SaaS 平台，也可能在最基础的权限逻辑上栽跟头。
报告提交后，厂商很快确认了漏洞并完成了修复
可惜了，最后被厂商降级了，确认我后面看了一下，这个漏洞利用有比较苛刻的前置条件，然后泄露的内容只有邮箱，危害依然有限
