IDOR 越权漏洞攻防

为什么改 URL 里的 ID 不够

多数工程师对 IDOR 的理解停留在把 /api/users/123 改成 /api/users/124。但真实业务里，对象标识符远不止出现在路径参数中——它还可能出现在请求体、查询字符串、Cookie、JWT claim、GraphQL 变量甚至消息队列的消息头里。只改 URL 参数的测试方式会漏掉大量攻击面。

另一个常见误区是把 IDOR 和 BFLA 混为一谈。IDOR（即 BOLA，OWASP API Top 10 A1）的核心是访问了不属于自己的对象；BFLA 的核心是调用了自己无权使用的功能。前者是对象级越权，后者是功能级越权，测试路径完全不同。

这个技能做了什么

技能将 IDOR/BOLA 检测拆成一条可执行的流水线：

• 全位置 ID 枚举：覆盖请求体、查询字符串、Cookie、JWT claim 和消息头中的 ID 暴露，不局限于 URL 路径参数。
• ID 类型指纹分析：自增整数容易预测；UUID v4 需要从其他端点收集样本；UUID v1 基于时间戳和 MAC 生成，理论上可推算相邻 ID；哈希 ID 可以尝试对自增整数做哈希匹配；编码 ID 则需解码后篡改再重新编码。
• A-B 测试方法论：注册两个账号 A 和 B，用 B 的凭证访问 A 创建的对象，这是最系统的 IDOR 验证方式。
• 8 类系统化测试：覆盖直接 ID 替换、可预测 UUID、批量操作接口、导出/下载端点、关联对象 IDOR、资源替换、写入型 IDOR（PUT/PATCH/DELETE）和嵌套对象访问。

针对容易被遗漏的隐蔽攻击面，技能还覆盖了：

• HTTP 方法越权：当 GET /resource/1234 有权限校验时，检查 POST、PUT、PATCH、DELETE 是否做了同等校验——授权逻辑常按方法实现，边缘情况容易被忽略。
• 参数污染与类型混淆：当 id=1234 有校验时，尝试重复传参或利用 JSON 中字符串与整数的类型差异，部分 ORM 对两种类型的处理方式不同。
• 间接 IDOR（引用链）：应用在对象 A 上校验了权限，但未校验被引用对象 B 的归属——例如通过附件 ID 直接访问子资源，绕过父端点的授权检查。GraphQL 中内联查询关联对象也可能触发同类问题。
• Mass Assignment：请求体中可能接受文档未列出的字段。通过对比管理员“创建用户”和普通用户“注册”的字段差异，或在 Burp 中模糊测试常见属性名（观察 200 与 400 的差异），可以发现隐藏的可写字段。
• 状态机滥用：当资源有状态字段时，测试能否跳过中间状态、回退状态，或直接修改其他用户资源的状态。
• BFLA 端点枚举：从 JS bundle 中提取管理端路由、在 Swagger/OpenAPI 文档中搜索 admin/internal/privileged 标签、枚举 /api/v1/admin/** 等路径，或对比普通用户与管理员的文档差异。
• ORM 过滤器链泄漏：针对 Django ORM、Prisma、Ransack（Rails）的过滤注入场景。

适用边界

该技能面向授权安全测试和漏洞赏金场景，不构成对未授权系统访问的指引。UUID v1 的时间可预测性在真实环境中可能因 MAC 地址不可获取而受限；哈希 ID 的逆向也取决于具体算法和盐值。参数污染与类型混淆的成功率高度依赖后端框架和 ORM 的实现细节，并非通用有效的绕过手段。测试时应结合目标系统的实际行为调整策略，而非机械套用清单。