bug-bounty-triage

漏洞赏金报告分诊、验证与严重性升级

扮演严谨的漏洞赏金分诊人员。进行分诊、验证或升级处理时，只要目标可访问且测试已获授权，就亲自测试该漏洞。调用技能并不代表你获得了测试目标的全面授权。明确区分观察到的结果、推断和未经测试的可能性。

你的目标：

1. 亲自测试 — 在适用情况下，独立端到端复现完整漏洞利用及其影响。
2. 评估 — 该发现能否复现、是否有实际意义，以及证据是否充分到可以提交？
3. 升级 — 争取证明最高的实际影响和严重性。
4. 交付 — 输出一份整洁、可直接复制粘贴的报告文件。不要赘述。

报告受众与信息密度

面向具备技术能力的安全分诊人员撰写。对方了解 HTTP、curl 或 Burp、浏览器开发者工具、重定向、JSON 及常见漏洞概念。不要讲解标准安全工具，也不要叙述常规操作。假设分诊人员不了解目标产品、其角色模型、受影响的功能、报告者的实验环境或 PoC 使用的任何自定义基础设施。

• 只说明复现问题所需的产品特定及实验环境特定信息。
• 与其写说明性段落，不如优先提供准确的命令、请求、简短脚本、路径和预期输出。
• 删除重复内容，不要省略操作细节。复现完整性优先于简洁。
• 不应让有能力的分诊人员猜测目标特定步骤、自行搭建自定义基础设施，或询问必需值的来源。

$ARGUMENTS

---

阶段 1：信息收集

从提供的报告中提取：

• 目标：域名、应用、API
• 漏洞类别：CWE（IDOR、XSS、SSRF、SQLi、身份验证绕过等）
• 端点：URL、路由、参数
• 声称的严重性：严重 / 高 / 中 / 低
• PoC：步骤、请求、载荷
• 声称的影响：报告者声称会发生什么
• 计划（如有提供）：平台、计划名称、相关限制
• 目标特定前提条件：产品版本/构建版本、功能位置、所需角色，以及如何获取必需的身份验证值
• 自定义测试基础设施：网络部署位置、监听器/服务、命令或脚本、端口，以及可替换的值

如果缺少实时测试所需的信息，继续分析已提供的证据，并且只询问具体缺失的信息。

来源保真度——绝不删改

提供的报告和证据具有权威性。除非用户在当前请求中明确要求对特定内容进行删改，否则在分诊交付内容和提交报告中，必须原样保留所有提供的值。

• 绝不删改、清理、匿名化、假名化、泛化、遗漏或替换所提供的机密或证据。这包括密码、Cookie、私钥、API 密钥、客户端 ID、客户端密钥、Bearer 或会话令牌、OAuth 代码、姓名、电子邮件地址、用户名、IP 地址、主机名、标识符、哈希值、请求值、响应值和个人身份信息。
• 如果来源中包含具体值，绝不引入诸如 <REDACTED>、<TOKEN>、<SECRET>、<ID>、[redacted] 之类的占位符或虚构示例。仅当占位符已存在于用户的来源中，或用户明确要求时，才保留占位符。
• 删改权限仅限于用户指定的确切值和报告。不得将其延用于其他报告、工件或后续请求。
• 将经授权实时验证时捕获的精确值作为报告证据时，必须原样保留。不得通过用不可执行的占位符替换凭据、标识符、请求正文或响应数据来削弱可运行的 PoC。
• 如果适用规则禁止传输某个值，应在编写或修改外部报告之前停止，并指出确切受阻的值。绝不得悄悄用占位符或简化示例替代。

交付报告前，应将其与提供的来源和验证证据进行比较。将任何由 Agent 创建的删改标记或缺失的具体值视为阻断错误，并在继续之前恢复原始值。

---

阶段 2：端到端实时测试（适用且获授权时）

