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 PoC 后恢复账户状态

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

1. 立即将账户恢复到 PoC 前的状态（例如，将密码改回原来的密码）
2. 在报告中记录恢复情况——“PoC 后已立即恢复账户状态。”
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 的保密要求适用于未解决和已解决的问题。

---

陷阱

• VRT 选错 → 自动降级 — 选择与漏洞不匹配的 VRT 类别，会导致分诊人员自动将问题降级为 P4。搜索层级：精确漏洞类别 → 暴露的数据 → 被绕过的控制措施 → 端点类型 → 通用父类别。
• 错误描述 VRT — 选择无法描述漏洞的较高严重性 VRT 来抬高严重性，会被标记并损害可信度。选择最具体且准确的 VRT，然后使用严重性申请段落。
• 严重性申请埋在正文中 — 如果严重性申请段落不是第一个部分，分诊人员会看到 VRT 默认的 P4，并在阅读你的理由前关闭报告。务必将它放在最前面。
• 未提供端到端证明就提交报告 — 没有展示利用过程的观察结果会被视为“理论上的”，并以 OOS 为由关闭。只有在能够向分诊人员完整说明攻击路径时才提交报告。
• 先串联原语，却未先提交报告 — 链的使用者会引用尚不存在的原语 UUID。先提交原语，再提交使用者，之后补上 UUID。
• 将链中的问题合并到一份报告中 — Bugcrowd 的“一项修复 = 一份赏金”规则意味着每个独立的修复面都应单独提交。不要合并；请相互交叉引用。
• 在提交干净的 P3 前先提交有 OOS 风险的发现 — 先通过扎实且明确属于范围内的发现建立可信度。有 OOS 风险的提交，在已有良好记录的背景下更容易获得公正评估。
• 一次性批量提交所有发现 — 在 5 分钟内提交所有内容，看起来像是敷衍的垃圾提交。提交之间至少间隔一小段时间。
• 对链中过度声称 P1 — 每个原语本身都不是 P1。为每个原语单独声称适当的严重性；由链的使用者承担提升后的严重性。
• 忘记 Bugcrowdninja 别名 — 未使用该别名进行测试，会导致你的流量被标记为可能存在欺诈。对于由 Bugcrowd 管理的计划，始终使用 @bugcrowdninja.com 邮箱。
• PoC 后未恢复账户状态 — 修改密码、邮箱等会改变状态的 PoC，如果账户仍处于异常状态，会损害可信度。立即恢复并记录操作。
• 认为 VRT 严重性固定不变 — VRT 默认值会随架构版本和计划配置而变化。务必查看当前表单实际自动建议的内容，不要依赖记忆。

---

9. 与其他技能配合使用

对于此问题 / 任务	使用此技能
“我应该提交这个发现吗？”	triage-validation（7-Question Gate）
“Bugcrowd 报告正文的模板是什么？”	report-writing
“我应该选择哪个 VRT？”	本技能（bugcrowd-reporting）§1
“如何论证更高的严重性？”	本技能 §2-3
“如何反驳 OOS 异议？”	本技能 §4
“如何在截图中隐藏 Cookie / PII？”	evidence-hygiene
“在哪里可以找到此利用步骤的 Payload？”	security-arsenal
“在哪里可以找到此资产类别的侦察探测手段？”	offensive-osint

---

验证

运行以下自测，确认已准备好提交报告：

1. VRT 搜索测试 — 确认你能够浏览 Bugcrowd VRT 界面：

   • 打开一份 Bugcrowd 提交草稿
   • 在 VRT 下拉菜单中搜索 “IDOR”、“XSS” 和 “Broken Access Control”
   • 确认每个搜索词至少都有一个匹配项

2. 严重性申请模板测试 — 确认模板渲染正确：

   grep -q "Severity request — please review carefully" SKILL.md && echo "PASS: template present" || echo "FAIL"
   grep -q "The closest VRT category" SKILL.md && echo "PASS: justification structure present" || echo "FAIL"
   

3. OOS 反驳模板可用性 — 确认全部 5 个反驳模板均存在：

   for clause in "Rate limiting on non-authentication" "Debug information disclosure" "User enumeration with low-risk" "Theoretical issues" "end-to-end proof"; do
     grep -q "$clause" SKILL.md && echo "  OK: $clause" || echo "  MISSING: $clause"
   done
   

4. 交叉引用 UUID 格式 — 确认已记录链式链接的 UUID 格式：

   grep -q "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" SKILL.md && echo "PASS: UUID format documented" || echo "FAIL"
   

5. Bugcrowdninja 别名使用须知 — 确认已记录别名的使用方法：

   grep -q "bugcrowdninja.com" SKILL.md && echo "PASS: alias documented" || echo "FAIL"
   

全部 5 项测试用于验证该技能的关键模板完好无损。

---

使用说明

此技能规模较小，专注于特定用途。它不会重复 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，则此技能将作为报告叠加层。