name	php-audit-pipeline
description	PHP Web 全链路白盒代码安全审计流水线（多文件版编排）。作为总编排参考，按 Sink 类型调用各子审计 skill（`php-route-mapper/php-auth-audit/php-route-tracer/php-*-audit`），并复用统一输出与分级标准。

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

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

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

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

先做关键字/函数抓手定位（Source/Sink）
- 从 source_path 根目录开始递归遍历（不限定具体业务目录；默认仍排除 vendor/、缓存目录，可按需要调整）检索 Source/Sink 候选。
- 对每个命中的 Sink，记录：文件路径、函数/方法签名、所在控制器/中间件/服务类上下文、sink 参数变量名。
再做参数可控性验证（可控性矩阵）
- 追踪 sink 参数变量来自哪里：例如 get_params()、request()->post()、$_GET/$_POST/$_REQUEST、body（php://input）、header/cookie。
- 判断该参数在进入危险拼接/执行前是否被：白名单/枚举校验、类型转换、转义/过滤、长度/字符集约束等硬化覆盖。
- 输出可控性状态：✅完全可控 / ⚠️条件可控 / ❌不可控，并写出拦截/硬化点的代码证据位置。
最后做执行点确认（真实落点）
- 确认该 sink 参数最终是否真的在危险上下文执行，而不是仅被传入后又被安全处理或未真正触发。
- 若无法证明“真实落点执行”，一律标记为 ⚠️待验证 / 🔍环境依赖，不要写 ✅已确认可利用。
输出建议（用于降低误报）
- 只要涉及“执行点/分支”无法完整证明，就把结论降级为待验证，并把缺失证据点写清楚（例如：分支条件未覆盖、输入在上游被过滤、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 全链路代码审计流水线（白盒）

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

编排说明

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

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

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

子审计覆盖矩阵（强制）

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

列	含义
子 skill 或审计面	与对照表名称一致
状态	已执行 / 不适用 / 已延期（三选一，禁止留空）
触发依据	已执行：依据（trace-gate、静态 sink、配置证据等）；不适用：否定证据（如全仓库检索无相关 API，须写明范围与 ripgrep 模式）；已延期：残留风险与补做条件
产出锚点	总报告中章节标题或段落首句，便于复核

规则：不要求单次会话内对每个子 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：安全日志与监控缺陷（缺失审计/敏感信息写入/日志注入等）

关键约束（强制）

完整性约束

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

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

识别技术栈/入口形态（必做）
- 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 分发
枚举路由/入口（必做，禁止省略）
- 从路由配置或分发逻辑中提取：HTTP 方法、路径/规则、对应 handler（文件/函数/类方法）
- 对动态路由（如 {id}、正则路由、WordPress 参数路由）必须写出“解析规则与可控参数列表”
枚举参数（必做）
- 识别 Source：$_GET/$_POST/$_REQUEST/$_FILES/$_COOKIE、php://input、getallheaders()
- 识别 JSON：json_decode(file_get_contents('php://input'), true)
- 识别文件：$_FILES['{file_field}'] 字段与文件名来源（name/tmp_name）
识别认证链与会话机制（必做）
- Session：session_start()、$_SESSION['key']、登录态判断
- JWT：JWT::decode、签名校验逻辑、Authorization: Bearer
- Middlewares：Laravel middleware、Symfony event listener、Slim middleware
- 自定义鉴权：checkAuth()/requireLogin()/authorize() 类函数
生成鉴权映射（静态映射，先不依赖 trace）
- 调用：php-auth-audit
- 模式：STATIC_MAPPING（仅生成 auth_mapping_{timestamp}.md 用于 P0/P1 路由分桶）
- 约束：当尚未生成 route_tracer/ trace 时，允许“缺少 trace 契约证据点”，但必须输出“鉴权状态分级 + P0/P1 分桶依据”
供应链漏洞扫描（组件已知 CVE/Advisory）
- 调用：php-vuln-scanner
- 输出：vuln_report/{project_name}_composer_vuln_report_{timestamp}.md
框架特效审计（可选：检测到对应框架才调用）
- 检测原则（必做）：依据 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 的确认结果，仅作为补漏兜底。