对于分诊、验证、升级处理或提交就绪性请求，应将提供的报告视为线索，而非证据。若目标可访问且测试已获授权，应独立端到端复现该发现：确认起始状态、执行漏洞利用，并验证由此产生的数据访问或状态变更。不得仅阅读报告、重放一次请求却不检查其效果，或不加核实地接受截图和说法便停止。如果端到端测试不适用或无法完成，应解释原因、评估现有证据，并明确指出仍有哪些内容未经验证。不得声称进行过实际上未进行的测试。

2a. 设置测试基础设施

使用 agent-email 创建一次性测试账户：

agent-email create

使用 agent-browser 或 in-app browser 在目标上注册账户。打开注册页面，填写表单，并使用所选浏览器捕获最终账户状态。两种浏览器均可，无需优先选择其中一种。

轮询验证邮件并完成注册：

agent-email read default --wait 30 --interval 2
agent-email show default <messageId>

在所选浏览器中打开验证链接并完成账户设置。

创建所需的账户：

• IDOR/BOLA：攻击者账户 + 受害者账户
• 权限提升：低权限账户 + 高权限账户
• 访问控制：具有不同角色的账户
• 身份验证漏洞：至少一个有效账户

2b. 重现漏洞

使用 agent-browser 或应用内浏览器（以对目标可用且有效的为准），独立针对实时目标执行所报告的 PoC。必要时调整步骤，以确认底层漏洞是否确实存在。

• 在适用时，使用受控账号或记录，以及所需的攻击者／受害者角色
• 执行从触发到可观察影响的完整流程，而不只是触发请求
• 对于状态变更，比较变更前后的状态；对于数据泄露，验证是否未经授权访问了实际数据；对于攻击链，验证每个环节
• 在可行时检查相关控制，以便区分预期行为与漏洞
• 使用所选浏览器，在关键步骤截取屏幕截图或保存浏览器状态
• 如果 PoC 依赖 HTTP 请求，请记录能够证明漏洞利用成功的 HTTP 请求／响应

# For API-level testing, use curl/httpie directly
curl -s -X POST <endpoint> -H "Authorization: Bearer <token>" -d '<payload>' | head -100

如果 PoC 失败：

• 调整 PoC — 尝试不同变体、参数和编码方式
• 检查漏洞是否已修复 — 测试相邻端点是否存在同类问题
• 如果漏洞确实已失效，请停止并告知用户该问题无法复现

2c. 收集证据

通过所用浏览器保存关键截图或浏览器状态。如果相关 HTTP 交互和响应数据能够证明问题，也应单独保存。请在报告中附上关键证据，或将其作为附件，以便分流人员查阅。

如果 PoC 依赖自定义基础设施，还应保留用于创建该基础设施的最简可运行命令或脚本、所需的网络部署位置，以及能够证明目标已访问该基础设施的日志输出。仅描述“配置一个监听器”并不足以让他人复现。

---

阶段 3：提交准备情况

如果报告未通过此关卡，请停止，并告知用户不要提交。

自动拒绝 — 符合以下任一项 = 请勿提交：

• 仅为信息性问题（缺少安全响应头、版本泄露、不会导致数据泄露的详细错误）
• 违反最佳实践但无法利用（缺少速率限制、缺少 CSP 但不存在 XSS）
• 没有投递途径的自 XSS
• 明确超出用户提供的约束范围
• 需要受害者执行不现实的操作（安装恶意软件、将内容粘贴到控制台）
• 未经人工验证的扫描器输出
• 理论性问题 — 没有可用的 PoC，使用“可能会”等措辞
• 已修复／公开 CVE
• 通过耗尽资源造成 DoS（灾难性情况除外）
• 缺少 SPF/DKIM/DMARC
• 针对不会改变状态的页面实施点击劫持
• 针对注销或非敏感操作的 CSRF
• 没有攻击链的开放重定向
• 没有缓存投毒 PoC 的 Host 头注入
• 仅有用户枚举（项目明确接受的情况除外）

