بنقرة واحدة
php-exploit-chain-audit
PHP 利用链/POP(回弹)链聚合器。把已产出的各类漏洞报告按“前置条件满足”串成可利用链路叙事(不新增证据点字典)。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
PHP 利用链/POP(回弹)链聚合器。把已产出的各类漏洞报告按“前置条件满足”串成可利用链路叙事(不新增证据点字典)。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
PHP Web 归档解压(Zip Slip/路径穿越)审计工具。识别解压条目名如何与目标目录拼接、是否存在 base dir 约束缺失,输出可利用性分级、可观测 PoC 与修复建议(禁止省略)。
PHP Web 全链路白盒代码安全审计流水线(多文件版编排)。作为总编排参考,按 Sink 类型调用各子审计 skill(`php-route-mapper/php-auth-audit/php-route-tracer/php-*-audit`),并复用统一输出与分级标准。
PHP Web 源码鉴权机制审计工具。从源码中识别所有认证/鉴权实现并分析风险,输出路由-鉴权映射与漏洞分析(含 PoC 与修复建议)。
PHP Web 源码命令注入审计工具。识别命令执行 Sink(exec/system/shell_exec 等),追踪用户输入进入命令拼接,输出可利用性分级、PoC 与修复建议(禁止省略)。
CodeIgniter 框架特效安全审计工具。针对 CodeIgniter 的 CSRF、XSS 输出过滤、数据库查询构造、路由与验证器配置、会话 Cookie 安全等机制进行白盒静态审计,并映射到通用漏洞类型体系(CSRF/AUTH/XSS/SQL/CFG/SESS 等)。
PHP Web 配置安全审计工具。识别 CORS/错误暴露/调试开关/安全头/危险运行时开关等,输出分级、可利用性分析、PoC 与修复建议(禁止省略)。
| name | php-exploit-chain-audit |
| description | PHP 利用链/POP(回弹)链聚合器。把已产出的各类漏洞报告按“前置条件满足”串成可利用链路叙事(不新增证据点字典)。 |
目标:将 vuln_audit/*_{timestamp}.md(以及可能的 auth_audit/*_{timestamp}.md)里的已确认/待验证漏洞,基于“可利用前置条件”串联成跨阶段利用链,并输出可观测的利用链叙事。
EVID_* 证据点字典,也不要求 php-route-tracer 直接输出额外契约字段。vuln_audit/*_{timestamp}.md:来自各 sink 子 skill 的漏洞报告集合(包含编号、可利用性、触发条件、位置证据与数据流链)。auth_audit/auth_audit_report_{timestamp}.md:用于补充链路中“鉴权门槛”是否一致(如漏洞链经过不同路由)。route_tracer/:如果需要补充“同一 route 的 sink 执行证据”,可通过漏洞报告中的 trace 证据引用回溯(不强制)。输出到:
{output_path}/exploit_chain/exploit_chains_{timestamp}.md
必须包含以下结构(不得省略):
# Exploit Chains (PHP) - Aggregation
项目路径: {source_path}
生成时间: {timestamp}
---
## 1) 利用链总览表
| chain_id | 链路类型 | 起点漏洞(编号) | 中间漏洞(编号) | 终点漏洞(编号) | 链路可利用性 | 关键依赖(路由/前置条件) |
|----------|----------|----------------|-------------------|------------------|----------------|------------------------------|
| | | | | | | |
---
## 2) 最短利用链(强制至少 1 条;若无则输出“未发现可拼接利用链”)
chain_id: {id}
### 2.{n}) 链路逐步叙事(按顺序)
Step 1: {漏洞编号}(类型 {SQL/CMD/FILE/WRITE/UPLOAD/DESER/TPL/EXPR/...})
- 触发路由/入口:{route info from vuln report}
- 可利用性:{✅/⚠️/❌/🔍}(来自漏洞报告“可利用性”字段)
- 前置条件是否满足:{是/否/待验证}(解释依据:鉴权门槛、输入可控性、trace_status)
Step 2: {漏洞编号}
- ...
Step Final: {终点漏洞编号}
- 为什么它是终点(导致最关键的敏感操作):{从 vuln report 中提取的结论性描述;不需要再堆证据点细节}
### 关键证据引用(链路级)
按 Step 顺序列出:
- {漏洞报告文件名}:{漏洞编号}(从该漏洞报告中提取“触发条件/可利用性前置条件/PoC 所需路由”)
---
## 3) “未能串联”的原因清单(强制)
列出至少以下类别:
1. 缺少关键落点/可访问性证据(例如 WRITE/UPLOAD 后未形成可读/可执行面)
2. 路由鉴权不一致(链上部分漏洞需要的权限与另一路由不匹配)
3. trace_status 不满足(PARTIAL/UNRESOLVED 导致无法确认链路可利用)
4. 需要特定环境依赖(🔍)
每条原因必须至少引用 1 个具体漏洞编号(来自 vuln_audit)。
建议从以下方向优先生成链(存在则写入,不存在就略过):
chain 可利用性由链路最弱环节决定:
✅ 已确认,则链路为 ✅ 已确认⚠️ 待验证(且非仅信息性缺失),则链路为 ⚠️ 待验证❌ 不可利用,则链路为 ❌ 不可利用🔍 环境依赖,且无法在其它 Step 中兜底,则链路为 🔍 环境依赖