IDOR 缺的是什么？
应用按请求里的对象标识读写资源，却没有核对请求者是否有权执行该动作。关键缺陷在对象级授权。[1]
037 / Web 与应用 / IDOR
知道编号，就能打开吗？
IDOR 越权访问 · IDOR
你已登录，也拿到了一个有效订单编号。但这笔订单属于别人。让服务器亲自回答：当前这个人，能对这个对象做这件事吗？
开始探索 ↓6–9 分钟
动手实验 · 场景判断 · 实用检查
动手实验 · 场景判断 · 实用检查
画面里的钥匙和储物柜是访问隐喻。能找到柜子，不代表有权打开它。
展开读图提示
读图提示
- 角色与机制
- 不同柜格比喻不同用户的数据对象，钥匙和柜格入口提示：能指定一个对象不代表有权打开它。
- 风险在哪里
- 应用若只按请求中的对象 ID 查找数据，而不核对当前用户权限，就可能让人越权读取或修改他人的对象。
- 防护与边界
- 服务端对每次对象操作做授权检查，并按当前用户权限限定查询；把 ID 改成难猜的 UUID 不能代替授权。
本课任务 / IDOR 越权访问
分清身份认证与对象授权，亲手验证一个跨账户访问边界。
- 拆开主体、对象与动作
- 观察缺少服务端检查的结果
- 解释 UUID 为什么不是权限
亲手探索 / 不同条件，不同结果
只改一个条件，访问结果就变了。
选择请求者和订单，再切换对象授权检查。比较“系统返回了什么”与“按业务规则应该允许什么”。只在本页虚构数据上操作。
对象授权实验
同一张通行证，能打开谁的订单？
策略：仅订单所有者可以读取。改变请求对象，再观察服务端是否真正检查所有权。
尚未运行。先调整实验条件，再查看结果；这里不会连接真实系统。
再试一次：先读自己的订单，再换成别人的订单。相同的 200 状态，在授权正确与越权时意味着什么？
OWASP：IDOR 与对象级授权（新窗口）随手查 / 把理解带回实际工作
理解机制之后，检查这些细节。
实验是简化模型。真实环境需要明确业务规则、验证失败路径，并持续维护配置与证据。
01 / 实用细节
把授权写成可检验的规则
先明确主体、对象、动作和业务关系。这个练习只采用“本人读取本人订单”的规则；真实系统还可能有团队、租户、委托与管理员权限，需逐项定义。[2]
02 / 实用细节
从可信会话获得主体
不要把客户端传来的 user_id 当作已验证身份。服务端从可信会话得到主体，再把查询限定在该主体有权访问的对象集合内。[1]
03 / 实用细节
每条入口都要执行检查
页面按钮、接口、批量导出和后台任务可能是不同入口。授权不能只放在前端，也不能只覆盖读取而漏掉修改、删除或下载。[2]
04 / 实用细节
默认拒绝，明确允许
未匹配到允许规则时应拒绝访问。处理授权异常时也应保留边界，不能因策略服务出错而向所有人放行。[2]
05 / 实用细节
用两个测试账户验证边界
在获准测试环境创建 A、B 两个账户及各自资源。验证自己的正常操作，再交换已知对象标识，检查跨账户和跨租户请求是否被拒绝。[1]
06 / 实用细节
状态码不能替代数据检查
一次测试既要检查返回状态，也要检查响应正文和实际副作用。对于存在性泄漏、错误提示和审计信息，按业务风险制定一致策略。[2]
从模拟，到验证
找一个获准的环境，实际检查一次。
勾选用于本页自查，不会自动标记整课已学会。练习与清单刷新后重置。
本页已检查 0 / 5 项
订单只允许所有者读取。用户 A 从截图中获得 B 的订单 UUID，改请求后看到了 B 的订单。哪项修复直接补上了漏洞？
能解释原因，再标记学会。
小测结果同步错题本；“已学会”沿用原有本地学习记录。
资料与依据
- OWASP · IDOR Prevention ↗
对象引用、随机标识与权限检查
本页场景、人物与数据均为教学示例。互动选择不会上传；收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期：2026-10-08。