# 证据纪律（补天 / 国内 SRC）

> 对齐：MyuriKanao/src-hunter-skill `methodology/03-evidence-discipline` + 补天审核习惯。  
> 无证据 = 无漏洞。报告里只能写你**亲手复现**过的事。

## 1. 每条 finding 最低证据包

| 必备 | 说明 |
|------|------|
| 目标与时间 | URL/Host、测试时间（本地时区）、测试角色（游客/用户/商户） |
| 完整请求 | 方法、路径、关键 Header、Body（Cookie 可脱敏后半段） |
| 关键响应 | 状态码 + 证明危害的字段（脱敏） |
| 对比基线 | 正常值 vs 恶意值（例如 id=自己 / id=他人；`1` vs `1'`） |
| 业务危害一句话 | 读到了什么 / 改了什么 / 冒充了谁 |

P0/P1 强烈建议再加：

- 步骤编号截图（URL 可见）
- 30s–2min 录屏（不剪辑花活）
- 可复现脚本（curl/Python，不含真实他人数据）

## 2. 样本控制（硬上限）

| 场景 | 允许 | 禁止 |
|------|------|------|
| IDOR/列表 | 1–3 条**自有或明确测试号**样本 | 全表遍历、导出他人大批量 |
| SQLi | 版本/库名/当前用户；最多 1 个字段名证明可读 | dump 全表、outfile、xp_cmdshell 乱打 |
| RCE | `whoami` / `id` / `uname -a` 一类只读 | 写 webshell、持久化、横向 |
| SSRF | 打自己的 OOB / 云元数据只读证明 | 扫全内网、改配置 |
| 上传 | 无害图片/文本证明落盘可读 | 马、后门、可执行业务逻辑破坏 |
| 短信/邮件 | 只对自己号 | 轰炸、撞库验证码 |

## 3. 脱敏规则

- 手机号：`138****5678`；证件/银行卡只留后 4
- Cookie/Token：保留前缀证明存在即可
- 他人订单号/姓名：打码或用测试号替代
- 截图里的侧栏个人信息一并打码
- **报告与 evidence 目录都不要存未脱敏原包**（工作区同样）

## 4. 稳定性

- 关键洞建议 ≥3 次成功复现；高危尽量 5 次或给出明确时序
- 时间盲注要真/假条件对照表
- WAF 间歇拦截要在报告写清「偶发 403 不否定存在」并附成功包

## 5. 提交前 10 项自检

- [ ] 标题含：等级倾向 + 条件（未授权/登录后）+ 类型 + 位置
- [ ] 资产在 scope
- [ ] 步骤零基础可跟做（含前置登录说明）
- [ ] 至少 1 组原始 HTTP 包
- [ ] 至少 1 张结果截图（URL 可见）
- [ ] 副作用/危害字段已证明且脱敏
- [ ] 未对生产做不可逆操作
- [ ] 修复建议可落地（鉴权/参数化/对象级校验…）
- [ ] 一洞一报或链式因果清楚
- [ ] 未夸大（评级与可证影响一致）

## 6. 证据目录建议（工作区）

```text
evidence/
  01-baseline-req.txt
  01-baseline-resp.txt
  02-poc-req.txt
  02-poc-resp.txt
  02-screenshot.png
  impact-summary.json   # 自用：字段、等级理由、是否 cluster
reports/
  0x-title.md
```

## 7. 与红队交付的区别

| SRC/补天 | 红队渗透报告 |
|----------|--------------|
| 最小 PoC + 业务危害 | 攻击路径、权限、影响面、建议修复优先级 |
| 一洞一报为主 | 可写完整 kill chain |
| 禁止横向破坏 | 在授权书内可做后利用（仍要控损） |

本 skill 默认 **SRC 证据纪律**；用户明确红队授权时再升格，但样本控制不放松。

## 8. 与误报 SOP 的关系

证据包证明「发生了什么」；alse-positive-sop.md 证明「这算不算漏洞、等级该不该降」。
提交前两者都要过：无包不报；仅有包但只达可达性也不报 confirmed。
