越权访问与 IDOR 入门

写在前面：合法学习边界

本文讲解越权访问和 IDOR（Insecure Direct Object Reference）。所有测试都必须在自建靶场或明确授权环境中进行。请不要对真实系统进行改 ID、越权读取、越权修改或未授权枚举。

越权访问的核心是：系统没有正确判断“这个用户能不能操作这个对象”。

常见类型有：

1
2
3
横向越权：访问同级别其他用户的数据
纵向越权：低权限用户访问高权限功能
对象级越权：直接访问不属于自己的资源

IDOR 就是“不安全的直接对象引用”。

当接口使用用户可控的对象标识时，如果服务端没有再次校验归属关系，就可能出现问题。

典型接口：

1
2
3
GET /api/orders/123
GET /api/profiles/1001
DELETE /api/files/77

如果 123 这个订单不属于当前用户，但系统仍然返回，就可能是 IDOR。

1
2
3
4
5
6
7
用户 ID
订单 ID
文件 ID
发票 ID
聊天记录 ID
项目 ID
会话 ID

这些 ID 如果直接来自 URL 或参数，都要重点检查授权。

前端隐藏按钮、隐藏菜单并不等于安全。真正有效的授权判断必须在服务端完成。

前端只做展示，后端才做控制。

典型验证方法：

1
2
3
4
1. 获取 A 用户接口
2. 替换成 B 用户对象 ID
3. 观察是否返回数据
4. 观察是否能修改或删除

但必须强调：这些步骤只能在授权范围内做。

越权/IDOR 能造成：

1
2
3
查看/修改他人数据
水平越权（平级用户）与垂直越权（提升权限）
数据泄露与业务受损

风险等级：高。

每次访问对象前，都检查归属关系。

避免连续、可预测、可遍历的 ID。

只给当前用户最小可见集合。

用户角色和可访问资源要绑定检查。

记录越权尝试、失败访问和异常对象请求。

1
2
3
4
服务端统一鉴权，不信任前端/ID 参数
对象访问前校验归属与权限（对象级授权）
ID 使用不可预测值或做随机化
修复后复测：替换他人 ID 无法访问

示例：

1
2
3
发现：用户 A 将订单 ID 改成用户 B 的订单 ID 后，接口仍返回订单详情。
风险：可能导致敏感订单、支付信息或业务数据泄露。
建议：服务端增加对象归属校验；不可信任客户端对象 ID；增加访问审计。

越权和 IDOR 的本质不是“会不会改 URL”，而是“后端有没有真正校验归属”。它是 Web 安全里最基础也最容易被忽视的一类问题。