bugcrowd-reporting

BUGCROWD 报告——项目专属策略

通用 report-writing 技能的配套内容。专门处理 Bugcrowd 提交时，如果需要考虑 VRT 映射、对 OOS 条款提出异议，或按项目选择目标，请使用此技能。

此技能总结了专用于 Bugcrowd 提交流程的模式。通用的平台专属模板（HackerOne / Bugcrowd / Intigriti / Immunefi 报告正文）请使用 report-writing 技能。决定是否提交报告之前的 7-Question Gate，请使用 triage-validation。

---

1. VRT 类别选择——搜索与回退策略

Bugcrowd 的提交表单要求选择一个 VRT（Vulnerability Rating Taxonomy，漏洞评级分类法）类别。下拉菜单的默认严重性与所选节点绑定——如果选错，表单可能会自动建议较低的优先级（通常为 P4），而实际影响可能是 P3 或 P2。

注意：VRT 默认严重性并非固定值。Bugcrowd 会在不同版本中修订 VRT 架构，单个项目也可以通过自身的优先级配置重新映射默认值。以下示例中的 P 值（例如，“表单登录未实施速率限制”默认显示为 P4）是撰写本文时的典型基准值——请务必查看当前表单针对该项目实际自动建议的严重性，不要直接套用此处的值。

1.1 搜索层级（按顺序尝试，选择仍能描述该漏洞的最高严重性匹配项）

对于任何发现，请按以下顺序使用这些词语搜索 VRT 下拉菜单：

1. 漏洞的主要类别——例如，IDOR、XSS、SSRF、auth bypass、2FA bypass
2. 暴露的数据类别——例如，PII、sensitive data exposure、disclosure of secrets
3. 被绕过的控制措施——例如，broken access control、authentication bypass
4. 端点类型——例如，no rate limiting on form > login、no rate limiting on form > change password
5. 通用父级节点——例如，Server Security Misconfiguration > Other、Broken Access Control > Other

1.2 选择仍能准确描述漏洞的最高严重性匹配项

切勿为了获得更高的默认严重性而选择错误描述漏洞的 VRT。分诊人员会重新分配类别，也可能指出该描述不实。应遵循以下原则：选择最具体且准确的 VRT；如果默认值不合适，再使用 §2（手动覆盖严重性）。

1.3 值得了解的常见映射

发现类型	首选 VRT	回退选项
更改密码时因缺少 2FA 导致 ATO	Broken Authentication & Session Management → Second Factor Authentication (2FA/MFA) → Bypass	Broken Auth → Authentication Bypass → Other
无速率限制的密码 oracle	Broken Authentication & Session Management → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Form → Login
GraphQL 内省 / APQ 允许列表绕过	Server Security Misconfiguration → Other（在正文中说明理由）	Broken Access Control → Other
通过用户名枚举真实姓名 PII	Sensitive Data Exposure → PII Leakage / Disclosure of Secrets → Non-Corporate User	Broken Access Control → Other
安全敏感操作中的状态失同步	Application-Level DoS → Other（采用状态失同步的表述）	Server Security Misconfiguration → Other
在身份验证流程端点上进行电子邮件 / SMS 攻击	Server Security Misconfiguration → No Rate Limiting on Form → Email-Triggering / SMS-Triggering	Server Security Misconfiguration → No Rate Limiting on Action
令牌暴力破解（电子邮件更改 OTP、密码重置）	Broken Authentication → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Action

1.4 如果没有合适的 VRT

选择 Server Security Misconfiguration → Other 或 Broken Access Control → Other，并在描述正文开头加入“VRT 映射说明”，解释为何所选节点是最接近的可用选项，以及漏洞的实际类型。

---

2. 手动覆盖严重性

Bugcrowd 的表单允许你手动设置技术严重性，且该设置独立于 VRT 默认值。表单本身注明："VRT 建议的严重性评级不保证就是应用于你提交内容的严重性评级。"

2.1 何时覆盖

在以下情况下覆盖 VRT 默认值：

