IDOR（Insecure Direct Object Reference）是 Web 安全中最常见的漏洞之一，属于访问控制问题。本文系统总结挖掘技巧和真实案例。

---

什么是 IDOR

IDOR（不安全的直接对象引用）指应用程序直接使用用户提供的输入来访问对象，而未进行权限校验。简单说就是：你传别人的 ID，服务器就返回别人的数据。

IDOR 属于越权漏洞（Broken Access Control）的范畴，可以分为：

• URL 层访问控制 — 通过 URL 路径直接访问
• 数据层访问控制 — 通过 API 参数越权操作数据

---

挖掘技巧

1. 关注功能点

检查任何涉及敏感 ID 的功能处：

功能点	风险等级	影响
密码重置/修改	P1	账户接管
个人信息查看	P1-P2	信息泄露
订单/支付操作	P2	数据篡改
评论/内容删除	P2-P3	内容破坏
文件/附件查看	P3	敏感文件泄露

2. 简单 IDOR（直接标识符）

关注参数：id、user_id、uid、pid、order_id、post_id 等。

测试方法：

• 将 ID 值加 1 或减 1
• 使用另一个账号的 ID 替换
• 遍历连续的 ID 值

3. 复杂 IDOR（随机标识符）

遇到 UUID/哈希值参数时：

• 尝试解码（Base64、Hex）
• 在页面源码/返回包中找参数值泄露
• 创建两个账号，互相替换参数值测试

4. 越权类型

用户间越权：

• 管理员 vs 普通用户的功能差异
• GET 请求的目录/路径越权
• POST/API 请求的数据层越权

单用户内部越权：

• 灰化按钮 → 审查元素绕过前端限制
• 相邻数据间的权限差异
• 多业务共用方法导致的权限绕过

---

实战案例

案例 1：微软找回密码 IDOR

微软招聘网站通过邮箱找回密码时，id 参数未进行用户权限校验：

POST /api/resetPassword
id=12345&email=attacker@example.com

通过遍历 id 值，可重置任意用户密码。

案例 2：雅虎任意评论删除

雅虎评论删除接口：

POST /_xhr/contentcomments/delete_comment/
comment_id=139967299182-588b2cdd&content_id=485d5605ea9

替换 comment_id 为其他用户的评论 ID，可删除任意评论。

注意：只有攻击者是第一个评论者时才能删除后面的任意评论——开发者遗漏了对第一个评论者的鉴权。

案例 3：Twitter 信用卡删除 IDOR

Twitter Ads 支付页面删除信用卡：

POST /accounts/[account_id]/payment_methods
account=12345&id=67890

替换 account 和 id 为另一个用户的账户和信用卡 ID，虽然返回 403，但信用卡实际已被删除——响应状态码不反映实际结果。

案例 4：YouTube 评论移动漏洞

将一个视频下的评论移动到另一个视频下：

POST /api/move_comment
comment_id=COMMENT_ID&video_id=VIDEO_ID

如果只改变 comment_id 而保持 video_id 不变，其他用户的评论会出现在你的视频下。价值 3k 美元。

---

如何防御

• 每个端点的每个关键参数都必须与当前用户身份及权限进行校验
• 不要依赖前端限制（灰化按钮、隐藏字段）
• 使用随机的、不可预测的 ID（但仍需鉴权）
• 对 API 响应做统一鉴权，不要只在特定功能处校验

测试 Checklist

[ ] 遍历数字 ID（+1/-1）
[ ] 替换 UUID/哈希值
[ ] 解码 Base64 等编码参数
[ ] 创建两个账号互相替换
[ ] 测试管理员和普通用户权限差异
[ ] 检查灰化按钮/隐藏功能
[ ] 关注响应 403 但操作成功的情况
[ ] 结合 HPP/self-XSS 升级危害

本文内容仅用于安全研究和授权测试，请勿用于非法用途。