扫描范围（不限定目录）
- 从 source_path 根目录开始递归遍历，覆盖项目内所有 PHP 源文件（例如 *.php）。
- 为减少噪音可默认排除 vendor/ 与缓存目录（如需最大召回可把排除策略关闭）。
必覆盖 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(...) 在可控输入链上存在潜在魔术方法执行链（静态证据足够时再升级；否则待验证）
扩展扫描（强烈推荐，防 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 闭合。
每个命中点的本地分析（必须输出）
- 位置：file:line、函数/语句、sink 参数表达式（原样摘录关键片段）
- 可控性回溯：在同一文件/相邻调用链内追踪 sink 参数是否来自请求输入（get/post/request()->param()、$_GET/$_POST/$_REQUEST、JSON php://input 解码结果、header/cookie 等）
- 执行点确认：若无法证明危险上下文真的会执行（例如分支提前 return/异常跳过/被过滤），结论必须降级为 ⚠️待验证
输出与汇总规则（不依赖 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 必须按以下顺序执行：

生成高危路由集合：
- 读取 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。）
生成分批追踪计划：
- 读取 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
批量调用追踪器（必须）：
- 对每批路由调用 php-route-tracer
- 输出：route_tracer/{route_id}/trace_{timestamp}.md
触发条件（硬门槛）：
- 只有当某类 sink 在 trace 中出现“真实 sink 执行点”，且 trace 契约校验通过，且对应参数在 trace 的可控性矩阵里不是“不可控/无实际使用（被硬编码覆盖）”，才允许进入阶段 4 触发对应 php-*-audit
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）

步骤：

从 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 无条件按计划执行（除非覆盖矩阵中已用否定证据标为不适用）。
仅对命中的类别调用对应子审计 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）
对每条疑似漏洞，必须输出“可利用性前置条件”：

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

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

name	php-audit-pipeline
description	PHP Web 全链路白盒代码安全审计流水线（多文件版编排）。作为总编排参考，按 Sink 类型调用各子审计 skill（`php-route-mapper/php-auth-audit/php-route-tracer/php-*-audit`），并复用统一输出与分级标准。

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

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

先做关键字/函数抓手定位（Source/Sink）
- 从 source_path 根目录开始递归遍历（不限定具体业务目录；默认仍排除 vendor/、缓存目录，可按需要调整）检索 Source/Sink 候选。
- 对每个命中的 Sink，记录：文件路径、函数/方法签名、所在控制器/中间件/服务类上下文、sink 参数变量名。
再做参数可控性验证（可控性矩阵）
- 追踪 sink 参数变量来自哪里：例如 get_params()、request()->post()、$_GET/$_POST/$_REQUEST、body（php://input）、header/cookie。
- 判断该参数在进入危险拼接/执行前是否被：白名单/枚举校验、类型转换、转义/过滤、长度/字符集约束等硬化覆盖。
- 输出可控性状态：✅完全可控 / ⚠️条件可控 / ❌不可控，并写出拦截/硬化点的代码证据位置。
最后做执行点确认（真实落点）
- 确认该 sink 参数最终是否真的在危险上下文执行，而不是仅被传入后又被安全处理或未真正触发。
- 若无法证明“真实落点执行”，一律标记为 ⚠️待验证 / 🔍环境依赖，不要写 ✅已确认可利用。
输出建议（用于降低误报）
- 只要涉及“执行点/分支”无法完整证明，就把结论降级为待验证，并把缺失证据点写清楚（例如：分支条件未覆盖、输入在上游被过滤、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 全链路代码审计流水线（白盒）

编排说明

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

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

子审计覆盖矩阵（强制）

列	含义
子 skill 或审计面	与对照表名称一致
状态	已执行 / 不适用 / 已延期（三选一，禁止留空）
触发依据	已执行：依据（trace-gate、静态 sink、配置证据等）；不适用：否定证据（如全仓库检索无相关 API，须写明范围与 ripgrep 模式）；已延期：残留风险与补做条件
产出锚点	总报告中章节标题或段落首句，便于复核

规则：不要求单次会话内对每个子 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：安全日志与监控缺陷（缺失审计/敏感信息写入/日志注入等）

关键约束（强制）

完整性约束

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

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