• 链式攻击造成的后果比单独漏洞类别更严重（链式攻击 → ATO）
• VRT 类别只是近似匹配，其默认值无法反映实际影响类别
• 项目自身的重点领域明确将此类后果列为比 VRT 默认值更高的严重性
• 暴露的数据类别比 VRT 示例中使用的数据更敏感（例如，真实姓名 PII，而非用户名枚举）

2.2 如何覆盖（表单操作）

1. 选择最准确描述该漏洞的 VRT（参见 §1）
2. 记下自动建议的严重性（P4、P3 等）
3. 在 Technical Severity 字段中手动选择你申请的严重性
4. 在描述正文的首个部分添加一段 Severity Request（参见 §3）

2.3 不要夸大影响

夸大为 P1 是最快失去分流人员信任的方式。仅在无需交互即可接管账户（ATO）、远程代码执行（RCE）、大规模 PII 外泄、资金盗窃及类似严重影响时，才使用 P1。如果达到 P1 的攻击链需要额外假设攻击者已窃取 Cookie，应将独立漏洞原语按 P3 提交，并通过交叉引用明确讨论该攻击链（参见 §4）。

---

3. 严重性申请段落——始终放在正文开头

当 VRT 默认值低估影响时，描述正文的首个部分应是一段严重性申请。这是分流人员首先读到的内容，也能避免他们在表单中看到“P4”后直接自动关闭报告。

3.1 模板

## Severity request — please review carefully before applying VRT default

