IDOR 藏在第二个标识符里:用双账号 Shadow Replay 发现 BOLA

Sat, 04 Jul 2026 00:00:00 +0000

每篇 IDOR 教程都给你同一套操作:找到 /api/orders/48210,把它改成 48211,看有没有 200。这套操作训练你去攻击那个应用最可能会检查的标识符。URL 路径里的主键,正是框架的 @authorize 注解所在之处、ORM 收窄查询之处、评审聚焦之处。它是诱饵。你 fuzz 它,拿到一堆 403,判定这个接口安全,然后径直从漏洞旁边走过。

因为漏洞几乎从不在你看得见的那个 ID 里。它在第二个标识符里——那个应用压根忘了它也是个标识符的东西。

路径里的 ID 是他们会检查的那个。漏洞藏在 request 携带的第二个标识符里——body 里的 account_id、header 里的 tenant、GraphQL 别名里的 id——那个没人为它写过授权规则的东西。

换的是次要标识符,不是路径

下面是有回报的那种形态。一个 request 会同时以两种方式框定一个对象:路径里的一个资源 ID,以及别处的一个所有权 ID——一个 JSON 字段、一个 header、一个隐藏的表单值。路径里的 ID 会被校验。所有权 ID 会被信任。

POST /api/v2/reports/generate HTTP/2
authorization: Bearer <attacker token>
content-type: application/json

{ "report_id": "attacker-owned-uuid",
  "account_id": 5561,          ← victim's account, not yours
  "format": "pdf" }

report_id 属于你,所以每一层资源级检查都干净利落地通过。但 account_id 决定的是报表包含谁的数据,而处理程序直接从 body 里读取它,根本没问你的会话是否有权访问账号 5561。路径原封不动。只改 account_id——或 org_id、tenant_id,或那个带外承载同一含义的 X-Account-Id header。这就是大多数 hunter 从不做的那一步,因为教程训练出了错误的条件反射。

Access-Control on Crusader Research

IDOR 藏在第二个标识符里:用双账号 Shadow Replay 发现 BOLA

换的是次要标识符,不是路径