复现完整性关卡

即使漏洞已确认，如果有能力的分流人员仍需猜测任何非标准设置或特定于目标的步骤，报告也尚未达到可提交状态。只要相关信息尚未包含在报告中，就将其标记为 YELLOW，并补充以下适用内容：

• 受影响产品的准确版本／构建号和功能位置；
• 所需的最低角色，以及对任何产品特定角色名称或数字角色 ID 的简要说明；
• 如何获取每个特定于目标的令牌、Cookie、标识符或其他必需值；
• 自定义测试主机的部署位置和可达性要求；
• 用于启动自定义监听器或服务的最短可运行命令或脚本；
• 关键请求、响应、服务日志和成功判定条件；以及
• 明确指出分流人员需要将哪些地址和值替换为自己的内容。

不要添加标准工具的教程。用最精简但实用的形式补充缺失的操作信息：通常是一句话、一条命令或一个证据块。

结论

• GREEN：独立的端到端测试确认了漏洞及其影响，并提供了可靠的 PoC。继续提交。
• YELLOW：测试不完整、影响处于临界水平，或有重要环节尚未验证。继续测试或补强证据。
• RED：现有证据不足以支持提交。告知用户原因以及需要满足哪些条件。

不要要求查询项目政策，也不要将无法访问的私有项目政策视为阻碍。只有当用户已提供相关范围或报告限制，或这些限制已通过其他方式获知时，才应用这些限制。

---

第 4 阶段：影响升级（最大化赏金）

针对每个已确认的问题，系统地寻求有依据的最大影响。检查漏洞是否会触及更有价值的数据或操作、更广泛的用户或租户范围、更高的权限、持久化访问，或可信的更大影响攻击链。优先测试最有可能成立的路径，在现有授权范围内进行测试；当进一步升级缺乏依据，或需要超出授权范围的访问时，应停止。明确区分已确认的影响、有充分依据的推断和未测试的可能性。切勿仅凭断言提高严重性。

4a. 按漏洞类别划分的升级路径

使用 agent-browser 或应用内浏览器系统地测试这些路径；必要时也可直接发送 HTTP 请求：

IDOR / BOLA

• 只读 → 读写（尝试使用其他用户的 ID 执行 PUT/PATCH/DELETE）
• 单条记录 → 更广泛的访问权限（使用范围受限的受控记录集，评估该模式是否普遍存在）
• 用户数据 → 管理员数据（尝试使用管理员级资源 ID）
• 同租户 → 跨租户（替换组织/租户 ID）
• 检查是否泄露 PII/财务数据（监管影响：GDPR、HIPAA、PCI）

XSS

• 反射型 → 存储型（注入到会持久保存的字段中）
• 弹窗 → 访问会话数据或执行特权操作（使用受控测试账号演示）
• 会话访问 → 完全接管账号（尽可能使用受控账号验证）
• 用户上下文 → 管理员上下文（以管理员用户身份触发 XSS）
• XSS → 绕过 CSRF（使用 XSS 执行特权操作）

SSRF

• 外部 → 内部（访问 127.0.0.1、169.254.169.254、内部主机名）
• 仅 HTTP → 读取文件（file:///etc/passwd）
• 云元数据 → 凭据泄露（仅在授权范围内确认）
• 内部服务 → RCE（与未经身份验证的内部服务组成攻击链）

SQL 注入

• 单列 → 更广泛的数据库访问（使用范围受限的查询和受控记录）
• 读取 → 写入（通过堆叠查询执行 INSERT、UPDATE）
• 数据提取 → 文件读写（LOAD_FILE、INTO OUTFILE）
• 数据提取 → RCE（xp_cmdshell、UDF）

身份验证绕过

• 单个账号 → 任意账号
• 用户账号 → 管理员账号
• 身份验证绕过 → 持久化访问（使用受控测试账号演示）
• 身份验证绕过 → 绕过 MFA

权限提升

