在 Web 安全领域，越权漏洞（Broken Access Control）长期占据 OWASP Top 10 的榜首位置。其中，IDOR（Insecure Direct Object Reference，不安全的直接对象引用）是最常见也最容易被忽视的一类越权漏洞。本文将从实战角度出发，系统讲解 IDOR 漏洞的挖掘思路，并通过水平越权和垂直越权的真实案例，帮助安全从业者建立完整的测试方法论。
什么是 IDOR 越权漏洞
IDOR 的本质是应用程序在访问对象时，未对当前用户的权限进行充分校验，导致攻击者可以通过修改请求中的对象标识符（如用户 ID、订单号、文件 ID 等），访问或操作本不属于自己的资源。
根据越权方向的不同，IDOR 通常分为两类：
- 水平越权：攻击者访问同级用户的资源。例如，用户 A 通过修改
user_id=1001为user_id=1002，查看用户 B 的订单信息。 - 垂直越权：攻击者访问更高权限级别的功能或数据。例如，普通用户通过直接访问管理员接口
/admin/deleteUser，执行只有管理员才能操作的功能。
IDOR 漏洞的常见触发点
在挖掘 IDOR 之前，需要先了解哪些位置最容易出现这类漏洞。以下是实战中高频出现的触发点：
- URL 路径参数：如
/api/user/123/profile、/order/detail/456 - 查询字符串参数：如
?user_id=123、?order_no=20230101 - POST 请求体字段：如
{"userId": 123, "action": "view"} - HTTP 请求头：如
X-User-Id: 123、Cookie中的用户标识 - GraphQL 查询参数：如
query { user(id: 123) { email } } - 文件路径引用：如
/download?file=report_123.pdf
水平越权实战案例
案例一：修改用户 ID 查看他人订单
某电商平台提供订单详情接口：
GET /api/order/detail?order_id=20231015001 HTTP/1.1
Host: shop.example.com
Cookie: session=userA_session
用户 A 登录后，将 order_id 修改为 20231015002，发现返回了用户 B 的订单详情，包含收货地址、手机号、商品信息等敏感数据。服务端仅校验了用户是否登录，但未校验该订单是否属于当前用户。
挖掘技巧：在测试时，使用两个账号（A 和 B）分别登录，用 A 的会话去请求 B 的资源 ID，观察是否返回 B 的数据。这是最基础也最有效的水平越权测试方法。
案例二：修改 POST 请求体中的用户标识
某社交平台的消息删除接口：
POST /api/message/delete HTTP/1.1
Host: social.example.com
Cookie: session=userA_session
Content-Type: application/json
{"message_id": 8801}
用户 A 尝试将 message_id 修改为 8802（属于用户 B 的消息），发现服务端成功删除了用户 B 的消息。这是一个典型的水平越权 + 写操作漏洞，危害等级更高。
挖掘技巧：不要只关注 GET 请求，POST、PUT、DELETE 等写操作接口同样需要重点测试。写操作越权往往能造成更大的业务影响。
垂直越权实战案例
案例三：普通用户直接访问管理员接口
某后台管理系统使用基于角色的访问控制（RBAC），但部分接口的前端路由做了权限限制，后端却未做校验：
GET /admin/user/list HTTP/1.1
Host: admin.example.com
Cookie: session=normal_user_session
普通用户登录后，直接访问 /admin/user/list，成功获取了所有用户列表。进一步测试发现，/admin/user/delete?id=5 同样可以执行删除操作。
挖掘技巧：垂直越权的核心思路是“功能级访问控制缺失”。测试时，使用低权限账号，尝试直接访问高权限接口。可以通过以下方式发现隐藏接口：
- 分析前端 JavaScript 文件中的路由定义
- 使用目录扫描工具（如 dirsearch、ffuf）枚举
/admin、/manage、/internal等路径 - 抓取管理员操作时的请求，用普通用户会话重放
案例四：通过参数污染提升权限
某 SaaS 平台的用户注册接口：
POST /api/register HTTP/1.1
Host: saas.example.com
Content-Type: application/json
{"username": "attacker", "password": "123456", "role": "user"}
攻击者尝试将 role 修改为 admin，发现注册后的账号直接拥有管理员权限。服务端信任了客户端传入的角色参数，未在服务端强制指定默认角色。
挖掘技巧：关注所有与权限、角色、用户组相关的参数。常见参数名包括 role、isAdmin、userType、permission、group 等。尝试修改这些参数的值，观察权限是否发生变化。
IDOR 漏洞挖掘的自动化思路
手动测试虽然精准，但效率有限。以下是几种自动化辅助思路：
- 参数值遍历：使用 Burp Suite Intruder 或 ffuf，对 ID 类参数进行数字递增遍历，观察响应长度和状态码变化。
- 双账号对比：使用 Autorize 等 Burp 插件，自动用低权限会话重放高权限请求，快速发现越权点。
- API 文档分析：如果目标提供 Swagger/OpenAPI 文档，可以批量提取所有接口，逐个测试权限校验。
- JS 文件爬取：通过爬取前端 JS 文件，提取隐藏的 API 路径和参数名，扩大测试面。
防御建议
对于开发者而言，防御 IDOR 的核心原则是：永远不要信任客户端传入的对象标识符，必须在服务端校验当前用户是否有权访问该对象。
具体措施包括：
- 使用间接引用映射（如将真实 ID 映射为随机 UUID）
- 在每次数据访问时，校验
resource.owner_id == current_user.id - 对功能级接口实施统一的权限中间件，避免遗漏
- 遵循最小权限原则，默认拒绝所有未明确授权的访问
总结
IDOR 越权漏洞的挖掘并不依赖高深的技术，而在于细致的观察和系统的测试方法。水平越权关注“同级用户之间的数据隔离”，垂直越权关注“低权限用户对高权限功能的访问”。在实际测试中，建议结合双账号对比、参数遍历和 JS 分析等手段，覆盖 GET/POST/PUT/DELETE 等各种请求方式，才能最大程度地发现潜在的越权风险。
未经允许不得转载：任鹏个人博客 » IDOR 越权漏洞挖掘指南：水平越权与垂直越权的实战案例分析
