# Attack Agent（流程文档）

> 本文件由主 agent 在阶段 2 主循环 Read 后按其流程执行，**不是独立 subagent**。

**核心原则：** 发现漏洞比记录漏洞更重要。流程是脚手架，不是枷锁。当你的直觉告诉你某个方向有问题，就深入追，不要因为"当前模块还没测完"而克制自己。

---

## 模块主循环

```
取 module_queue.pop(0)：

  1. 读 discovery 阶段生成的 permission_matrix.json 和 js_analysis.json
  2. 识别本模块的 features 和关联 API
  3. 对每个 feature 跑流水线（详见 `r/023.txt` + `r/024.txt`）
  4. 触发业务操作后，检查响应是否暴露新接口 → 立即追加到 api_inventory 和 permission_matrix（见下）
  5. 发现子模块入口 → append 到队列；发现新页面/新功能 → 追加到 pages.json（见下）
  6. G2 校验通过 → 移入 tested_modules → 取下一个
```

**优先级规则：** `permission_matrix` 中标记为 `critical` 的越权点、`js_analysis` 中的 `client_controlled_params` 和 `sensitive_comments`，优先测试，不按模块顺序等待。

---

## 边测边发现：增量更新 api_inventory 和 permission_matrix

Discovery 阶段只能发现**静态已知**的接口。很多接口只有在业务操作发生后才会暴露：

- 创建订单 → 响应里出现 `pay_url`、`callback_sign`
- 支付成功 → 出现 `recharge-callback.php` 的 sign
- 上传文件 → 响应里出现文件访问路径
- 任何重定向 → Location 头可能指向新接口

**每次触发业务操作后，立即检查：**

1. 响应 body 里有没有新的接口路径（URL、path、endpoint 字段）
2. 响应 body 里有没有 token/sign/key 类字段（可能是可重放的凭据）
3. 响应 Header 里有没有新路径（Location、X-*、Set-Cookie 里的 path）
4. 重定向目标是不是新接口

**发现新接口后立即做两件事：**

```bash
# 1. 追加到 api_inventory.json
# 2. 用所有角色 session 测权限，追加到 permission_matrix.json
for role in admin user1 user2 merchant1; do
  SESS=$(jq -r ".accounts[] | select(.role==\"$role\") | .cookie_value" pentest-data/{project-id}/sessions/pool.json)
  CODE=$(curl -s -o /dev/null -w "%{http_code}" -H "Cookie: $COOKIE_NAME=$SESS" "$NEW_API_URL")
  echo "$role: $CODE"
done
```

如果新接口对非预期角色返回 200 → 标记 `critical`，插入 `module_queue` 队首，当前模块暂停，先测这个。

**同样地，发现新页面/新功能时追加到 `pages.json`**：测试中遇到的新页面（导航、链接、面包屑、SPA 路由）、新功能点（按钮、表单、操作入口），边发现边追加进 `pages.json` 的对应 `pages[]` 或其 `functions[]`，并尽量把 `triggered` 标 true（本次测试触发了的功能）或 BLOCKED（触达不到 + 原因）。这是 G6 页面功能覆盖门控的数据来源——**尽量收集到所有功能**。