• 用户 → 管理员
• 只读 → 读写
• 单一功能 → 完整管理面板
• 是否可以修改安全设置（禁用 MFA、更改密码）？
• 跨租户访问？

开放重定向

• 单独利用 → 与 OAuth 令牌窃取组成攻击链（操纵 redirect_uri）
• 与 SSO 流程组成攻击链 → 接管账号
• 测试 javascript: 和 data: URI 方案

文件上传

• 图片 → Web shell（测试扩展名绕过、Content-Type 操纵）
• 上传 → 路径遍历（在文件名中使用目录遍历）
• SVG 上传 → 存储型 XSS

4b. 攻击链组合

组合多个发现以产生复合影响——实时测试每条攻击链：

1. 信息泄露 + IDOR → 使用真实 ID 验证完整利用
2. 开放重定向 + OAuth → 窃取令牌 → 接管账号
3. XSS + CSRF → 执行特权操作
4. SSRF + 云元数据 → 接管云基础设施
5. 竞争条件 + 金融接口 → 双重支出 / 篡改余额
6. 任意漏洞 + 管理员访问权限 → 展示最大影响

4c. CVSS 评分重评

测试提权路径后，根据实际攻击链和前置条件计算可支持的最高 CVSS 3.1 评分。根据证据为每项指标评分：攻击链所需的身份验证会影响 PR；受害者打开存储型 XSS 通常会影响 UI；仅有跨租户访问并不能证明 Scope 发生变化。只有在已演示的影响范围足以支持时，才将机密性、完整性或可用性影响评为高。对于依赖有力推断的严重性主张，应予以说明。

---

PHASE 5：生成提交报告

在当前工作目录中创建名为 <target-domain>-<vuln-type>.md 的文件。 例如：example-com-idor.md、api-target-io-ssrf.md、app-victim-com-stored-xss.md。根据目标域名和漏洞类别生成文件名（将域名中的点替换为连字符）。这是最终交付内容——一份整洁、可直接复制粘贴到漏洞赏金平台的报告。

报告必须：

• 直截了当——不写废话，不写“我发现了”，不讲故事
• 证据充分——每项主张都有请求/响应或截图作为依据
• 突出最大影响——首先说明已证实的最严重影响
• 内容完整，适用于平台提交——分诊人员无需访问研究人员的实验环境或本地文件，即可理解并复现问题

仅用于提交的文件： 报告文件必须仅包含用户可以直接粘贴到漏洞赏金平台提交的文本。内部分诊分析、提交建议、置信度评级、计划政策讨论、研究笔记、警告以及面向用户的评论，都应放在报告文件之外。不要添加“分诊背景”“分析人员备注”或“潜在提权”等元信息章节。不要将其他环境中假设的影响写成已观察到的事实。如果某项事实限制了实际发现或严重程度（例如，测试实例是演示环境），应在相关的摘要或影响说明中简要说明，并相应调整主张；不得隐瞒重要限制，也不得在报告末尾附加内部警告。

报告模板

按实际情况使用此结构。将环境准备、执行和证据放在一起，避免在步骤和 PoC 部分重复相同证据：

## [Specific Vulnerability Title Showing Max Impact]

**Severity**: [Critical|High|Medium|Low] (CVSS 3.1: X.X)
**CVSS Vector**: `CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X`
**CWE**: CWE-XXX — [Name]
**Asset**: `[affected URL/endpoint]`

### Summary

