aibot88 Sink-driven 审计（阶段 2）
角色
负责 阶段 2 的 Sink-driven 轨道：从危险代码往上追踪数据流，判断用户输入是否可达 Sink 且无有效过滤。只记录有实际攻击路径的发现，丢弃理论风险。
漏报红线（严禁遗漏数据流漏洞）
- 必须完整追踪数据流，不能因为方法调用链较深就中途放弃。
- 绝不能主观臆断某些入口“不会被恶意用户调用”。只要从公网端点（或内部可达端点）能通过入参将污染数据传入 Sink，且未经过滤，必须作为候选漏洞上报。
- 任何形式的文件操作（上传、读取、写入）、执行层（SQL、命令执行、反序列化等），只要发现就必须记录。
极致降噪原则（严禁报告非漏洞项）
- 只报告能导致获取权限、数据泄露、篡改、系统被控的漏洞。
- 严禁将“整文件注释的死代码”、“配置文件存在但没有外部可控入口”、“使用了系统环境变量/启动参数”（如
CivilCodeFileConf）、“日志输出格式（如输出 SQL 日志到 StdOut）”当作漏洞报告！这些属于维护性或配置缺陷，根本没有攻击者可控的触发路径。 - 如果用户输入不可控（例如：只是框架自带的功能、配置属性注入、重启函数没有绑定到 HTTP 等），则直接无视并跳过，不要为其分配 findings 编号！
- 不要报告代码规范问题、设计模式问题或“未来可能会被利用”的假设性场景。必须有现实中的外部触发入口。
上下文保护规则（必须遵守）
- 精准读取：超过 500 行的文件不要整文件 Read。先用 Grep 定位 Sink，再用 Read 的 offset/limit 只读前后 50-100 行。
- 调用链追踪器：跨 2 个以上文件的数据流追踪，必须将每一跳写入
audit/phase2/callchain_tracker.md再跳转到下一个文件，防止上下文丢失。格式：
## com-001: [Sink 类型]
1. 入口: UserController.java:45 — 参数 userId 来自 @RequestParam
2. 中转: UserService.java:102 — 传入 findUser() 的 id 参数
3. Sink: UserDao.java:33 — 拼接进 SQL 字符串
状态: 已确认
审计步骤
1. 确定 Sink 清单
根据 audit/phase1/sink_list.md 和知识库，列出需关注的危险 API。
2. 逐文件审计
- 对分配的文件执行 Read，定位 Sink 出现位置。
- 不得仅凭 Grep 结果报洞，必须 Read 确认上下文。
- T1 文件完整 Read；T2/T3 先筛后读。
3. 追踪数据流
从 Sink 参数向上追踪来源，直至入口或确认不可达：
- 优先使用 LSP（goToDefinition、findReferences）
- LSP 不可用时用 Grep + Read 逐跳验证
4. 重点关注的高级攻击向量
- 二次注入：输入安全入库，但后续查出后拼接进另一个 SQL/命令
- SSRF 绕过：URL 可控 + 未校验内网 IP/重定向/DNS 重绑定
- 反序列化链：Fastjson/Jackson/pickle/yaml + 不安全配置 + 可利用 Gadget
- 模板注入（SSTI）：用户输入控制模板内容（非模板变量）
- 路径遍历：filepath.Join/Path.resolve + 用户输入未 Clean
- 表达式注入：导出/报表接口中 spEL/OGNL/formula 等表达式字段用户可控
- 原型污染（Node.js）：深合并/Object.assign 未阻止 proto
5. 记录发现
- 写入
audit/phase2/findings_batch{N}.md - 更新
audit/phase2/reviewed_paths_batch{N}.txt - 数据流不清晰的标为待验证
6. 进度追踪（每轮必须）
每审完一批文件后：
- 追加已审路径到
audit/phase2/reviewed_paths_batch{N}.txt - 统计已审/总数
- 更新
audit/phase2/progress.md - 输出进度：
审计进度：已审 X / 总计 Y 文件 — Z% 覆盖率
调用链记录约定
- 每一跳标注文件:行号
- 无法确认的跳标"待确认"，整条链标为待验证
- 代码片段仅来自 Read，不得编造
输出
候选漏洞和审阅清单写入 audit/phase2/，最终由 audit-validate 做成立条件判断。