# Feature 威胁建模指南

> 由主 agent 在阶段 2 读取。与 `r/024.txt` 共同构成 Attack 阶段核心流程。

---

## Feature 流水线（前半）

### 步骤 1：探索 + JS 结合理解

不只是点页面、看按钮。把 discovery 阶段的 JS 分析结果和当前 feature 对应起来：

- 这个 feature 对应哪些 API？参数怎么构造的？
- JS 里有没有这个 feature 的前端校验？后端是否会重复校验？
- 有没有前端存储敏感中间态（window 变量、localStorage）？

### 步骤 2：威胁建模（12 维度）

基于下表逐项自问，**自由命名威胁项**，不预设漏洞类型。

| 维度                   | 深度自问                                                                                                      |
| ---------------------- | ------------------------------------------------------------------------------------------------------------- |
| **数据流**       | 数据从哪进、经过哪些处理、到哪出。有没有地方输入原样进入了数据库/命令/模板？                                  |
| **权限边界**     | 接口有没有校验调用者角色？校验是在哪一层做的（中间件/每个接口/前端）？能不能绕过？                            |
| **资源归属**     | 对象 ID 是数字/有序吗？后端有没有校验"这个 ID 属不属于当前用户"？能不能枚举到别人的资源？                     |
| **状态变更**     | 这个操作会改变什么状态？状态转换有没有前置条件检查？能不能跳过中间状态直达终态？能不能从终态回退？            |
| **客户端可控值** | 金额、数量、概率、折扣、角色、回调 URL 这些"应该服务端决定"的值，客户端能不能传进来覆盖？                     |
| **并发场景**     | 这个操作能不能并发执行？同一资源的并发写会不会产生重复效果（双花、重复领取、超卖）？                          |
| **输出展示**     | 用户输入最终会渲染到哪个页面的哪个元素？用的是 innerHTML 还是 textContent？API 返回的 HTML 字段有没有转义？   |
| **认证与会话**   | 登录/注册/找回密码流程有没有可枚举的差异响应？Token 可不可以伪造或重放？                                      |
| **SSRF**         | 接口是否接收 URL、主机名、IP 作为参数？接收后服务端会发起请求吗？有没有限制协议/IP 段？                       |
| **注入面**       | 输入是否进入 SQL/OS 命令/模板/XML/JSON 路径？转义是充分的吗？有没有二次处理让转义失效？                       |
| **文件操作**     | 上传：类型校验在哪里做、用什么方式、能不能绕过？路径可控吗？下载/删除：路径参数有没有穿越风险？               |
| **业务逻辑**     | 价格/数量可以是负数或 0 吗？优惠/积分/抽奖可以重复使用吗？签名验证的 key 是公开的还是私密的？状态机能逆向吗？ |

**重要：** 威胁建模时优先关注 js_analysis 中已经标记的 `client_controlled_params` 和 `sensitive_comments`，这些是前端代码直接暴露的攻击面，优先级最高。

**收口:`coverage_note` 三问(反遗漏,每个 feature 必填)**

威胁建模不是列完 12 维度就结束。每个 feature 收口前,用**三个泛化维度**自问一遍,答案写进该 feature 的 `coverage_note`(几句话,不要表格)。三维度并起来 = 整个攻击面,什么漏洞类型都自动落进某一类——但**不点名具体漏洞**,逼你自己想"这个输入/这个动作还可能是什么",反而想得全:

- **输入面**:本 feature 的每个外部可控输入(参数、字段、文件、路径、请求头、URL),我都"要么测了、要么明确说为啥不测"了吗?有没有哪个是含糊过去的?
- **行为面**:本 feature 的每个接口、每个会改状态的动作、每个能并发的点、每个角色组合,我都覆盖了吗?`apis[]` 里列的接口是不是每个都碰过?
- **深度面**:我判"安全"的,是真穷尽了,还是一种姿势就收?还有没有别的角度没排除?(没排除的具体面写进对应 test 的 `unruled_out`,见 `r/024.txt`)

> 这不是又一张要填的表——是逼你把"含糊过去"的点显式化。一个输入只要被认真想过,它该是哪种漏洞你比谁都会判断;skill 只保证"没有任何输入/动作/角色组合是被你含糊跳过的"。三条对应 G2。

---

## 威胁建模字段约定

每个威胁项写入 `modules/{x}.json` 的 `features[].threat_model`:

| 字段 | 说明 |
|------|------|
| `threat_id` | feature 内唯一标识,推荐 `T1`/`T2`/... |
| `vuln_type` | **模型自由命名**,精确描述威胁(避免泛泛的 "IDOR",用 "IDOR-编辑他人用户" 这种带场景的) |
| `reasoning` | **必填**,基于 feature 的什么特征推断出此威胁(数据流 / 权限边界 / 外部输入 / 状态变更 等) |
| `target_api` / `target_params` | 威胁指向的具体接口和参数 |

- 每个威胁必须有 `reasoning`,不得只写 `vuln_type` 不解释
- 威胁项数量不限,但模型需诚实——没风险的 feature 可以 `threat_model: []`
- 任何 `threat_model` 项必须在 `validation_results.tests` 中有对应 `threat_id` 的验证记录(否则 G2 不过)
- 每个 feature 必须有非空 `coverage_note`;每条 `not_vulnerable` 必须有非空 `unruled_out`(否则 G2 不过)
