cross-attack-chains

跨漏洞攻击链

攻击链是一系列经过验证的安全行为，其中每一步都为下一步提供前提条件。同一目标上的多个发现并不构成攻击链，除非已证明它们之间存在依赖关系。

适用场景

• 两个或多个已验证的发现影响同一信任边界。
• 某个发现暴露了另一个发现所需的身份、令牌、路由、主机或能力。
• 报告需要区分单独影响与复合影响。
• 无法安全地测试攻击链的下一步，因此必须将其标记为推断。

前提条件

• 每个组件发现都具备已捕获的证据和负向对照。
• 已获得当前授权，涵盖复合测试及任何增加的副作用。
• 已批准使用相关身份、合成记录、回调和清理流程。
• 对敏感数据、可用性或范围变化设定了明确的停止条件。

运行方法

在目标输出目录下创建攻击链记录：

TARGET_ID="example-test"
OUTPUT_DIR="${OUTPUT_DIR:-./output}"
CHAIN_DIR="$OUTPUT_DIR/$TARGET_ID/chains"

mkdir -p "$CHAIN_DIR"
touch "$CHAIN_DIR/EXPLOIT_CHAINS.md"

一致使用以下证据状态：

状态	含义
已观察	存在于已捕获的输出中
已确认	通过对照重现了安全影响
已推断	依赖关系看似合理，但尚未测试
未测试	因范围、安全性或缺少前提条件而排除

流程

1. 规范化组件发现

对于每个组件，记录：

• 预期行为和观察到的行为；
• 目标、身份和时间戳；
• 正向证据和负向对照；
• 副作用和清理操作；
• 已证明的影响；
• 假设和测试限制。

对于尚未通过所属技能验证的扫描器标签和仅基于版本信息的线索，应予以舍弃。

2. 绘制依赖关系

Finding A
  output: approved user identifier
  enables: object lookup in Finding B

Finding B
  output: unauthorized synthetic object read
  enables: none

如果 A 和 B 只是位于同一位置，应分别记录。

3. 测试转换

转换是攻击链的核心。应证明在相同的授权条件下，一步的确切输出会被下一步接受。

示例：

候选路径	需要证明的转换
Source map 到隐藏 API	提取出的基础 URL 可解析为已测试的 API
用户枚举到 IDOR	枚举出的标识符可访问另一已批准身份的对象
CORS 到受保护数据读取	已批准的浏览器会话向受控来源返回非公开响应
SSRF 到内部服务	受控回调或响应能够识别内部服务
暴露的凭据到仓库访问	受限范围的凭据对已批准的测试资源有效

不要使用真实用户数据、进行大范围凭据测试或执行破坏性操作来弥补缺失的转换。

4. 重新评估复合影响

说明：

1. 每个组件单独能证明什么；
2. 已验证的转换带来了哪些额外能力；
3. 重现了哪些最终影响；
4. 哪些下游后果仍属于推断。

攻击链的严重程度不能超过证据所支持的程度。理论上的最终步骤不会因为前面的步骤奏效而变成已确认。

5. 保留清理记录和限制

记录合成用户、对象、上传内容、回调和临时令牌的移除情况。如果测试在最后一步之前停止，应说明原因并保留最后一个已确认状态。

常见陷阱

• 同时出现不代表存在依赖关系。
• 用户名不是凭据。
• 有效凭据不代表可以访问所有服务。
• 文件上传不代表能够执行代码。
• 可以访问内部网络不代表能够控制内部服务。
• 多个低置信度步骤叠加只会增加不确定性，不会提高置信度。
• 复合测试所需的授权范围可能超出各个单独发现的授权范围。

验证

• 每个组件均通过了其所属技能的验证。
• 每个箭头都有证据表明，前一步的输出能够作为下一步的输入。
• 负向对照能够区分该路径与公开或预期行为。
• 会改变状态的步骤使用合成资源，并包含清理操作。
• 推断所得和未经测试的步骤均有明确标注。
• 最终报告将已证实的影响与可能的后果分开说明。