识别技术栈/入口形态（必做）
- 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 分发
枚举路由/入口（必做，禁止省略）
- 从路由配置或分发逻辑中提取：HTTP 方法、路径/规则、对应 handler（文件/函数/类方法）
- 对动态路由（如 {id}、正则路由、WordPress 参数路由）必须写出“解析规则与可控参数列表”
枚举参数（必做）
- 识别 Source：$_GET/$_POST/$_REQUEST/$_FILES/$_COOKIE、php://input、getallheaders()
- 识别 JSON：json_decode(file_get_contents('php://input'), true)
- 识别文件：$_FILES['{file_field}'] 字段与文件名来源（name/tmp_name）
识别认证链与会话机制（必做）
- Session：session_start()、$_SESSION['key']、登录态判断
- JWT：JWT::decode、签名校验逻辑、Authorization: Bearer
- Middlewares：Laravel middleware、Symfony event listener、Slim middleware
- 自定义鉴权：checkAuth()/requireLogin()/authorize() 类函数
生成鉴权映射（静态映射，先不依赖 trace）
- 调用：php-auth-audit
- 模式：STATIC_MAPPING（仅生成 auth_mapping_{timestamp}.md 用于 P0/P1 路由分桶）
- 约束：当尚未生成 route_tracer/ trace 时，允许“缺少 trace 契约证据点”，但必须输出“鉴权状态分级 + P0/P1 分桶依据”
供应链漏洞扫描（组件已知 CVE/Advisory）
- 调用：php-vuln-scanner
- 输出：vuln_report/{project_name}_composer_vuln_report_{timestamp}.md
框架特效审计（可选：检测到对应框架才调用）
- 检测原则（必做）：依据 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 及扩展高危）

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

扫描范围（不限定目录）
- 从 source_path 根目录开始递归遍历，覆盖项目内所有 PHP 源文件（例如 *.php）。
- 为减少噪音可默认排除 vendor/ 与缓存目录（如需最大召回可把排除策略关闭）。
必覆盖 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(...) 在可控输入链上存在潜在魔术方法执行链（静态证据足够时再升级；否则待验证）
扩展扫描（强烈推荐，防 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 闭合。
每个命中点的本地分析（必须输出）
- 位置：file:line、函数/语句、sink 参数表达式（原样摘录关键片段）
- 可控性回溯：在同一文件/相邻调用链内追踪 sink 参数是否来自请求输入（get/post/request()->param()、$_GET/$_POST/$_REQUEST、JSON php://input 解码结果、header/cookie 等）
- 执行点确认：若无法证明危险上下文真的会执行（例如分支提前 return/异常跳过/被过滤），结论必须降级为 ⚠️待验证
输出与汇总规则（不依赖 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 必须按以下顺序执行：

生成高危路由集合：
- 读取 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。）
生成分批追踪计划：
- 读取 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
批量调用追踪器（必须）：
- 对每批路由调用 php-route-tracer
- 输出：route_tracer/{route_id}/trace_{timestamp}.md
触发条件（硬门槛）：
- 只有当某类 sink 在 trace 中出现“真实 sink 执行点”，且 trace 契约校验通过，且对应参数在 trace 的可控性矩阵里不是“不可控/无实际使用（被硬编码覆盖）”，才允许进入阶段 4 触发对应 php-*-audit
trace 契约校验（必须）：
- 每个 trace 文件必须包含以下段落/表头（字段名必须一致，不得重命名）：
  - ## 7) Sink Summary
  - ## 5) 参数可控性矩阵
  - ## 6) Sink 定位
  - ## 8) Trace 完整性声明
  - ## 9) Sink Evidence Type Checklist
- 如果 trace 契约校验失败：
  - 必须标记该 route 的 trace 为 PARTIAL 或 UNRESOLVED
  - 对所有由该 trace 支持的漏洞，状态必须降级为 ⚠️待验证，且不得直接给出 ✅已确认可利用。

阶段 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）

步骤：

从 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 无条件按计划执行（除非覆盖矩阵中已用否定证据标为不适用）。
仅对命中的类别调用对应子审计 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）
对每条疑似漏洞，必须输出“可利用性前置条件”：

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

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

php-audit-pipeline

이 저장소의 다른 Skills

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

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

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

编排说明

子审计覆盖矩阵（强制）

角色与方法

三层分析法（强制）

10 个安全维度

漏洞分级（强制使用）

严重等级计算公式

三维评分标准（强制）

等级映射（强制）

漏洞编号规范（强制）

关键约束（强制）

完整性约束

输出完整性校验（强制）

输入

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

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

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

阶段 1：侦察（Recon）

阶段 2：建模（Modeling）

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

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

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

阶段 5：汇总报告（Report）

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

可利用前置条件

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

建议修复

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

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

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

编排说明

子审计覆盖矩阵（强制）

角色与方法

三层分析法（强制）

10 个安全维度

漏洞分级（强制使用）

严重等级计算公式

三维评分标准（强制）

等级映射（强制）

漏洞编号规范（强制）

关键约束（强制）

完整性约束

输出完整性校验（强制）

输入

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

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

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

阶段 1：侦察（Recon）

阶段 2：建模（Modeling）

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

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

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

阶段 5：汇总报告（Report）

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

可利用前置条件

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

建议修复

이 저장소의 다른 Skills