注册时输入已存在的用户名/手机号/邮箱：
- 已存在: "该手机号已注册" / "用户名已被占用"
- 不存在: "注册成功" 或进入下一步
 
→ 差异响应 = 可枚举用户是否存在
→ proxy_send_request 分别提交存在和不存在的用户，对比响应

- 存在的用户 + 错误密码: "密码错误"
- 不存在的用户 + 任意密码: "用户不存在" / "账号或密码错误"
 
即使提示相同，也检查：
1. 响应时间差异（存在的用户需要查库比对密码，更慢）
2. 响应长度差异（多几个字节也是差异）
3. HTTP 状态码差异
4. Cookie/Header 差异

- 存在的手机号: "验证码已发送"
- 不存在的手机号: "该手机号未注册"
 
→ 密码重置接口是用户枚举的最常见入口

搜索用户接口:
GET /api/user/search?phone=13800138000
→ 返回用户信息 = 可通过手机号查任意用户
 
检查用户是否存在:
GET /api/user/check?username=admin
→ 返回 {"exists": true}

自己的订单: GET /api/order/10086
改 ID: GET /api/order/10087, 10088, 10089...
 
如果返回其他用户的订单 → IDOR + 数据泄露
如果返回 404/403 但响应不同 → 可判断订单是否存在

发票下载: GET /api/invoice/INV-2024-0001
遍历: INV-2024-0002, INV-2024-0003...
→ 泄露其他用户/公司的发票信息

个人资料: GET /api/user/profile/1001
遍历: 1002, 1003, 1004...
→ 批量获取用户个人信息
 
注意遍历策略：
- 数字 ID: 1, 2, 3... 或 1001, 1002, 1003...
- UUID: 不可遍历，但可能从其他接口泄露
- 自增序列: 试 ID ± 1, ± 10, ± 100 判断规律

检查以下接口：
1. 导出功能: GET /api/export/users?format=csv
   → 不传过滤条件 = 导出全量数据？
   → 修改分页参数: page_size=999999
 
2. 搜索接口: GET /api/search?keyword=&page_size=1000
   → 空关键词 + 大分页 = 全量查询
 
3. 列表接口: GET /api/users?limit=999999&offset=0
   → 直接拉全量
 
4. GraphQL: { users(first: 99999) { id, name, email, phone } }
   → 批量查询

检查 API 响应是否包含不该返回的字段：
 
用户接口:
- 密码 hash（password_hash, encrypted_password）
- 身份证号（id_card, identity）
- 完整手机号（phone 未脱敏）
- 完整邮箱
- 家庭住址
- 银行卡号
 
订单接口:
- 其他用户的收货信息
- 支付流水号
- 第三方账户信息
 
系统接口:
- 数据库连接信息
- 内部 IP
- API Key/Secret

微妙的枚举指标（肉眼不易察觉）：
1. 响应时间: 存在用户 200ms vs 不存在 50ms
2. 响应大小: 差 10-20 字节
3. Cookie 数量: 存在用户多设置一个 Cookie
4. 错误码: 同样 400 但 error_code 不同
5. JSON 字段: 存在用户多返回一个 user_id 字段
 
→ proxy_diff_responses 自动发现差异

1. 证明可以判断用户是否存在（至少 2 个差异证据）
2. 或证明可以获取其他用户的数据
3. 评估影响范围（可遍历多少用户/订单）
4. vuln_verify + note_add(type="result")