The Ultimate IDOR Testing Checklist (2026 Edition)

查看原文 / View Original 编辑 / Edit

The Ultimate IDOR Testing Checklist (2026 Edition)

IDOR 测试终极清单（2026 版）

Phase 1: Setup & Target Identification

第一阶段：环境设置与目标识别

  • [ ] Create Test Accounts: Create two accounts (Attacker and Victim) for safe testing of destructive requests (POST/PUT/DELETE). [ ] 创建测试账户： 创建两个账户（攻击者和受害者），以便安全地测试破坏性请求（POST/PUT/DELETE）。
  • [ ] API Identification: Find JSON endpoints over rendered HTML. [ ] API 识别： 优先寻找 JSON 端点，而非渲染后的 HTML。
  • [ ] Sensitivity Analysis: Target critical functions first (password reset, account recovery, financial data, DMs, user management). [ ] 敏感性分析： 优先针对关键功能进行测试（密码重置、账户恢复、财务数据、私信、用户管理）。
  • [ ] ID Audit: Check if endpoint is private or public and contains any kind of ID parameter. [ ] ID 审计： 检查端点是私有的还是公开的，并确认是否包含任何类型的 ID 参数。
  • [ ] ID Leakage: Check for IDs leaked via other API endpoints or public pages (public profile pages, listings). [ ] ID 泄露： 检查是否有 ID 通过其他 API 端点或公共页面（如公开个人资料页、列表页）泄露。
  • [ ] Map Clients: Collect web/mobile clients, open APIs from decompiled mobile (jadx/apktool), and swagger/openapi if present. [ ] 映射客户端： 收集 Web/移动端客户端，通过反编译移动端应用（jadx/apktool）获取 API，并检查是否存在 Swagger/OpenAPI 文档。

Phase 2: Direct ID Substitution & Enumeration Technique

第二阶段：直接 ID 替换与枚举技术

  • Scenario to Test (Attacker ID=10, Victim ID=9) 测试场景（攻击者 ID=10，受害者 ID=9）
  • Basic ID Flip: GET /api/v5/users/10 -> GET /api/v5/users/9 基础 ID 翻转： GET /api/v5/users/10 -> GET /api/v5/users/9
  • Incremental Numeric Brute Force: Loop over sequential numeric IDs (decrement/increment from own ID). 递增数字暴力破解： 遍历连续的数字 ID（从自己的 ID 开始递减/递增）。
  • Non-Numeric ID Substitution: Replace param with email / username / UUID. 非数字 ID 替换： 将参数替换为电子邮件、用户名或 UUID。
  • Complex ID Brute Force: Brute force short alphanumeric segments (last 1–4 chars). 复杂 ID 暴力破解： 暴力破解短的字母数字片段（最后 1-4 个字符）。
  • Predictable ID / Combined ID: /user/2222/data/3333 — change one or both parts. 可预测 ID / 组合 ID： /user/2222/data/3333 — 修改其中一部分或两部分。
  • Hashed/Derived IDs (MD5/SHA1 pattern): Detect hashed IDs, create accounts to infer mapping, try replacing derived hashes. 哈希/派生 ID（MD5/SHA1 模式）： 检测哈希 ID，通过创建账户推断映射关系，尝试替换派生出的哈希值。

Phase 3: Path and URL Manipulation Bypasses