The closest VRT category for this finding is "[chosen VRT]," which Bugcrowd defaults to **P[N] ($X-$Y in [program]'s rubric)**. **I am requesting evaluation at P[M] [standalone | in chain with submission XXXX]** for the following reasons:

1. **[Impact axis 1]** — [specific reason this finding exceeds the VRT default's example]
2. **[Impact axis 2]** — [specific reason, often citing the program's own Focus Areas]
3. **[Impact axis 3]** — [specific reason, often comparing to historical bounty payouts for the same data class]

[Optional: one paragraph contrasting the VRT default's typical example with this finding's actual impact, e.g., "P4 = No Rate Limiting on Login Form" applies to ordinary login pages where brute force is bounded by lockout policies; this endpoint has neither lockout nor throttle.]

3.2 示例模式

## Severity request — please review carefully before applying VRT default

The closest VRT category for this finding is "No Rate Limiting on Form → Login," which Bugcrowd defaults to **P4 ($XX–$YY in this program's rubric)**. **I am requesting evaluation at P3 standalone, P2 in chain with submission XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX** for the following reasons:

1. **[Endpoint] is a password-disclosure oracle, not a generic rate-limit gap.** The endpoint returns true/false for a supplied password — combined with cookie theft, it is the exact primitive an attacker uses to learn the victim's *durable* credential from a stolen *transient* session.
2. **The chained outcome is "Account Takeover,"** explicitly listed under the program → Focus Areas → Critical (P1) examples. This finding is one of two independent links that make that chain work; the other is submission XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
3. **The two findings have independent fix surfaces.** Per the program's "one fix = one bounty" rule they should be evaluated as two separate findings whose chain raises the joint severity.

The "P4 = No Rate Limiting on Login Form" default applies to ordinary login pages where brute-force is bounded by lockout policies. This endpoint has neither lockout nor throttle, and the result of brute force is the *user's actual password* (not a session) — making the impact significantly higher than the default VRT severity assumes.

3.3 语气指南

• 以 "Severity request — please review carefully before applying VRT default"（字面原文）开头。分流人员认识这句话，不会自动关闭报告。
• 谨慎使用 粗体；每条理由最多使用一两处。
• 切勿使用“可能有潜在的”或“或许允许”——这些措辞容易导致降级。
• 按准确名称引用项目自身的重点领域／已接受影响列表。
• 通过完整的提交 ID（UUID 格式）交叉引用关联的提交。

---

4. 对范围外条款的反驳——模板

Bugcrowd 分流人员有时会将发现归入范围外（OOS）条款，在未阅读报告的情况下自动关闭。为避免这种情况，请加入一个 In-scope justification 部分，引用相关的范围外条款，并解释为何你的发现不符合该条款。

4.1 对“非身份验证端点上的速率限制”的反驳

当发现涉及身份验证端点（登录、密码更改、密码验证、OTP 验证、令牌验证）时：

## In-scope justification

The program OOS list excludes "Rate limiting or brute-force issues on **non-authentication** endpoints." `[endpoint name]` is the canonical authentication endpoint — it accepts a password/token/OTP and returns whether it matches the user's stored credential. By definition this is an authentication primitive. The OOS clause's "non-authentication" qualifier therefore does NOT apply.

4.2 对“调试信息泄露”的反驳（适用于架构／内省相关发现）

当发现涉及的架构泄露实际上绕过了控制（例如，GraphQL 允许列表绕过导致变更操作面暴露）时：

## In-scope justification

This is not a "debug information" finding. The [persisted-query allowlist | introspection gate | etc.] is acting as an authorization control on the [GraphQL surface | API tree | etc.]. The bypass converts that gate into a no-op — multiple [mutations | endpoints] become reachable that the official clients cannot invoke. The schema disclosure is incidental; the impact is **mutation-surface unlock**, not information leakage.

4.3 对“低风险信息的用户枚举”的反驳

当泄露的信息不止是“该用户名／邮箱是否存在”时：

## In-scope justification

The program OOS list excludes "User Enumeration issues with **low-risk and insignificant** information being enumerated." The data leaked here is **neither low-risk nor insignificant**: it includes the matched user's [full real first name, last name, profile photo / SSN last 4 / phone number / etc.]. Real-[name | identity | etc.] knowledge is the same data class that gates the program's own [account-recovery flows / fraud-investigation interviews / support-call verification], which means this lookup directly defeats one of the program's own anti-fraud controls. This is PII disclosure, not handle enumeration.

4.4 对“理论问题／无法利用”的反驳

当漏洞的可利用性已通过端到端方式演示时：

## In-scope justification

This finding is exploitable end-to-end as demonstrated in the PoC: [one-sentence summary of the proven exploitation path]. The PoC includes [N HTTP requests with redacted cookies | N screenshots | a sanitized HAR file | etc.] showing the attacker's session [reading victim data | changing victim credentials | etc.]. The OOS clause for "theoretical issues that are not exploitable, or can not be demonstrated as exploitable" does not apply.

4.5 如果没有端到端证据

如果你只有“API 行为”观察结果，却未能完整演示利用路径，那么该发现仍属理论问题。不要提交。收集缺失的证据（送达确认、令牌格式检查、响应中包含的跨账户受害者数据等），然后重新评估。提交理论性发现会损害你在平台上的研究员声誉。

5. 漏洞链 — 交叉引用策略

许多影响重大的发现都是由两个或更多独立基础漏洞组成的链（预言机 + 缺少增强验证 = 账户接管）。Bugcrowd 的项目规则是：“每份报告提交一个漏洞。如果必须将多个漏洞串联起来才能证明影响，可以将它们一并提交，但请清楚说明漏洞链。”

5.1 漏洞链的提交策略

1. 确定漏洞链中严重性最高的结果（通常对应项目“重点领域”中的 P1/P2 示例）。
2. 先将漏洞链中的基础漏洞分别提交，作为单独报告——每个报告按其独立严重性评级（通常为 P3/P4）。提交内容的 UUID 只有在提交后才会生成，因此基础漏洞必须先存在，后续才能引用。暂时在每个基础漏洞的正文中保留交叉引用占位行。
3. 提交漏洞链的汇总报告——正文描述完整的账户接管／远程代码执行等影响，并按漏洞链严重性评级（例如 P1）。由于基础漏洞报告已经存在，请在汇总报告的“漏洞链相关报告”区块中填写其真实 UUID（参见 §5.2）。
4. 在提交汇总报告后编辑每个基础漏洞报告，补填汇总报告的 UUID：“漏洞链相关报告：提交内容 [UUID]，详述完整影响。”（引用是双向的，因此必须在另一份报告提交后编辑一份报告——Bugcrowd 允许提交后编辑描述正文。）

5.2 交叉引用模板

在漏洞链汇总报告正文靠前的位置：

## Chain partners (filed as separate reports)

- **submission [UUID-1]** — [primitive 1: e.g., `me.verify_password` no rate limit]
- **submission [UUID-2]** — [primitive 2: e.g., GraphQL APQ allowlist bypass]

These primitives have independent fix surfaces and are filed separately per the program's "one fix = one bounty" rule. The chained impact described here requires both primitives to be exploited end-to-end.

在每个基础漏洞报告的正文中：

## Chain context

This finding is the [N]th of [M] independent primitives that together produce [impact, e.g., "permanent account takeover from a stolen session cookie"]. The full chain narrative and the chained severity (P1) are documented in submission [UUID]. This standalone report is at P3 reflecting the primitive's individual impact.

5.3 不要这样做

• 不要在每个基础漏洞的正文中粘贴完整的漏洞链描述。应使用交叉引用。
• 不要声称每个基础漏洞单独就达到 P1——夸大严重性会损害所有关联报告的可信度。
• 不要要求为整个漏洞链支付一笔合并奖金。项目的“一处修复 = 一笔奖金”规则意味着每个独立的修复面都对应一笔单独的奖金。应将漏洞链描述为严重性放大因素，而不是合并请求。

---

6. 目标选择 — QA 与生产环境

同时将生产环境和 QA 资产纳入范围的项目（例如，app.target.com 与 app-qa.target.com）需要谨慎选择目标。

6.1 选择正确的目标下拉选项

如果你测试的是……	选择此目标	原因
生产环境应用／API	生产环境目标	最准确；表明影响实际作用于真实用户
QA 应用／API（根据项目规则，适用于非美国研究人员）	QA 目标（例如，Sign In - (QA)、Enrollment - (QA)）	符合项目规则；表明你是友好测试者
QA 环境，但没有对应的 QA 目标	选择最接近的生产环境目标，并在正文中清楚声明这是 QA 环境	如有需要，分流人员会正确地重新分配报告
跨资产发现（影响多个目标）	漏洞源自的资产／影响最大的资产	在正文中列出其他受影响目标

6.2 QA 环境免责声明段落（提交在 QA 环境中测试的发现时）

## Notes for triagers

- Tested in the QA environment ([qa-host]) per the program's instruction for non-US researchers / per the program's QA-testing scope.
- Production may enforce additional controls that QA does not — please confirm whether the same resolver code path runs on production.
- All testing limited to my own QA test account; no other accounts were interacted with.
- Selected target: `[chosen-target]`. Selected VRT: `[chosen-VRT]`. Both selected as closest available matches; please reassign if more appropriate options exist.

---

7. 研究人员侧的规范（Bugcrowd 专属）

以下项目规则会影响提交质量，尽管它们本身不属于报告正文的一部分。

7.1 账户邮箱 — Bugcrowdninja 别名

多数由 Bugcrowd 管理的项目要求研究人员在目标上将 @bugcrowdninja.com 别名用作账户邮箱。这会将流量标记为友好测试者流量，供目标的欺诈团队识别。步骤如下：

1. 使用你的 Bugcrowd 别名在目标上注册账户（格式如 [email protected]）
2. 如果你已有账户，请在测试前将邮箱更新为该别名
3. 如果项目提供多账户测试的联系渠道，请通过该渠道协调使用其他别名的账户（如 [email protected] 等）
4. 在报告的“给分流人员的备注”部分记录该别名，以便分流人员在日志中关联测试流量

7.2 概念验证后恢复账户状态

演示任何会更改状态的操作（更改密码、更改邮箱、移除设备、转账）后：

1. 立即将账户恢复到概念验证前的状态（例如，将密码改回原来的密码）
2. 在报告中记录恢复情况——“概念验证结束后，账户状态已立即恢复。”
3. 如果无法恢复（例如，已发送的邮件无法撤回），请如实记录残留状态

7.3 提交报告后轮换 Cookie / 会话

提交包含由会话 Cookie 派生的证据的报告后：

1. 先退出登录，再重新登录以轮换会话 Cookie
2. 你提交的截图 / HAR 中可见的任何 Cookie 值现在都已失效
3. 你也可以选择将测试账户的密码更换为一个从未在其他地方使用过的新密码——这样，PoC 截图中可见的密码也会失效

7.4 如果测试账户被锁定

1. 不要创建第二个账户来绕过锁定——这看起来像是在欺诈
2. 如果提供了计划专属联系人，请发送邮件，附上你的 Bugcrowd 用户名和报告 ID
3. 等待计划团队为你解除锁定；在锁定期间进行测试会损害可信度

---

8. 多项发现任务的提交顺序策略

当你在一次任务中有多项发现时，提交顺序很重要。

8.1 建议的顺序

1. 先提交链条原语，再提交使用它们的发现。 使用方会引用原语报告的 UUID，只有提交原语后才会生成这些 UUID（参见 §5.1）。先提交证据最充分的原语以确定时间戳，然后提交链条中的其余原语。
2. 接下来提交链条使用方——填入真实的原语 UUID，然后编辑每个原语，补充使用方的 UUID（Bugcrowd 允许在提交后编辑正文）。
3. 接下来提交独立的 P3 发现。 按证据质量排序：证据最充分的优先，风险较高（接近 OOS）的发现靠后。
4. 最后提交有 OOS 风险的发现。 等这些发现提交时，你已在此次任务中建立了可信的记录。

8.2 跟踪提交 ID

维护一个简单的文本文件，记录每次提交的 UUID、严重程度和一句话描述。你会在报告之间以及后续与分诊人员沟通时引用这些 ID。

8.3 应避免的做法

• 不要在几分钟内一次性提交所有发现。分诊人员会认为这是敷衍的垃圾提交。
• 不要在同一次任务中提交一个干净的 P3 发现之前，就提交有 OOS 风险的发现。干净的发现能建立可信度；在此背景下阅读风险较高的发现，也更有利。
• 在计划明确表示可以之前，不要公开披露任何发现。Bugcrowd 的保密要求同时适用于未解决和已解决的问题。

---

与其他技能搭配使用

对于此问题 / 任务	使用此技能
“我到底该不该报告这个发现？”	triage-validation（7 问门槛）
“Bugcrowd 报告正文模板是什么？”	report-writing
“我该选哪个 VRT？”	此技能（bugcrowd-reporting）§1
“如何论证更高的严重程度？”	此技能 §2-3
“如何反驳 OOS 异议？”	此技能 §4
“如何在截图中遮盖 Cookie / PII？”	evidence-hygiene
“在哪里能找到此利用步骤的载荷？”	security-arsenal
“在哪里能找到适用于此资产类别的侦察探测？”	offensive-osint

---

使用说明

此技能内容精简且聚焦。它不会重复 report-writing 中的内容（各平台模板、CVSS 评分、降级反驳要点、提交前 60 秒检查清单）——提交 Bugcrowd 报告时，请同时加载这两项技能。两项技能的内容可以自然组合，因为二者界限清晰：report-writing 提供正文模板，bugcrowd-reporting 则提供叠加在其上的计划专属策略。

---

相关技能与工作流

• report-writing — 始终与 bugcrowd-reporting 一同加载此技能。工作流基础：report-writing 提供正文骨架；此技能在此基础上叠加 VRT 选择、严重性请求段落和 OOS 条款反驳。
• triage-validation — 用于判断提交至 Bugcrowd 的发现能否通过分流审核。工作流基础：先运行 7Q 门槛；只有通过验证的发现才会进入此技能进行 VRT 映射。
• evidence-hygiene — 用于向 Bugcrowd 提交中附加截图 / HAR 文件。工作流基础：Bugcrowd 的私有附件系统要求证据经过脱敏；点击附加前，先通过 evidence-hygiene 处理所有内容。
• security-arsenal — PoC 步骤需要逐字引用有效载荷时使用。工作流基础：此技能报告正文中的“复现步骤”部分会从 security-arsenal 提取准确的有效载荷，方便分流审核人员复制并运行。
• bb-methodology — 用于确认参与模式是漏洞赏金（而非红队测试）。工作流基础：bb-methodology 的 PART 0 会回答“是否为漏洞赏金？”。如果答案是肯定的，且目标是 Bugcrowd，此技能便会作为报告辅助层。