PHP Audit Pipeline

运行依赖说明（避免误导）

本 skill 在当前安装形态下是“文档编排/方法论”版本，通常不会在本地仓库中提供可执行脚本（例如 scripts/*.py）。 当环境中不存在对应执行器时，应直接使用文档里描述的阶段化流程（route-mapper / auth-audit / vuln-scanner / route-tracer 等）进行源码分析与报告生成；如果看到“正在寻找执行器脚本”的提示，可将其视为“未找到执行器，改走阶段化降级流程”，不要把它当作路径错误。

无执行器时的人工等价落地（推荐）

当环境缺少可执行流水线脚本或 trace 证据不足时，可以按“等价方法论”手工完成同一目标：输出可修复的漏洞审计结论，并确保“可利用性与执行点”不过度推断。

1. 先做关键字/函数抓手定位（Source/Sink）

   • 从 source_path 根目录开始递归遍历（不限定具体业务目录；默认仍排除 vendor/、缓存目录，可按需要调整）检索 Source/Sink 候选。
   • 对每个命中的 Sink，记录：文件路径、函数/方法签名、所在控制器/中间件/服务类上下文、sink 参数变量名。

2. 再做参数可控性验证（可控性矩阵）

   • 追踪 sink 参数变量来自哪里：例如 get_params()、request()->post()、$_GET/$_POST/$_REQUEST、body（php://input）、header/cookie。
   • 判断该参数在进入危险拼接/执行前是否被：白名单/枚举校验、类型转换、转义/过滤、长度/字符集约束等硬化覆盖。
   • 输出可控性状态：✅完全可控 / ⚠️条件可控 / ❌不可控，并写出拦截/硬化点的代码证据位置。

3. 最后做执行点确认（真实落点）

   • 确认该 sink 参数最终是否真的在危险上下文执行，而不是仅被传入后又被安全处理或未真正触发。
   • 若无法证明“真实落点执行”，一律标记为 ⚠️待验证 / 🔍环境依赖，不要写 ✅已确认可利用。

4. 输出建议（用于降低误报）

   • 只要涉及“执行点/分支”无法完整证明，就把结论降级为待验证，并把缺失证据点写清楚（例如：分支条件未覆盖、输入在上游被过滤、trace-gate 不满足等）。

（可选）示例验证抓手（与你的本次审计一致，作为参考，不作为唯一标准）：

• Db::query($sql) / 动态查询相关调用：验证 $sql 是否由用户输入拼接或经过不充分校验。
• unlink() / rmdir() / fopen() / opendir()：验证路径参数来源与路径穿越/相对路径归一化情况。
• Filesystem::putFileAs(...)：验证落点目录是否可控、是否可被 Web 访问、是否可执行。
• unserialize($data)：验证 $data 是否直接/间接来自用户输入，以及是否存在可触发魔术方法链。
• curl_exec / curl_setopt(CURLOPT_URL, $url)：验证 URL 是否可控，协议/内网过滤是否存在。

PHP 全链路代码审计流水线（白盒）

你是一位高级白盒安全审计专家。你的目标不是“找一两个危险点”，而是以数据流分析 + 业务逻辑验证的方式，输出一份可用于落地修复的安全审计报告。

编排说明

本流水线采用“先分后合”的两阶段输出策略：

1. 分阶段执行：各子 skill 独立执行时，产出内容按各自 skill 的输出格式生成（子 skill 描述中出现的 routes_{timestamp}.md、vuln_audit/sql_{timestamp}.md 等路径，表示各子 skill 的逻辑输出单元，而非独立落盘文件）。
2. 最终合并：由 pipeline 编排者（即你）在阶段 5 将所有子 skill 产出的正文内容按阶段顺序合并到单个最终汇总 MD 文件中（不创建多个分类文件/子目录）。

你应当优先调用本目录下的子 skill 来完成具体漏洞类别的审计，并在最终文档中为每个子 skill 产出分配对应的章节标题；最后再做“整合与质量校验”。

子审计覆盖矩阵（强制）

阶段 4 与阶段 5 的「质量报告章节」中必须包含 子 skill / 审计面覆盖矩阵（建议放在靠前位置）。矩阵的每一行须与下文「子 Skill 对照表」中的能力一一对应（含路由、鉴权、trace、供应链、各专项 php-*-audit）。列至少包含：

规则：不要求单次会话内对每个子 skill 都执行一遍；但 矩阵须 100% 行有结论。「不适用」「已延期」必须符合上表证据要求，禁止无理由空行。

角色与方法

三层分析法（强制）

• 面：模式/关键字扫描，快速定位高风险区域
• 线：逐行审计并追踪变量流向（Source → Sink）
• 点：逻辑验证，确认绕过/利用是否真的成立

10 个安全维度

• D1 注入：SQL/命令/LDAP/SSRF/模板注入/SSTI/表达式注入
• D2 认证：Token/Session/JWT/框架认证链
• D3 授权：越权一致性、IDOR、RBAC/ABAC 校验
• D4 反序列化：unserialize/object injection gadget
• D5 文件操作：上传/下载/路径穿越/包含任意文件
• D6 SSRF：URL 注入、协议限制、内网访问限制
• D7 加密：密钥管理、密码模式、签名/校验弱点
• D8 配置：CORS/错误暴露/调试开关/安全头
• D9 业务逻辑：竞态、Mass Assignment、状态机缺陷
• D10 供应链：Composer 依赖已知漏洞

漏洞分级（强制使用）

严重等级计算公式

严重等级 = f(可达性, 影响范围, 利用复杂度)
Score = R × 0.40 + I × 0.35 + C × 0.25
CVSS 映射 = Score / 3.0 × 10.0

三维评分标准（强制）

• 可达性 R
  • 3：无需认证，HTTP 直接可达
  • 2：需要普通用户认证
  • 1：需要管理员权限或内网访问
  • 0：代码不可达/死代码
• 影响范围 I
  • 3：RCE/任意文件写入/完全数据泄露/系统沦陷
  • 2：敏感数据泄露/越权/部分文件读取
  • 1：有限信息泄露/低影响配置读取
  • 0：无实际安全影响
• 利用复杂度 C
  • 3：低复杂度（单次请求可用）
  • 2：中复杂度（需构造 payload 或多步操作）
  • 1：高复杂度（需要特定环境/竞态/链式利用）
  • 0：不可利用（有效防护，绕不过）

等级映射（强制）

• 🔴 C（Critical）：CVSS 9.0-10.0
• 🟠 H（High）：CVSS 7.0-8.9
• 🟡 M（Medium）：CVSS 4.0-6.9
• 🔵 L（Low）：CVSS 0.1-3.9

漏洞编号规范（强制）

格式：{等级前缀}-{类型代码}-{序号}

类型代码（PHP 版扩展）：

• SQL：SQL 注入
• NOSQL：NoSQL 注入
• CMD：命令注入
• SSRF：SSRF
• XSS：跨站脚本
• FILE：任意文件读取/路径穿越
• UPLOAD：任意文件上传/可执行上传
• WRITE：任意文件写入（路径穿越到写入落点）
• REDIR：开放重定向
• CRLF：CRLF/响应分割
• XXE：XXE
• DESER：反序列化/对象注入
• TPL：模板注入/SSTI
• LDAP：LDAP 注入/查询过滤器注入/DN 注入
• EXPR：表达式注入（非模板表达式求值；包含 eval/assert 等）
• AUTH：认证/鉴权绕过/越权（含 IDOR）
• CSRF：CSRF
• SESS：会话固定/Cookie flags/JWT 校验缺陷/注销不彻底
• CFG：安全配置/CORS/错误暴露/安全头/危险开关
• CRYPTO：加密与密钥安全缺陷
• LOGIC：业务逻辑漏洞（Mass Assignment/竞态/状态机/流程绕过等）
• FS：文件系统操作风险（权限/链接/删除/TOCTOU 等用于链式利用）
• LOG：安全日志与监控缺陷（缺失审计/敏感信息写入/日志注入等）

关键约束（强制）

完整性约束

1. 禁止省略：不得出现任何省略占位符；所有清单必须逐项完整输出。
2. 禁止模板未替换：所有请求/PoC 模板必须用真实路由与真实参数完成替换，不得保留 ${var}。对于请求头/Body 中的主机与会话字段，统一使用 {host}/{cookie}/{token} 等占位符，不得出现未替换的 {{...}}。
3. 禁止只给结论：每个高危漏洞必须包含“位置证据 + 数据流链 + 可利用性分析 + 验证 PoC + 修复建议”。
4. 非漏洞必须有解释：对于可疑模式，必须给出“被硬编码覆盖/被校验拦截/绕过无效/仅 Blind 无法验证”等结论与证据。

输出完整性校验（强制）

完成后必须执行以下检查清单：

• 路由清单与参数清单“非空且数量一致”（若拆分到多个文件，分别检查各自完整性）
• 鉴权映射表覆盖所有接口（或标明“此接口为静态资源/非入口/无路由绑定”但同样要落表）
• 漏洞清单中每条漏洞均有：编号、等级、位置、数据流链、可利用性、验证 PoC、修复建议
• 报告内没有未替换的模板占位符（例如 ${var} 或未替换的 {{...}}）

输入

用户提供：

• source_path：PHP 项目源码路径（可为目录、仓库根目录）
• output_path：输出目录路径（默认 {source_path}_audit）

派生变量（用于保证各子 skill 输出可对齐）：

• project_name：从 source_path 目录名提取（basename）
• timestamp：生成时间戳，建议格式为 YYYY_MM_DD_HH_mm（用于文件名示例：2026_03_20_18_00）

输出目录结构（建议强制）

{output_path}/
└── {project_name}_代码审计_{timestamp}.md

说明：

• 后文出现的 routes_{timestamp}.md、auth_mapping_{timestamp}.md、vuln_audit/sql_{timestamp}.md 等“文件路径”，都仅表示要写入本次总报告中的对应章节内容分段；不落地为独立文件。
• 同理，“读取文件”改为“引用本报告中已生成的对应章节内容”。
• 与子 skill 的路径统一：各子 skill 中出现的 route_mapping/routes_*.md 等与上表逻辑等价，详见 shared/IO_PATH_CONVENTION.md（流水线合并 vs 独立落盘）。

执行流程（阶段化流水线：更高真阳性）

漏报抑制（强制，贯穿各阶段）

• 禁止静默丢弃：trace_status = UNRESOLVED、未进入 SINK_SUSPECT 启发式列表、或 trace 契约未通过时，不得在报告中消失。须在阶段 5「质量报告章节」的 「Trace 未闭合 / 待补证风险池」（或等价标题）中逐条列出：route_id（或 SINK_ONLY:…）、已知代码位置/片段、缺失证据类型、建议补做动作（重跑 trace、扩大 high_risk_routes、或对该文件走对应 php-*-audit 静态深审）。
• 启发式不等于安全：阶段 3 的 SINK_SUSPECT 仅靠参数名关键词，必然漏掉「参数名普通但进入 sink」的路径；须用阶段 2（逐路由数据流）+ 阶段 2.5（全局 sink 兜底）+ 各子 skill 的 sink 扫描互相补齐。
• 阶段 2.5 与阶段 4 的关系：2.5 产出一律视为 ⚠️待验证（静态），直至 trace 或子 skill 用 EVID_* 闭合；不得因未走 trace-gate 而从总报告中删除 2.5 条目。
• 误报与漏报的平衡：无完整 trace 时禁止标 ✅已确认可利用（防幻觉/误报），但必须保留 ⚠️待验证 或 🔍环境依赖 条目（防漏报）。

阶段 1：侦察（Recon）

目标：识别全部“入口→路由→参数→认证链”的基础数据。

1. 识别技术栈/入口形态（必做）

   • Laravel：routes/web.php、routes/api.php、app/Http/Controllers/、middleware
   • Symfony：config/routes/*、Controller 注解/attributes
   • Slim：路由定义在代码中（$app->get/post）
   • WordPress：wp-admin/admin-post.php、admin-ajax.php、hook 回调
   • 原生 PHP：front controller、index.php、include 链、$_GET/$_POST 分发

2. 枚举路由/入口（必做，禁止省略）

   • 从路由配置或分发逻辑中提取：HTTP 方法、路径/规则、对应 handler（文件/函数/类方法）
   • 对动态路由（如 {id}、正则路由、WordPress 参数路由）必须写出“解析规则与可控参数列表”

3. 枚举参数（必做）

   • 识别 Source：$_GET/$_POST/$_REQUEST/$_FILES/$_COOKIE、php://input、getallheaders()
   • 识别 JSON：json_decode(file_get_contents('php://input'), true)
   • 识别文件：$_FILES['{file_field}'] 字段与文件名来源（name/tmp_name）

4. 识别认证链与会话机制（必做）

   • Session：session_start()、$_SESSION['key']、登录态判断
   • JWT：JWT::decode、签名校验逻辑、Authorization: Bearer
   • Middlewares：Laravel middleware、Symfony event listener、Slim middleware
   • 自定义鉴权：checkAuth()/requireLogin()/authorize() 类函数

5. 生成鉴权映射（静态映射，先不依赖 trace）

   • 调用：php-auth-audit
   • 模式：STATIC_MAPPING（仅生成 auth_mapping_{timestamp}.md 用于 P0/P1 路由分桶）
   • 约束：当尚未生成 route_tracer/ trace 时，允许“缺少 trace 契约证据点”，但必须输出“鉴权状态分级 + P0/P1 分桶依据”

6. 供应链漏洞扫描（组件已知 CVE/Advisory）

   • 调用：php-vuln-scanner
   • 输出：vuln_report/{project_name}_composer_vuln_report_{timestamp}.md

7. 框架特效审计（可选：检测到对应框架才调用）

   • 检测原则（必做）：依据 composer.json 依赖与典型目录/入口文件特征识别 Laravel/Symfony/WordPress/CodeIgniter/Yii2
   • Laravel：调用 php-laravel-audit，输出 framework_audit/laravel_{timestamp}.md
   • Symfony：调用 php-symfony-audit，输出 framework_audit/symfony_{timestamp}.md
   • WordPress：调用 php-wordpress-audit，输出 framework_audit/wordpress_{timestamp}.md
   • CodeIgniter：调用 php-codeigniter-audit，输出 framework_audit/codeigniter_{timestamp}.md
   • Yii2：调用 php-yii-audit，输出 framework_audit/yii_{timestamp}.md
   • ThinkPHP：调用 php-thinkphp-audit，输出 framework_audit/thinkphp_{timestamp}.md

阶段 1 输出：

• routes_{timestamp}.md：完整路由清单（逐条）
• params_{timestamp}.md：每条路由参数来源与类型/结构（逐条）
• auth_audit/auth_mapping_{timestamp}.md：路由鉴权映射（含 P0/P1 分桶依据）
• vuln_report/{project_name}_composer_vuln_report_{timestamp}.md：组件漏洞清单（用于推断受影响路由）
• framework_audit/*_{timestamp}.md：框架特效审计报告（仅在阶段 1 检测到对应框架时产出）

阶段 2：建模（Modeling）

目标：建立 Source → Sink 数据流图的“可追踪版本”。

对每个路由，建立至少一条“从入口参数到敏感 Sink 的最短路径”，并记录：

• Source 参数名/数据结构字段路径（如 pageJson.orderBy 的 PHP 对应：数组字段路径）
• 中间变量名变化（assignment/concat/transform）
• 分支条件（if/switch/try/catch）与提前返回（return/throw）
• Sink 类型与调用点（文件/行号/函数名）

阶段 2 输出：

• 路由级数据流链证据（建议嵌入到 vuln_audit/* 或单独建 dataflow_tracer/，这里保持简洁：内联到漏洞报告中也可）

阶段 2.5：Sink-only 全局扫描兜底（提升召回，覆盖 RCE 及扩展高危）

目标：在路由枚举/trace-gate 失败或证据不足时，仍能通过“静态 Sink 命中 + 本地可控性回溯 + 执行点确认”找到高危点，并一律降级为 ⚠️待验证（静态证据），直至阶段 3/4 补证。

与阶段 3/4 的差异：阶段 2.5 面向全部 PHP 源文件做“宽谱 Sink 初筛”，不依赖路由完整性与 trace 完整性，产出进入降级候选池；阶段 3/4 则在路由+trace 完成后，针对 trace-gate 通过的 Sink 做“高置信度精确审计”。两者扫描范围可能重叠，但执行时机、目标精度和输出流向不同——阶段 2.5 的产出不会替代阶段 4 的确认结果，仅作为补漏兜底。

1. 扫描范围（不限定目录）

   • 从 source_path 根目录开始递归遍历，覆盖项目内所有 PHP 源文件（例如 *.php）。
   • 为减少噪音可默认排除 vendor/ 与缓存目录（如需最大召回可把排除策略关闭）。

2. 必覆盖 Sink 集合（最低集）（防 RCE/对象注入漏报）

   • CMD：exec/system/shell_exec/passthru/proc_open/popen/pcntl_exec 与反引号 `cmd`
   • EXPR：eval/assert 以及已弃用但仍常见的 preg_replace(..., ..., .../e) 风险点
   • FILE（执行面边界）：include/require 在“可执行内容/执行边界”上存在风险时（仅读取不等于 RCE，需确认执行语义）
   • DESER：unserialize(...) 在可控输入链上存在潜在魔术方法执行链（静态证据足够时再升级；否则待验证）

3. 扩展扫描（强烈推荐，防 SQL/SSRF/任意读等漏报）：在业务代码目录上，按 shared/PHP_SINK_REFERENCE.md 再扫一轮 SQL 执行族（query/exec/prepare+拼接线索）、SSRF 族（curl_exec/file_get_contents($url) 等）、任意读族（file_get_contents/fopen+路径拼接）。命中写入同一 sink_static_index_{timestamp}.md（或扩展 rce_sinks 附录），条目标注「扩展扫描」；结论仍为 ⚠️待验证 直至 trace 或对应 php-sql-audit/php-ssrf-audit/php-file-read-audit 闭合。

4. 每个命中点的本地分析（必须输出）

   • 位置：file:line、函数/语句、sink 参数表达式（原样摘录关键片段）
   • 可控性回溯：在同一文件/相邻调用链内追踪 sink 参数是否来自请求输入（get/post/request()->param()、$_GET/$_POST/$_REQUEST、JSON php://input 解码结果、header/cookie 等）
   • 执行点确认：若无法证明危险上下文真的会执行（例如分支提前 return/异常跳过/被过滤），结论必须降级为 ⚠️待验证

5. 输出与汇总规则（不依赖 route_id）

   • 输出到 {output_path}/global_sink_fallback/：
     • rce_sinks_{timestamp}.md：RCE/高危执行点静态命中清单（每条包含位置、可控性回溯证据、执行点确认与结论降级理由）
     • sink_static_index_{timestamp}.md：静态命中索引（用于质量统计与后续手工补全 trace）
   • 阶段 5 汇总时：在“质量报告章节”的“漏洞列表总览”中额外引用 global_sink_fallback/rce_sinks_{timestamp}.md，并将这些项标注为“静态证据（非 trace-gate）”。

阶段 3：分批追踪（Only When Trace Proves）

目标：通过 php-route-tracer 的“实际执行证据”，把漏洞挖掘从“关键字扫描”升级为“可控性与分支证据驱动”，最大化真阳性。

阶段 3 必须按以下顺序执行：

1. 生成高危路由集合：

   • 读取 auth_audit/auth_mapping_{timestamp}.md，提取 P0（❌无鉴权）与 P1（⚠️仅认证 或 🔓可绕过/越权/IDOR 的风险路由）
   • 读取 vuln_report/{project_name}_composer_vuln_report_{timestamp}.md，把与解析入口/敏感功能相关的组件漏洞触发点“推断映射”到可能受影响路由，并标注“推断理由”
   • 基于静态参数线索补充 SINK_SUSPECT 路由（不依赖 trace 证据点，trace-gate 在阶段 4 再做硬门槛确认）
     • LDAP：参数名/字段名包含 dn/baseDn/filter/searchFilter/ldap/filterString 等关键词（或其在路由 params 中的 JSON 字段路径）
     • EXPR：参数名/字段名包含 expr/expression/condition/where/rule/eval 等关键词（或其在路由 params 中的 JSON 字段路径）
     • SQL：参数名/字段名包含 sql/query/filter/orderBy/sort/limit/search 等关键词（或其在路由 params 中的 JSON 字段路径）
     • CMD：参数名/字段名包含 cmd/command/exec/shell/run/path/filename 等关键词（或其在路由 params 中的 JSON 字段路径）
     • SSRF：参数名/字段名包含 url/uri/target/host/port/protocol/path 等关键词（或其在路由 params 中的 JSON 字段路径）
     • FILE：参数名/字段名包含 file/path/filename/download/view/document/template 等关键词（或其在路由 params 中的 JSON 字段路径）
     • UPLOAD：参数名/字段名包含 upload/file/tmp_name/filename/multipart 等关键词（或其在路由 params 中的 JSON 字段路径）
     • WRITE：参数名/字段名包含 write/put_contents/fwrite/fopen/rename/copy/truncate/error_log/dest/path/target/path 等关键词（或其在路由 params 中的 JSON 字段路径）
     • XSS：参数名/字段名包含 content/body/comment/title/description/html 等关键词（或其在路由 params 中的 JSON 字段路径）
     • TPL：参数名/字段名包含 template/view/engine/renderer/format/expr 等关键词（或其在路由 params 中的 JSON 字段路径）
     • XXE：参数名/字段名包含 xml/doctype/dtd/xxe 等关键词（或其在路由 params 中的 JSON 字段路径）
     • DESER：参数名/字段名包含 serialize/unserialize/payload/object/serialized 等关键词（或其在路由 params 中的 JSON 字段路径）
     • NOSQL：参数名/字段名包含 filter/query/where/operator/op/regex/whereClause 等关键词（或其在路由 params 中的 JSON 字段路径）
     • REDIR：参数名/字段名包含 next/return_to/redirect/target/url 等关键词（或其在路由 params 中的 JSON 字段路径）
     • CRLF：参数名/字段名包含 header/cookie/location/set-cookie 等关键词（或其在路由 params 中的 JSON 字段路径）
     • ARCHIVE：参数名/字段名包含 zip/tar/phar/archive/entry/extractTo/unzip/untar 等关键词（或其在路由 params 中的 JSON 字段路径）
   • 合成 route_id（强制）：条目来自 CLI/cron/队列、WordPress hook、include 链、阶段 2.5 静态 sink 等且无 HTTP 路由时，须使用稳定 ID（禁止留空），并在同行写明 entry_file（相对 source_path）、entry_symbol（函数/方法或 global）、trace_from（从何处开始向 sink 追踪）。推荐：ENTRY_CLI:{脚本标识}、ENTRY_CRON:{任务名}、ENTRY_QUEUE:{消费者类或文件}、ENTRY_HOOK:{hook 名}、ENTRY_INCLUDE:{文件}:{符号}、SINK_ONLY:{序号}:{基名}:{行号}（可与 sink_static_index 交叉引用）。
   • 输出：cross_analysis/high_risk_routes_{timestamp}.md（含 P0/P1/SINK_SUSPECT；每条须有 route_id（含合成 ID）。php-route-tracer 以 route_id 标识任务，追踪起点以 entry_file+entry_symbol+trace_from 为准，不要求 ID 形如 URI。）

2. 生成分批追踪计划：

   • 读取 high_risk_routes_{timestamp}.md
   • 分批参数化（强制）：顺序 P0 → P1 → SINK_SUSPECT。trace_batch_max_size 默认 10，可在 5–30 间按项目调整；须在计划中写选型理由（例：同模块可合并加大批次；调用链深、跨文件多、参数面宽或上下文预算紧则减小批次）。
   • trace_batch_plan_{timestamp}.md 每一批须含：batch_id、本批采用的 trace_batch_max_size、选型理由（1–3 句）、本批 route_id 有序列表。
   • 输出：cross_analysis/trace_batch_plan_{timestamp}.md

3. 批量调用追踪器（必须）：

   • 对每批路由调用 php-route-tracer
   • 输出：route_tracer/{route_id}/trace_{timestamp}.md

4. 触发条件（硬门槛）：

   • 只有当某类 sink 在 trace 中出现“真实 sink 执行点”，且 trace 契约校验通过，且对应参数在 trace 的可控性矩阵里不是“不可控/无实际使用（被硬编码覆盖）”，才允许进入阶段 4 触发对应 php-*-audit

5. trace 契约校验（必须）：

   • 每个 trace 文件必须包含以下段落/表头（字段名必须一致，不得重命名）：
     • ## 7) Sink Summary
     • ## 5) 参数可控性矩阵
     • ## 6) Sink 定位
     • ## 8) Trace 完整性声明
     • ## 9) Sink Evidence Type Checklist
   • 如果 trace 契约校验失败：
     • 必须标记该 route 的 trace 为 PARTIAL 或 UNRESOLVED
     • 对所有由该 trace 支持的漏洞，状态必须降级为 ⚠️待验证，且不得直接给出 ✅已确认可利用。

Sink 类型抓手、危险模式与强制验证的完整条文见本仓库 shared/PHP_SINK_REFERENCE.md（章节 3.1–3.16 及 LDAP/EXPR）。阶段 3/4 据 trace 筛选是否触发对应 php-*-audit 时，以该文件为准。

阶段 3 输出：

• cross_analysis/high_risk_routes_{timestamp}.md
• cross_analysis/trace_batch_plan_{timestamp}.md
• route_tracer/ 下每条追踪路由的 trace_{timestamp}.md（含参数可控性表与分支路径证据）

阶段 4：Sink 审计执行（Only When Trace Proves）

步骤：

1. 从 route_tracer/ 的 trace 中筛选需要“trace-gate”的漏洞类别与“参数实际使用状态”（必须以 trace 可控性矩阵为准）。
   • trace-gate 类别：SQL/NOSQL/CMD/SSRF/FILE/UPLOAD/WRITE/ARCHIVE/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS
   • 非 trace-gate 类别：CFG/CRYPTO/LOGIC/LOG（可基于静态扫描与代码配置证据直接调用对应 skill，不以 trace ## 9) … CFG 作为唯一门槛）。说明：php-route-tracer 的检查表中虽含 CFG 行，仅作增强证据；php-config-audit 等仍须在阶段 4 无条件按计划执行（除非覆盖矩阵中已用否定证据标为不适用）。
2. 仅对命中的类别调用对应子审计 skill；并满足以下“证据来源”规则（禁止仅凭关键字推断）：
   • 若类别属于 trace-gate：必须逐项引用 php-route-tracer 的 ## 9) Sink Evidence Type Checklist 对应行（FILE/UPLOAD/WRITE/ARCHIVE/SSRF/SQL/NOSQL/CMD/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS）的证据要点作为审计依据（要求证据点 ID 原样一致）
   • 若类别为 AUTH：调用 php-auth-audit 的 TRACE_AUDIT 模式（必须引用 trace 证据点 ID）
3. 对每条疑似漏洞，必须输出“可利用性前置条件”：

• 鉴权要求：✅无需 / ⚠️需登录 / ❌不可利用门槛
• 输入可控性：✅完全可控 / ⚠️条件可控 / ❌不可控（硬编码覆盖）
• 触发条件：分支条件/异常路径/环境依赖（数据库类型、网络可达性）

4. trace 完整性回退规则（必须）：

   • 若 trace_status = PARTIAL：只能进入 ⚠️待验证 模式（不得直接给出 ✅已确认可利用）
   • 若 trace_status = UNRESOLVED：禁止静默漏报——不得写成「无风险」或从报告中消失。必须在总报告 「Trace 未闭合 / 待补证风险池」 中为该 route_id 单列一条：已知片段（来自 trace 的可达部分）、缺失证据、建议下一步（补 trace / 纳入 SINK_ONLY 静态深审 / 调用对应 php-*-audit）。若该路由与阶段 2.5 静态命中可关联，须写交叉引用。

5. 文件系统操作审计（非 trace-gate，静态证据驱动）：

   • 调用：php-filesystem-audit
   • 输出：vuln_audit/fs_{timestamp}.md
   • 判定规则：允许基于源代码定位的“文件系统操作证据链 + 路径控制来源 + TOCTOU/链接绕过解释”直接输出 ✅/⚠️/❌/🔍，不以 php-route-tracer 的证据契约字段为前置硬门槛

并最终给出：

• 状态：✅已确认 / ⚠️待验证 / ❌不可利用 / 🔍环境依赖
• 严重等级与 CVSS 映射（按上方公式）

阶段 5：汇总报告（Report）

在总报告中生成“质量报告章节”，包含：

• 子 skill / 审计面覆盖矩阵：与上文「子审计覆盖矩阵（强制）」同结构，置于质量报告靠前位置；须与阶段 4 实际执行情况一致，不得矛盾。

• 风险统计表（🔴/🟠/🟡/🔵 数量与 CVSS 区间）

• 漏洞列表总览（逐条引用本报告中对应的漏洞详情段落）

• 「Trace 未闭合 / 待补证风险池」（强制）：汇总 trace_status ∈ {PARTIAL, UNRESOLVED} 的 route_id、阶段 2.5 sink_static_index 中尚未被 trace 闭合的条目、以及「扩展扫描」命中项；与「漏洞列表总览」并列，禁止因证据不足而删除记录（未闭合 ≠ 无风险）。

• 覆盖率：路由覆盖、鉴权覆盖、Sink 覆盖、关键分支覆盖（用“已完成/待补充”而非省略；建议阈值：路由覆盖与 Sink 覆盖 >= 90%）

• 框架特效审计汇总：如果存在 framework_audit/*.md，需要将其风险映射到统一类型码（AUTH/CSRF/TPL/XSS/SQL/LOGIC/CFG/SESS/SSRF/…），统计数量与最高严重等级，并在汇总中注明“框架风险来源于哪些 framework_audit 报告文件”

  框架审计豁免说明：框架特效审计（Laravel/Symfony/WordPress/CodeIgniter/Yii2/ThinkPHP）属于“静态配置/模式匹配”型审计，其发现的风险不需要经过 php-route-tracer 的 trace-gate 或 ## 9) Sink Evidence Type Checklist 的证据校验。框架审计结果直接按其自身规则分级并映射到统一类型码即可。

• 证据完整度评分（Evidence Completeness）：对所有 trace-gate sink 类型（FILE/UPLOAD/WRITE/ARCHIVE/SSRF/SQL/NOSQL/CMD/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS），按 shared/EVIDENCE_POINT_IDS.md 中定义的证据点 ID 集合进行计数：覆盖率% = 已满足证据点数 / 该类型所需证据点总数 × 100%；并在表格中列出缺失的证据点 ID（必须原样一致）与缺失原因（如 trace_status=PARTIAL/UNRESOLVED、证据点定位失败、参数不可控等）。

阶段 5.1：利用链聚合（强制）

• 调用：php-exploit-chain-audit
• 在“质量报告章节”的“漏洞列表总览”之后增加一段“利用链聚合章节”：引用利用链聚合报告的链路总览表与最短利用链（只需引用、不重复内容）。

漏洞详情模板（强制使用）

每条漏洞必须遵循以下结构（写入本次总报告的漏洞详情段落）：

### [{等级前缀}-{类型代码}-{序号}] {风险标题}

| 项目 | 信息 |
|------|------|
| 严重等级 | {🔴/🟠/🟡/🔵} (CVSS {score}) |
| 可达性 (R) | {0-3} - {理由} |
| 影响范围 (I) | {0-3} - {理由} |
| 利用复杂度 (C) | {0-3} - {理由} |
| 可利用性 | ✅ 已确认 / ⚠️ 待验证 / ❌ 不可利用 / 🔍 环境依赖 |
| 位置 | {文件路径}:{行号} ({函数/方法}) |

#### 数据流链（Source → Sink）

(按路由逐行写出赋值/传递/拼接/校验/分支，禁止省略)

可利用前置条件

• 鉴权要求：{无需/需登录/需特定权限}
• 输入可控性：{完全可控/条件可控/不可控}
• 触发条件：{分支/异常/环境依赖}

验证 PoC（强制给出可执行请求）

{HTTP Method} {完整路径与查询/Body} HTTP/1.1
Host: {host}
{必要 Header/Session/JWT/Cookie}

{Payload}

建议修复

• 以“代码替换建议”为主（给出安全写法要点）
• 给出“如何在代码中搜索修复是否遗漏”的搜索语句（bash/rg 形式）

## 说明文档（审计 READMEs）
必须在本次总报告内生成以下附录章节：
- 如何识别 PHP 路由与参数
- 如何识别会话/JWT 并审计鉴权链
- 如何结合 `shared/PHP_SINK_REFERENCE.md` 做按类型的 Sink 挖掘与 trace-gate 对齐

## 自检与质量保证（强制）
在标记完成前，必须回答并自检：
- [ ] 「子 skill / 审计面覆盖矩阵」是否已对对照表**每一行**给出已执行/不适用/已延期，且不适用与已延期均附触发依据或否定证据？
- [ ] 我是否按 `shared/PHP_SINK_REFERENCE.md` 与 trace 结果覆盖了常见高危类别（SQL/NOSQL/CMD/SSRF/XSS/FILE/UPLOAD/WRITE/ARCHIVE/XXE/DESER/TPL/AUTH/CSRF/REDIR/CRLF/SESS/CRYPTO/CFG/LOG/FS）？
- [ ] 我是否覆盖 LDAP/EXPR（或矩阵中「不适用」已附否定证据）？
- [ ] 每条漏洞是否都有数据流链与可利用前置条件？
- [ ] 是否没有任何省略写法？
- [ ] 是否没有任何未替换的模板占位符？
- [ ] **「Trace 未闭合 / 待补证风险池」**是否已列出所有 `PARTIAL/UNRESOLVED` 及 2.5 未闭合静态命中，且与漏洞列表无矛盾？

## 子 Skill 对照表（能力清单 + 矩阵对齐）
下表为**必须出现在「子 skill / 审计面覆盖矩阵」中的行清单**。阶段 3/4 按 trace-gate 与静态证据触发对应 skill；**未执行**的行须在矩阵中标记「不适用」或「已延期」并满足矩阵列要求（禁止空行、禁止无理由跳过）。

1. 路由/参数：`php-route-mapper`
2. 鉴权：`php-auth-audit`
3. 深度追踪：`php-route-tracer`（用于任何需要可控性/分支证据的场景）
4. 组件漏洞（供应链）：`php-vuln-scanner`

5. 利用链聚合：`php-exploit-chain-audit`（在阶段 5.1 强制调用）

6. 文件系统操作审计：`php-filesystem-audit`（在阶段 4 以静态证据驱动执行）

按漏洞类别调用：
- SQL 注入：`php-sql-audit`
- NoSQL 注入：`php-nosql-audit`
- 命令注入：`php-cmd-audit`
- SSRF：`php-ssrf-audit`
- XSS：`php-xss-audit`
- 模板注入/SSTI：`php-tpl-audit`
- LDAP 注入：`php-ldap-audit`
- 表达式注入（非模板）：`php-expr-audit`
- 任意文件读取/路径穿越：`php-file-read-audit`
- 文件上传：`php-file-upload-audit`
- 任意文件写入：`php-file-write-audit`
- 归档解压路径穿越/Zip Slip：`php-archive-extract-audit`
- XXE：`php-xxe-audit`
- 反序列化/对象注入：`php-deser-audit`
- 认证/鉴权绕过/越权/IDOR：`php-auth-audit`（与鉴权状态、资源归属一起落入汇总）
- CSRF：`php-csrf-audit`
- 开放重定向：`php-open-redirect-audit`
- CRLF/响应分割：`php-crlf-audit`
- 会话与 Cookie 安全：`php-session-cookie-audit`
- 加密与密钥安全：`php-crypto-audit`
- 安全配置（CORS/错误暴露/安全头/危险开关）：`php-config-audit`
- 业务逻辑漏洞（Mass Assignment/竞态/状态机/流程绕过）：`php-logic-audit`
- 安全日志与监控：`php-logging-audit`