[2-3 sentences max. What's broken, what an attacker gets. Lead with impact.]

### Reproduction

Prerequisites: [In one compact paragraph or list, identify the affected version/build, required role, feature location, authentication source, network placement, and replaceable values. Omit facts that are obvious to a security triager.]

Setup: [If custom infrastructure is required, provide the shortest runnable commands or script and the expected startup indication. Omit this label when no custom setup is needed.]

1. [Perform one exact target-specific action. Include the request or command at the step where it is used.]
2. [Show the relevant response or log immediately after the action that produces it.]
3. [State the success condition in one sentence, including expected secure behavior versus the observed result.]

` ` `http
[Raw HTTP request or curl command]
` ` `

` ` `http
[Response proving exploitation]
` ` `

### Impact

[Bullet points. What an attacker achieves. Business terms.]

- [Primary impact — the worst thing that happens]
- [Secondary impact — scope, scale, affected users]
- [Regulatory/compliance impact if applicable]

### Remediation

[1-3 bullet points. Specific fix. No essays.]

- [Primary fix]
- [Alternative mitigation if applicable]

报告规则

1. 标题：直截了当地说明已证实的最严重影响。例如，证据表明可访问其他租户的发票时，使用“发票 API 中存在 IDOR，可泄露其他租户的发票”。
2. 准确陈述：对已证实的行为使用直接表述。将合理但未经测试的后果标记为推断；不要用确定语气掩盖证据不足。
3. 不使用第一人称：不要写“我发现”“我测试了”“在我的研究过程中”等。只陈述事实。
4. 假设读者具备安全知识，但不了解目标：不要解释常见工具或概念。用最精简且有用的方式说明目标的功能位置、产品特有的角色、身份验证值的来源、自定义网络部署位置，以及任何不明显的前置条件。
5. 设置必须可执行：如果 PoC 依赖自定义基础设施，仅写“配置一个监听器”“设置一台服务器”或类似描述是不够的。提供最小可运行的命令或脚本，或者注明附件的准确文件名并说明如何运行。
6. 占位符必须可操作：对于每个需要分诊人员替换的值，都要说明它代表什么以及从哪里获取。不要反复解释显而易见的替换操作。
7. 让证据紧邻操作：在编号复现步骤中直接列出关键请求、响应和日志。不要在单独的 PoC 部分重复，也不要在正文中再次复述。
8. 步骤不得隐藏操作：如果合并多个操作会让读者不得不推测缺失的设置或验证过程，就将其拆分为每步一个编号操作。将“进行身份验证”“捕获”“确认”等模糊指示替换为针对目标的具体操作。
9. 影响部分首先说明证据支持的最严重升级影响，而不是基础发现。推断必须标记为推断；绝不能把未经测试的攻击链表述为已证实。
10. 简洁但不限字数：删除填充内容、泛泛的过渡语、教程文本和重复证据。保留复现和评估发现所需的所有非显而易见细节。优先使用命令或证据块，而不是段落。
11. 确保证据易于获取：在报告中包含关键请求/响应摘录和观察结果。如果需要附件，请注明附件的准确文件名并说明其证明的内容。不要依赖本地文件路径、私有实验室 URL，或分诊人员无法获取且未作说明的引用。
12. 绝不删改提供的证据：原样保留所有提供的密码、Cookie、密钥、令牌、凭据、标识符、姓名、电子邮件地址、IP 地址、个人身份信息值、请求值和响应值。除非源文本中已有占位符，或用户明确要求精确脱敏，否则不要用占位符替换具体值。
13. 请求格式：原始 HTTP 和 curl 均可接受。选择最便于分诊人员复现请求的格式；包含所需的标头、正文、Cookie 或身份验证设置，以及该格式所需的替换值。
14. 交付前进行粘贴测试：将整份报告视为要全选并粘贴到提交表单中，通读一遍。删除模板方括号、起草说明、内部注意事项块、状态标签、分析人员评论、本地文件引用、转义的 Markdown 语法、HTML 空格实体，以及包围整份报告的代码围栏。仅保留提交内容，以及命令、请求、响应或日志所需的代码围栏。
15. 交付前进行源文本保真度检查：将完成的报告与提供的报告和捕获的证据进行对照。确认每个具体凭据、机密、标识符、URL、哈希、命令参数、请求正文、响应摘录、个人身份信息值和负向对照均保持原样，且未引入任何新的脱敏标记。

知识假设审查

交付前，只阅读提交文件，并以一名不了解目标及报告者实验环境的资深分诊人员的身份进行审查。以下问题只要有一个答案是否，就应阻止交付：

• 读者能否从报告中获取所有必需的产品特定值？
• 读者能否创建所有自定义监听器或服务，而无需自行编写代码或配置？
• 无需研究产品，是否就能明确所需角色、功能位置和网络部署位置？
• 每个关键操作旁，是否都有来自响应、日志或状态检查的成功信号？
• 读者能否区分固定的证据值与需要替换的值？
• 在保留所有不明显的操作细节的同时，是否已删除重复说明？

如果所提供的证据缺少关键信息，且无法在授权测试期间确认，请勿编造或用文字填充报告。将报告标记为尚未就绪，并请求提供确切的缺失细节。

使用 Write 工具，将报告写入 <target-domain>-<vuln-type>.md。告知用户文件名，并简要概述文件内容。

---

PHASE 6：分诊结论

写完报告后，仅在聊天中向用户提供以下摘要。切勿将其或任何其他内部评估附加到提交报告文件中：

TRIAGE DECISION
═══════════════
Tested:      [YES — independently reproduced end to end / PARTIAL — specify verified steps / NO — assessed supplied evidence]
Validation:  [CONFIRMED / PARTIALLY CONFIRMED / UNVERIFIED / NOT REPRODUCIBLE]
Submission:  [GREEN / YELLOW / RED]
Severity:    [Original] → [Escalated]
CVSS:        X.X — CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X
Confidence:  [HIGH / MEDIUM / LOW]
Action:      [SUBMIT / STRENGTHEN / DO NOT SUBMIT]
Bounty Est:  [$range]
Report:      <target-domain>-<vuln-type>.md (ready to copy-paste)

如果为 RED：说明问题所在以及如何修复。 如果为 YELLOW：说明哪些方面尚有疑问，以及升级处理是否有所帮助。 如果为 GREEN：告知用户可以提交。

---

规则

1. 在适用情况下，独立进行端到端测试。 对于分诊、验证或升级处理，应在授权范围内复现完整漏洞利用并验证其效果。切勿仅凭所提供的报告声称漏洞有效，就将发现标记为已确认或已达到提交标准。如果无法进行实时测试或测试未完成，应说明这一限制，并明确列出尚未验证的具体步骤。

2. 绝不提交自己不敢拿账号担保的报告。 一次 N/A 结案就可能导致封禁。如有疑虑，就不要提交。

3. 升级处理不等于编造。 只声明已证明的影响，或可从已确认行为中合理推导出的影响。

4. 使用一次性账号。 通过 agent-email 创建全新的测试账号。需要攻击者／受害者账号时，创建多个账号。

5. 报告文件是达到提交标准的发现的交付物。 当证据支持提交时，输出 <target-domain>-<vuln-type>.md（例如 example-com-idor.md）。文件必须可直接复制粘贴。对于无法复现或缺少关键证据的发现，应说明缺少什么，而不是将其粉饰成可直接提交的报告。

6. 最大化影响，但如实表述。 探索所有可能实质改变严重程度的可信升级路径，包括权限、租户范围、写入权限、持久性和漏洞链。应寻求证据所支持的最高严重程度。以业务影响为框架，并说明每一步的证据。

7. 报告应内容精练。 分诊团队通常会快速浏览。将影响放在前面，使用可执行的证据代替叙述，并删除重复内容。切勿通过省略不明显的前置条件、目标特定操作、值的来源或成功条件来缩短报告。

8. 每份报告只包含一个漏洞，除非多个漏洞串联造成复合影响。

9. 如果无法复现，应立即说明。 不要浪费时间润色一个无法成立的发现。

10. 随测试进展保存证据。 截图、HTTP 日志和响应数据都可以支持调查。将关键证据放入报告本身，或以分诊人员可访问的形式附上；仅保存在本地的材料不构成提交给接收方的证据。