Agent Skills
› NeverSight/learn-skills.dev
› php-audit-pipeline
php-audit-pipeline
GitHubPHP Web全链路白盒安全审计总编排Skill。通过调用子Skill（路由、鉴权等）或执行降级流程，结合三层分析法与10大维度，输出标准化漏洞审计报告及分级结论。
触发场景
需要执行PHP项目全面代码安全审计
请求生成PHP应用漏洞分析报告
进行PHP供应链或业务逻辑安全评估
安装
npx skills add NeverSight/learn-skills.dev --skill php-audit-pipeline -g -y
SKILL.md
Frontmatter
{
"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 参数变量来自哪里：例如
-
最后做执行点确认（真实落点）
- 确认该 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：SSRFXSS：跨站脚本FILE：任意文件读取/路径穿越UPLOAD：任意文件上传/可执行上传WRITE：任意文件写入（路径穿越到写入落点）REDIR：开放重定向CRLF：CRLF/响应分割XXE：XXEDESER：反序列化/对象注入TPL：模板注入/SSTILDAP：LDAP 注入/查询过滤器注入/DN 注入EXPR：表达式注入（非模板表达式求值；包含 eval/assert 等）AUTH：认证/鉴权绕过/越权（含 IDOR）CSRF：CSRFSESS：会话固定/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分发
- Laravel：
-
枚举路由/入口（必做，禁止省略）
- 从路由配置或分发逻辑中提取：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）
- 识别 Source：
-
识别认证链与会话机制（必做）
- Session：
session_start()、$_SESSION['key']、登录态判断 - JWT：
JWT::decode、签名校验逻辑、Authorization: Bearer - Middlewares：Laravel middleware、Symfony event listener、Slim middleware
- 自定义鉴权：
checkAuth()/requireLogin()/authorize()类函数
- Session：
-
生成鉴权映射（静态映射，先不依赖 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(...)在可控输入链上存在潜在魔术方法执行链（静态证据足够时再升级；否则待验证）
- CMD：
-
扩展扫描（强烈推荐，防 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、JSONphp://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 字段路径）
- LDAP：参数名/字段名包含
- 合成
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
- 只有当某类 sink 在 trace 中出现“真实 sink 执行点”，且 trace 契约校验通过，且对应参数在 trace 的可控性矩阵里不是“不可控/无实际使用（被硬编码覆盖）”，才允许进入阶段 4 触发对应
-
trace 契约校验（必须）：
- 每个 trace 文件必须包含以下段落/表头（字段名必须一致，不得重命名）：
## 7) Sink Summary## 5) 参数可控性矩阵## 6) Sink 定位## 8) Trace 完整性声明## 9) Sink Evidence Type Checklist
- 如果 trace 契约校验失败：
- 必须标记该 route 的 trace 为
PARTIAL或UNRESOLVED - 对所有由该 trace 支持的漏洞，状态必须降级为
⚠️待验证，且不得直接给出✅已确认可利用。
- 必须标记该 route 的 trace 为
- 每个 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}.mdcross_analysis/trace_batch_plan_{timestamp}.mdroute_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-gate：必须逐项引用
- 对每条疑似漏洞，必须输出“可利用性前置条件”：
- 鉴权要求：✅无需 / ⚠️需登录 / ❌不可利用门槛
- 输入可控性：✅完全可控 / ⚠️条件可控 / ❌不可控（硬编码覆盖）
- 触发条件：分支条件/异常路径/环境依赖（数据库类型、网络可达性）
-
trace 完整性回退规则（必须）：
- 若 trace_status = PARTIAL：只能进入
⚠️待验证模式（不得直接给出✅已确认可利用） - 若 trace_status = UNRESOLVED：禁止静默漏报——不得写成「无风险」或从报告中消失。必须在总报告 「Trace 未闭合 / 待补证风险池」 中为该
route_id单列一条：已知片段（来自 trace 的可达部分）、缺失证据、建议下一步（补 trace / 纳入SINK_ONLY静态深审 / 调用对应php-*-audit）。若该路由与阶段 2.5 静态命中可关联，须写交叉引用。
- 若 trace_status = PARTIAL：只能进入
-
文件系统操作审计（非 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.5sink_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`
版本历史
- c3c0a1e 当前 2026-07-23 06:43
