关于 attack-patterns-reference
attack-patterns-reference 是用于分类 Web 和 WordPress 行为并指向验证技能的安全测试目录,面向授权测试人员。它帮助区分初始信号与已验证影响,不将模式本身视为漏洞发现。
主要功能
- 01将 Web 信号映射到验证技能
- 02涵盖 WordPress、CORS 和 XML-RPC 模式
- 03列出候选攻击路径的前提条件
- 04强调证据与负向对照
适用场景
- 01测试前分类侦察结果
- 02为 WordPress 信号选择后续技能
- 03评估候选攻击路径前检查前提条件
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ uphiago/ recon-skills --skill attack-patterns-reference安装后在 Claude Code 中输入/attack-patterns-reference确认已加载。
附带文件references/p-patterns.md
详细介绍
攻击模式参考
本目录将观察到的 Web 和 WordPress 行为映射到负责验证的技能。模式 ID 仅用于导航,不代表可利用性、严重程度、普遍程度或已确认的攻击路径。
适用场景
- 需要在开展针对性测试前对侦察结果进行分类。
- 多种已验证行为可能构成候选攻击路径。
- WordPress、CORS、XML-RPC、源码泄露或服务暴露信号需要对应的验证流程。
请勿将本目录用作扫描器发现列表,也不要用它替代负责技能中的验证部分。
前提条件
- 已获授权的目标以及当前范围限制。
- 已捕获待分类观察结果的证据。
- 所选后续技能所需的工具和身份。
运行方法
- 将观察到的行为与最接近的模式匹配。
- 打开表格中列出的负责技能。
- 检查其前提条件和副作用。
- 执行能证伪假设的最小验证和负向对照。
- 将结果记录为已观察、已推断、已确认或未测试。
流程
常见 Web 模式
| 模式 | 初始信号 | 负责技能 |
|---|---|---|
| WordPress 用户暴露 | REST 或作者路由返回用户元数据 | wp-mass-recon |
| 带凭据的 CORS | 反映不可信来源并允许凭据 | cors-credential-wordpress |
| XML-RPC 方法 | 返回符合协议的 system.listMethods 响应 | xmlrpc-exploitation |
| XML-RPC SSRF | pingback.ping 到达受控回调 | xmlrpc-exploitation |
| 公开注册 | 已启用注册 | wp-mass-recon |
| 插件攻击面 | REST 命名空间、资源文件或版本标记 | wordpress-plugin-hunt |
| 预发布环境差异 | 非生产主机的控制措施较弱 | staging-subdomain-hunt |
| 错误日志暴露 | 响应包含真实应用错误 | error-log-mining |
| PHPInfo 暴露 | 可访问 PHP 配置页面 | phpinfo-to-rce |
| 源码或备份泄露 | 响应包含代码仓库、配置或数据库内容 | source-leak-hunt |
| JavaScript 密钥候选 | Bundle 中包含类似凭据的值 | js-secrets-extraction |
| 公开服务 | 非 HTTP 或管理服务可从互联网访问 | port-service-discovery |
扩展模式说明请参阅 references/p-patterns.md。
CORS 变体
| 变体 | 初始信号 | 所需验证 |
|---|---|---|
| 带凭据的来源反射 | 不可信来源加上 ACAC: true | 带凭据的浏览器可读取非公开数据 |
| 信任空来源 | ACAO: null 加上 ACAC: true | 沙盒浏览器可读取非公开数据 |
| 无凭据的通配符 | ACAO: * | 确定响应是否已经公开 |
| 带凭据的预检请求 | OPTIONS 接受来源、方法和标头 | 实际请求成功,且浏览器可读取响应 |
| 身份验证路由 CORS | 受保护路由上出现 CORS 标头 | 已批准的会话可读取受保护数据 |
| 特定插件的 CORS | 只有一个插件命名空间接受该来源 | 响应包含受保护数据,或执行经过授权的测试操作 |
| 特定环境的 CORS | 预发布环境和生产环境策略不同 | 在获授权环境中证明影响 |
| 第三方允许列表 | 信任一个外部服务来源 | 确认对该来源的控制权及受保护数据访问权限 |
候选攻击路径
这些是组合模板,并非已确认的发现:
| 路径 | 必须验证的前提条件 |
|---|---|
| 从 CORS 到受保护数据读取 | 已批准的会话、不可信来源、可由浏览器读取的非公开响应 |
| 从 XML-RPC SSRF 到云元数据 | 受控回调、可访问的元数据服务、可用的次要影响 |
| 从开放注册到文件上传 | 已批准的合成账户、具备上传能力的角色、可执行的文件路径 |
| 从暴露的日志到账户访问 | 当前凭据材料、已批准的身份、有效的身份验证控制 |
| 从暂存环境暴露到生产环境影响 | 共享信任边界、可复用的密钥或部署路径、明确的范围 |
只有在独立验证每项前提后,才使用 cross-attack-chains。
注意事项
- 历史频率不能证明当前目标存在问题。
- 产品名称、版本、状态代码或标头都不能证明影响。
- 兜底路由可能会让敏感路径看起来可以访问。
- 公开的客户端标识符和有意公开的 API 并不自动构成凭据或授权失败。
- 不同产品和插件版本的模式前提条件会有所变化。
- 攻击路径的不确定性取决于其中最不确定的步骤。
验证
- 将每个模式与捕获的请求和响应证据相匹配。
- 执行负向对照,以区分结果与公开或通用行为。
- 使用浏览器验证 CORS 影响;仅凭标头不足以确认。
- 使用受控回调验证盲 SSRF;仅凭协议状态不足以确认。
- 在关联 CVE 前,检查确切的组件和前提条件。
- 仅报告在范围内复现的影响。
评论
支持 Markdown