47 行覆盖矩阵与 38 类漏洞测试:bug-bounty-hunting-prompts Phase 2 全量扫描策略深度解析

发布时间:2026/10/28 22:52:27
47 行覆盖矩阵与 38 类漏洞测试:bug-bounty-hunting-prompts Phase 2 全量扫描策略深度解析

【免费下载链接】bug-bounty-hunting-prompts

Reusable prompts for a structured, evidence-first bug bounty hunting workflow

项目地址:https://gitcode.com/gh_mirrors/bu/bug-bounty-hunting-prompts
点击查看免费下载

Bug Bounty 项目bug-bounty-hunting-prompts提供了一套"证据优先"的漏洞赏金猎捕工作流提示词包,其中 Phase 2(Sweep,全量扫描阶段)是整个流程的核心:它用47 行覆盖矩阵和38 类漏洞类别,让范围内的每个端点都拿到一个可验证的结论。本文深度解析这套全量扫描策略,帮助新手理解如何做到"不漏扫"的 Web 安全测试。

🎯 为什么 Phase 2 是"覆盖优先",而不是"找 Bug 优先"

Phase 2 的设计哲学在提示词文件中写得很直白:这是一个覆盖阶段,不是一个刷 Bug 数量的阶段(phase-02-sweep.md#L27)。

它的目标不是追深度,而是先完成广度:把已测绘的攻击面全部标注"试过什么、哪里死了",让后续的目标周期从一张完整地图上启动,而不是反复试探已经排除的方向。

这里有一个非常反直觉但关键的规则:一个带受控证据的dead(已排除)结论,价值等同于一个confirmed(已确认)结论。没有它,后续轮次会把你已经证伪的方向再测一遍(phase-02-sweep.md#L463)。

📋 47 行覆盖矩阵:每类漏洞一个"账本格子"

Phase 2 是否扫完,不靠自觉声明,而是由机器校验的47 行覆盖矩阵裁决,它由两部分组成:

  • 38 个端点作用域漏洞类:结论绑定到具体端点形状
  • 9 个目标作用域基础设施行:结论绑定到整个目标(phase-02-sweep.md#L441)

38 类漏洞由一份固定的标准测试名称数组定义(phase-02-sweep.md#L225-L234),阶段开始前的检查与结束时的门检查都读同一份数组——"什么算覆盖"只有一份事实来源,不存在模糊空间。

矩阵由辅助脚本coverage_matrix.py从机器可读的资格数据、测试事件和记录渲染成人读清单hunt/phase-02-coverage.md,严禁手工编辑——它由辅助脚本统一覆写(phase-02-sweep.md#L17)。

🧩 38 类漏洞测试:分组与优先级详解

完整矩阵被划分为 6 个组,技术细节外置到各自的技术参考文件中,矩阵本身只回答"测什么、谁来做"(phase-02-sweep.md#L475-L477):

1️⃣ 服务端执行(8 类)

SSRF、SSTI 服务端模板注入、XXE、反序列化、JNDI / Log4Shell、路径遍历 / LFI、开放重定向、文件上传(含服务端处理与上传 UI 两侧)。

2️⃣ 访问控制(9 类)

IDOR 水平越权、双向跨账号重放(IDOR-X)、未授权 API 访问、可预测 ID 遍历、路径规范化绕过、HTTP 方法覆写、API 版本绕过、函数级管理端点访问、GraphQL 授权与内省。

其中api-version是个亮点设计:资格是推导出来的而非靠碰运气发现——对每个携带版本标记的形状,重放/v1…/vN、无版本、Header 与查询参数变体,因为旧版本常在现行版本加管控后仍保留较弱授权(phase-02-sweep.md#L538)。

3️⃣ 认证与会话(7 类)

JWT 混淆分析、会话管理(固定 / 吊销 / 登出)、OAuth / OIDC / SAML、密码重置 / 改邮箱 / 魔法链接、URL 令牌泄漏、SIWE 钱包签名认证、预认证端点绕过。

4️⃣ 业务逻辑(7 类)

数值篡改(价格 / 数量 / 折扣)、批量赋值(role、is_admin)、竞态条件 / 双重支付、幂等性与重放、工作流跳步 / 状态机绕过、HTTP 方法互换、权益与套餐绕过。

5️⃣ 客户端与协议(6 类)

DOM XSS 与 postMessage、CSWSH(WebSocket 源检查)、缓存欺骗 / 投毒、Header 注入(Host / CRLF)、二阶注入(一个面埋点、另一个面引爆)、API 滥用模式。

6️⃣ 被"降级"的一类:系统性注入模糊测试

SQLi、NoSQLi、OS 命令、CSV / 公式注入被整体降为最低优先级,仅做机会性测试。降级依据是真实数据复盘:过去 100 份报告约 107 小时里,产出零个确认漏洞的正是系统性参数模糊测试这一特定活动(phase-02-sweep.md#L581)。

注意降级边界:SSTI、路径遍历、Header 注入并未被降级——它们各自留在正常优先级组里,ImageMagick 驱动的文件读取甚至被确认过 Critical。

🏗️ 9 行目标作用域矩阵

基础设施与暴露面组共 9 行(phase-02-sweep.md#L483-L493):

覆盖行内容
公开管理 / 调试入口未授权可达的 admin、debug 面
暴露的代码与配置source map、.git、.env、备份文件
信息泄露堆栈、内部主机、版本泄漏
DNS 接管子域名接管
云存储开放 Bucket、可写对象
开放后端metrics、actuator、Hasura、Supabase、Swagger
打包密钥JS bundle 与 source map 中的密钥
感知认证的基建认证会话能多看到什么
WebSocket 发现枚举全部 WS 端点

每一行都必须有自己的 angle 文件与终态记录,不允许合并成一个笼统的infra结论——一对一记录让缺失的基础设施覆盖显形而不是被隐藏(phase-02-sweep.md#L508)。

🔀 接入模式路由:RICH、PARTIAL 与 UNAUTH

Phase 2 启动时先读取 Phase 1(phases/phase-01-access.md)留下的访问契约,按实际认证身份数而非模式标签路由(phase-02-sweep.md#L45-L53):

模式控制面通道无状态子代理通道
RICH双身份,跑双向跨账号工作全量
PARTIAL按认证文件推导:两个身份跑双向,一个跑单账号全量,按可用凭证过滤
UNAUTH无账号工作,跑浏览器安全子集全量并按未授权优先级重排

⚠️ 提示词文件特意强调:UNAUTH 是生产模式,不是降级模式——复盘语料中 31 个已提交发现(含 13 个 Critical)来自从未存在账号的项目。未授权模式下的优先级排序直接取自这 31 个发现的实际构成:公开制品中的密钥、未授权服务暴露、公开端点 BOLA、预认证端点绕过、CI 与供应链(phase-02-sweep.md#L954-L960)。

🚀 三阶段并行执行:Stage A、B 与 C

Stage A:控制器通道(有状态工作)

浏览器导航、双身份跨账号重放等需要身份或可变状态的工作,只能由控制器串行执行:身份 A 是干净对照组兼"攻击者",身份 B 是受害者、验证者与破坏性测试身份(phase-02-sweep.md#L589-L591)。两个 profile 支持攻击者/受害者关联,但不授权两个代理并发变更账号。

双向跨账号矩阵的套路是:先各自证明 A 能访问 A、B 能访问 B 作为对照,再把 B 的物体用 A 的身份重放、A 的物体用 B 的身份重放(捕捉非对称租户行为),写操作使用可逆标记并在验证后还原(phase-02-sweep.md#L744-L751)。

Stage B:无状态子代理扇出

不依赖状态、身份的类别(SSRF、LFI、反序列化、信息泄露等)打包成3-4 个独立工作束并行委派给子代理,并发上限严格控制在 3-4(phase-02-sweep.md#L763)。

子代理契约非常清晰:

  • 🚫 绝不触碰控制器的浏览器 profile
  • 🚫 绝不写报告文件(报告编号由控制器集中分配)
  • 🚫 绝不与用户对话、绝不执行破坏性认证检查
  • 每条 lead 只返回一行 JSONL 结论,过程转录不进主上下文

Stage A 尾部:破坏性检查放最后

登出、令牌吊销、改密改邮箱、竞态、幂等爆发、速率验证等高风险操作,必须等所有跨账号与无状态工作全部终态后才开始。双身份通道里 B 此后成为"牺牲品"身份,A 始终保留为干净对照(phase-02-sweep.md#L819-L827)。

Stage C:漏洞组合与规模升级

这是收尾前最后一步,也是"严重度放大器"。对每一对发现追问:A 是否提供了 B 所需的前置条件?(phase-02-sweep.md#L873)

单点组合组合后
存储型内容 + 宽松 CORS 读取账号接管(ATO)
SSRF + 开放重定向云元数据 / 内网服务触达
信息泄露(ID 列表)+ IDOR批量数据提取
认证绕过 + IDOR未授权批量 PII
逻辑缺陷 + 无速率限制同一缺陷规模化(通常就是严重度跳升点)

语料库中最严重的发现都是组合而非单类。之后还要做"规模路径":对每个已确认的 Medium 追问"什么让它变 High"——能否重复、能否触达其他租户、是否涉及资金或批量 PII。

🚪 停止条件:完整扫描的 8 道硬门

Phase 2 的完成标准不是 Bug 数,而是 8 道必须同时满足的机器校验门(phase-02-sweep.md#L1008-L1020):

  1. coverage_matrix validate通过,47 行全部终态
  2. 每个类别的剩余清单为空
  3. 每个 Medium 及以上已确认发现都有报告文件
  4. 每个尝试过的角度都有 angle 文件与终态 Status
  5. 线索台账中无遗留queued/dispatched
  6. Stage C 已运行:每个确认发现都做过组合与规模检查
  7. 身份通道与破坏性尾部记录合法有效
  8. 导入的移动端假设全部验证通过

⏱️时间预算:目标约 90-120 分钟连续工作。通配符域下有几百个形状时,你一次扫不完——文件明确鼓励按矩阵顺序工作并如实记录没扫到哪:"诚实的 partial 地图,胜过粉饰的假完整"(phase-02-sweep.md#L1022)。

📦 如何把它适配到自己的流程

这套提示词刻意写成可移植占位符,落地前需要四步(ADAPTATION.md#L9-L19):

  1. 替换{{target}}、{{scope}}等模板字段,范围以项目简报为准
  2. 为$YOUR_WORKSPACE_ROOT、$YOUR_HELPERS_ROOT等变量提供你自己的等价物,不需要的依赖块可直接删除
  3. 把浏览器控制、流量捕获、OOB 回调等能力替换为自己可审计的实现
  4. 只针对已授权、在范围内的资产运行;使用有界、非破坏性的证明

整条流水线中,Phase 0(侦察面映射,phases/phase-00-recon.md)与 Phase 1(账号与认证,phases/phase-01-access.md)为 Phase 2 提供输入,扫描结束后由 Phase 3(phases/phase-03-closeout.md)校验交接并释放资源。完整阶段序列见 README.md#L33-L52。

✅ 小结:全量扫描策略的三个核心

  • 矩阵先行:47 行覆盖矩阵 + 机器校验,让"扫完"可验证、不可自我声明
  • 分类分派:38 类漏洞各配资格文件与终态结论,dead与confirmed同样值钱
  • 组合收尾:Stage C 把分散的 Medium 连成 High 与 Critical——没有任何下游阶段会替你补这一步

如果你正在搭建自己的结构化漏洞猎捕系统,可以从这份提示词包的 Phase 2 起步:先把"覆盖"做成可度量的硬指标,再谈"找得深"。

【免费下载链接】bug-bounty-hunting-prompts

Reusable prompts for a structured, evidence-first bug bounty hunting workflow

项目地址:https://gitcode.com/gh_mirrors/bu/bug-bounty-hunting-prompts
点击查看免费下载

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考