# 跨角色验证与权限矩阵利用

> 由主 agent 在阶段 2 读取。配合 `r/012.txt`、`r/023.txt`、`r/024.txt` 使用。

---

## 权限矩阵利用

Discovery 阶段已生成 `permission_matrix`。进入每个模块前先看矩阵：

- 哪些接口对低权限角色返回 200？→ 立即深入验证
- 哪些接口对所有角色都返回 403？→ 看是否能绕过（header 注入、参数覆盖）
- 哪些接口在不同角色之间有差异响应（内容不同但都是 200）？→ IDOR 高风险

---

## 跨角色验证

越权测试的三个层次，**都需要覆盖**：

1. **读越权**：A 能否读到 B 的私有数据
2. **写越权**：A 能否修改 B 的资源
3. **操作越权**：A 能否触发本应 B 或更高权限才能执行的业务操作（退款、审核、发货）

对象 ID **不要硬编码**，从目标角色的数据列表里取真实 ID：

```bash
VICTIM_RESOURCE=$(curl -s -H "Cookie: $VICTIM_SESS" "$LIST_URL" | jq -r '.data[0].id')
curl -s -H "Cookie: $ATTACKER_SESS" "$RESOURCE_URL/$VICTIM_RESOURCE"
```

跨角色验证要求（对应 a01.txt G4）：

- victim cookie 获取真实资源 ID(**不得硬编码**)
- attacker 使用 attacker 自身 cookie(不复用 victim 的)
- 结果写回 `modules/{x}.json` 的 `cross_role_verification`
- 如果模块无对象 ID/无权限边界,或会话池不足以支撑跨角色(账号 `<2`):直接记 `role_pairs_tested: []` + note 说明原因,`tested: true`

---

## Token/Session 过期处理

收到 401/403 时：重新登录 → 同步更新 `sessions/pool.json`（`accounts[].cookie_value`）和 `sessions/account_{role}.json`（`auth.cookie_string` + `auth.cookies`）两处 → 重试。

---

## 安全边界

**禁止**：删除已存在的真实业务数据 / 其他用户预存数据；上传持久化恶意载荷；高并发压测；扩展到非目标资产。

**允许**：删除本次测试中自行创建的数据（测试账号/订单/评论/文件等），可用于验证删除类功能含删除越权。只动本次新建的，不碰已存在的。

**敏感操作前确认**：支付/退款/通知/批量操作、修改权限。竞态测试用专用测试资源，不影响其他用户。