第三阶段：路径与 URL 操作绕过

  • Trailing Slash: GET /api/v5/users/9 -> GET /api/v5/users/9/ 尾部斜杠： GET /api/v5/users/9 -> GET /api/v5/users/9/
  • Double Slashes / Obfuscated Path: GET /api/v5/users//9 or GET /api/v5/users/./9 双斜杠 / 混淆路径： GET /api/v5/users//9 或 GET /api/v5/users/./9
  • Case Variation / Key Swapping: /api/User?id=123 vs /api/user?id=123 or user_id ↔ userid 大小写变体 / 键名交换： /api/User?id=123 对比 /api/user?id=123 或 user_id ↔ userid
  • Path Traversal / Mixed Paths: POST /users/delete/my_id/../victim_id 路径遍历 / 混合路径： POST /users/delete/my_id/../victim_id
  • Wildcard Substitution: GET /api/users/* or GET /api/users/user_id 通配符替换： GET /api/users/* 或 GET /api/users/user_id
  • Fuzz Keywords in Path: GET /api/v3/users/12345 -> /api/v3/users/all 路径关键词模糊测试： GET /api/v3/users/12345 -> /api/v3/users/all
  • SQLi Quick Check: GET /api/v3/users/12345' SQL 注入快速检查： GET /api/v3/users/12345'

Phase 4: Logic & Endpoint Bypasses

第四阶段：逻辑与端点绕过

  • Version Downgrading: GET /v3/user/111 -> GET /v1/user/111 版本降级： GET /v3/user/111 -> GET /v1/user/111
  • Sub-Endpoint Variant: Full profile endpoint vs less-protected detail endpoint. 子端点变体： 完整资料端点对比保护较弱的详情端点。
  • Missing Function Level Access / Case Variants: GET /admin/profile -> GET /Admin/profile 功能级访问缺失 / 大小写变体： GET /admin/profile -> GET /Admin/profile
  • Owner Flag / Role Field Differences: Look for “owner”: true/false, “is_admin”, role fields returned in body and try to toggle via params or token swap. 所有者标志 / 角色字段差异： 查找响应体中的 “owner”: true/false、“is_admin” 等角色字段，并尝试通过参数或令牌交换进行切换。
  • Token / Authorization Swap: Replace access_token/API key with victim’s or other known tokens to test token-scoped checks. 令牌 / 授权交换： 将 access_token/API 密钥替换为受害者或其他已知令牌，以测试令牌作用域检查。
  • Cached Role Check / Session Race: Logout/login, change roles, re-test to detect cache-based false-negatives. 缓存角色检查 / 会话竞争： 通过注销/登录、更改角色并重新测试，检测基于缓存的误报。
  • Token Binding Flaws: Test by reusing a valid token issued for resource A against resource B. 令牌绑定缺陷： 通过将为资源 A 签发的有效令牌用于资源 B 来进行测试。
  • Frontend–Backend Desync / Logic Mismatch: Test by sending requests with IDs that the frontend never exposes and see if backend performs the action. 前端-后端不同步 / 逻辑不匹配： 发送前端从未暴露的 ID 请求，观察后端是否执行了相应操作。

Phase 5: Parameter & Body Abuse

第五阶段：参数与请求体滥用

  • Add Parameter Bypass: GET /api_v1/messages -> ?user_id=victim_uuid 添加参数绕过： GET /api_v1/messages -> ?user_id=victim_uuid
  • Multi-ID / Comma Separation: GET /api/users?id=10,9 多 ID / 逗号分隔： GET /api/users?id=10,9
  • Alternate Separators: {"Account": 2222;1111} or 2222.1111 替代分隔符： {"Account": 2222;1111} 或 2222.1111
  • HTTP Parameter Pollution (HPP): ?user_id=10&user_id=9 HTTP 参数污染 (HPP)： ?user_id=10&user_id=9
  • JSON Array/Object Wrap: {"userid":[123]} or {"userid":{"userid":123}} JSON 数组/对象包装： {"userid":[123]} 或 {"userid":{"userid":123}}
  • Null Termination (%00): GET /api/users/9%00 空字节终止 (%00)： GET /api/users/9%00
  • Deserialization / Object Injection: Replace user_id=9 with user={"id":9} or send serialized payloads to influence server-side logic. 反序列化 / 对象注入： 将 user_id=9 替换为 user={"id":9}，或发送序列化载荷以影响服务器端逻辑。

Phase 6: Encoding, Hashing, and Obfuscation Bypasses

第六阶段：编码、哈希与混淆绕过

  • Leading Zeros: GET /api/users/009 前导零： GET /api/users/009
  • Percentage Twenty Bypass (%20): GET /api/users/9%20 空格编码绕过 (%20)： GET /api/users/9%20
  • Type Confusion: GET /api/users/"9" (String vs Integer) 类型混淆： GET /api/users/"9"（字符串与整数）
  • Decode and Re-Encode ID: Decode MTIzNg -> change -> re-encode. ID 解码与重编码： 解码 MTIzNg -> 修改 -> 重新编码。
  • Hex / MD5 / SHA hashes: Detect patterns and attempt crafted/partial replacements. 十六进制 / MD5 / SHA 哈希： 检测哈希模式并尝试进行伪造或部分替换。

Phase 7: Protocol & Data Format Change Bypasses

第七阶段：协议与数据格式变更绕过

  • Change HTTP Method: GET -> POST/PUT/DELETE 更改 HTTP 方法： GET -> POST/PUT/DELETE
  • Change File Type: /user_data/2341.json -> .xml / .txt 更改文件类型： /user_data/2341.json -> .xml / .txt
  • Change Content-Type: application/json ↔ application/x-www-form-urlencoded ↔ application/xml 更改 Content-Type： application/json ↔ application/x-www-form-urlencoded ↔ application/xml
  • X-HTTP-Method-Override: Use header X-HTTP-Method-Override: DELETE to bypass method checks. X-HTTP-Method-Override： 使用请求头 X-HTTP-Method-Override: DELETE 绕过方法检查。
  • Protocol-specific APIs (gRPC / protobuf): Test non-HTTP RPC endpoints for IDOR patterns. 协议特定 API (gRPC / protobuf)： 测试非 HTTP RPC 端点是否存在 IDOR 模式。
← 返回新闻列表 / Back to news list