| name | sink-chain-methodology |
| description | Sink chain deep tracing methodology with graded code output templates (Critical full-chain / High-Medium key-nodes), reverse tracking rules, and per-hop Read verification. |
Sink Chain Methodology Skill
Sink 链深度追踪方法论 — 分级代码链输出模板、反向追踪规则、每一跳 Read 验证
核心原则
发现任何 Sink 函数后，不能仅报告 Sink 位置，必须追踪完整的数据流链路并附带实际代码证据。
报告中的 Sink 链不是装饰信息，而是漏洞成立的主证据。Critical/High 如果缺少真实外部 Source，必须在报告前复核阶段降级。
Source 真实性判定
| Source 等级 | 示例 | 处理 |
|---|
| TRUE_SOURCE | HTTP 参数/Header/Cookie/Body、文件上传、MQ/RPC/Webhook 入站、OAuth/OIDC 回调、低权限用户可写数据库字段 | 可支撑 Critical/High |
| CONDITIONAL_SOURCE | 管理员可编辑配置、部署 Profile、内部 API、需特定权限写入的数据 | 通常降 1 级 |
| PSEUDO_SOURCE | 常量、测试数据、启动参数、不可被攻击者控制的内部变量 | 通常降到 Low/Info |
| NO_SOURCE | 未找到入口，仅命中 Sink | 删除或标记误报 |
数据转换管道追踪
发现 Sink 函数后，不仅追踪直接调用者，还必须向上追踪中间构造/转换层:
数据流模型: Source → [Transform₁ → Transform₂ → ... → Transformₙ] → Sink
典型中间层命名模式: *Builder, *Provider, *Manager, *Utils, *Helper, *Handler, Str, Trans, Process, Assemble, Render, Compile
追踪操作:
- 对每个 Sink → Grep 调用位置 → 对调用者 Grep 输入来源
- 重复直到找到外部输入(Source) 或到达 3 层上限
- 每层用 Read offset/limit 验证实际代码，记录 file:line + 关键代码片段
- 中间转换层若接受外部参数但无清洗/参数化 → 标记为独立注入入口
此规则确保不遗漏"Source 经过 Builder/Provider 间接到达 Sink"的注入路径。
反向追踪规则（强制）
- 至少 3 层: Sink → 调用者 → 调用者的调用者 → Source
- 每一跳必须 Read: 不可基于推测，必须 Read 实际代码
- 记录格式: file:line + 8-15行关键代码片段（Critical），5-10行（High），3-6行（Medium）
- 净化点标注: 遇到净化/过滤函数时，必须记录并评估是否可绕过
- 断链处理: 若某一跳无法继续追踪，标注断点位置和原因
两级 Sink 链输出模板
Critical 漏洞 — 完整代码链
每一跳都附带实际代码片段。报告中先展示总览，再展开关键代码:
[SINK-CHAIN] Source → Transform1 → Transform2 → ... → Sink
├── Source: {file}:{line}
│ ```{lang}
│ {code_snippet 8-15行}
│ ```
│ 类型: {HTTP参数/配置/数据库/文件...}
│ Source真实性: TRUE_SOURCE | CONDITIONAL_SOURCE
│
├── Transform1: {file}:{line}
│ ```{lang}
│ {code_snippet 5-10行}
│ ```
│ 转换说明: {如: 字符串拼接/格式化/编码转换}
│
├── Transform2: {file}:{line}
│ ```{lang}
│ {code_snippet 5-10行}
│ ```
│ 净化检查: {无净化/有净化但可绕过(原因)/有效净化}
│
└── Sink: {file}:{line}
```{lang}
{code_snippet 8-15行}
```
危险函数: {函数名}
影响: {RCE/数据泄露/文件读写/...}
High/Medium 漏洞 — 关键节点模式
Source、关键 Transform、净化点、Sink 附带代码，中间节点可用 file:line 简写:
[SINK-CHAIN] Source → ... → Sink
├── Source: {file}:{line}
│ ```{lang}
│ {code_snippet 5-10行}
│ ```
│ Source真实性: TRUE_SOURCE | CONDITIONAL_SOURCE
│
├── 中间节点: {file1}:{line} → {file2}:{line} → {file3}:{line}
│
├── 净化点: {file}:{line}
│ ```{lang}
│ {sanitizer_code 3-6行}
│ ```
│ 可绕过: {是(原因)/否}
│
└── Sink: {file}:{line}
```{lang}
{code_snippet 5-10行}
```
Low/Info 漏洞
仅需 Sink 位置 + 简要描述，无需完整链。
Markdown 展示格式
每个漏洞至少包含两个层次:
- 数据流总览: 一段
text 流程图 + 一张表格，说明阶段、位置、变量、处理、安全判断。
- 关键代码分析: 按 Source / Transform / Sanitizer / Sink 分节，每节包含代码块和判断。
若 Source 缺失，必须在总览上方输出:
> 真实性提示: 当前链路未记录真实 Source，报告前复核应降级。
数据库 steps 格式（强制）
调用 audit_save_sink_chain 或 audit_update_finding_after_verification(..., sink_chain_steps) 时，steps 必须是非空 JSON 数组。每个节点优先使用固定字段:
{"step_type":"Source|Transform|Sanitizer|Sink","file_path":"...","line_number":42,"code_snippet":"...","notes":"..."}
- Critical/High/Medium 至少包含一个
Source 和一个 Sink。
- Source/Sink 必须带文件行号或真实代码片段；不能只写自然语言总结。
- 工具返回
error、saved=0 或 replaced_steps=0 时，必须修正 steps 后重试。
引用 references/core/taint_analysis.md
对于需要完整污点分析的场景，加载详细方法论:
- Sink识别 — 分析危险函数和涉及变量
- 反向追踪 — 从Sink向上追踪数据来源
- Source定位 — 识别用户可控输入点
- 净化检查 — 验证传播路径上的安全措施
- 报告生成 — 输出完整的污点分析报告
