bugcrowd-reporting

BUGCROWD の報告 — プログラム固有の戦術

汎用の report-writing スキルを補完するものです。VRT マッピング、OOS 条項への反論、またはプログラムごとの対象選定が重要となる、Bugcrowd への報告で使用してください。

このスキルでは、Bugcrowd の報告フローに特化したパターンを解説します。各プラットフォームに共通する汎用テンプレート（HackerOne / Bugcrowd / Intigriti / Immunefi の報告本文）については、report-writing スキルを使用してください。報告するかどうかを決める前に実施する 7-Question Gate については、triage-validation を使用してください。

---

1. VRT カテゴリーの選択 — 検索とフォールバックの戦略

Bugcrowd の報告フォームでは、VRT（脆弱性評価分類）の選択が 1 つ必要です。ドロップダウンのデフォルトの深刻度は、選択したノードに紐付けられています。選択を誤ると、実際の影響が P3 または P2 であるにもかかわらず、フォームがより低い優先度（多くの場合 P4）を自動的に提示します。

注：VRT のデフォルトの深刻度は固定値ではありません。Bugcrowd はバージョンごとに VRT スキーマを改訂しており、各プログラムが独自の優先度設定によってデフォルトを再マッピングする場合もあります。以下の例に示す P 値（例：「No Rate Limiting on Form → Login」のデフォルトは 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
レート制限のないパスワードオラクル	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 mapping note」を記載してください。選択したノードが最も近い選択肢である理由と、実際のバグの内容を説明します。

---

2. 深刻度の手動指定

Bugcrowd のフォームでは、VRT のデフォルトとは別に技術的な深刻度を手動で設定できます。フォームの説明にも、次のように記載されています。「VRT が推奨する深刻度が、提出内容に適用される深刻度になるとは限りません。」

2.1 手動指定する場合

次の場合は、VRT のデフォルトを上書きしてください。

• 複数の脆弱性を連鎖させた結果が、単独のバグクラスより高い深刻度になる場合（連鎖 → ATO）
• VRT のカテゴリーが近似的なもので、デフォルトの深刻度が実際の影響クラスを反映していない場合
• プログラム独自の Focus Areas に、この結果が VRT のデフォルトより高い深刻度で明記されている場合
• 漏えいするデータの種類が、VRT の例で使われているものより機微な場合（例：ハンドルの列挙ではなく、実名を含む PII）

2.2 手動で指定する方法（フォームの操作）

1. バグを最も正確に表す VRT を選択します（§1 に従ってください）
2. 自動提案された深刻度（P4、P3 など）を確認します
3. Technical Severity フィールドで、申請する深刻度を手動で選択します
4. 説明本文の最初のセクションに、Severity Request の段落を追加します（§3 に従ってください）

2.3 過大な主張は避ける

P1 を過剰に主張するのは、トリアージ担当者の信頼を失う最も手っ取り早い方法です。P1 は、ユーザー操作なしの ATO、RCE、大量の PII の持ち出し、資金の窃取など、重大度が Critical に分類される影響に限定してください。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 トーンのガイドライン

• 「深刻度の申請 — VRT のデフォルトを適用する前に、慎重にご確認ください」（この文言をそのまま使用してください）で始めてください。トリアージ担当者はこの表現を認識しており、自動的に却下しません。
• 太字は控えめに使用し、理由ごとに多くても1〜2箇所にしてください。
• 「potentially（潜在的に）」や「may allow（可能にする場合があります）」は使わないでください。これらは深刻度を下げる口実になります。
• プログラム独自の Focus Areas／受け入れ対象の影響リストを、正確な名称で引用してください。
• 関連する提出内容を相互参照する場合は、提出 ID を省略せず UUID 形式で記載してください。

---

4. OOS 条項への反論 — テンプレート

Bugcrowd のトリアージ担当者は、報告書を読まずに OOS 条項に当てはめ、調査結果を自動的に却下することがあります。これを防ぐため、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. 連鎖した発見事項 — 相互参照の戦略

影響度の高い発見事項の多くは、2つ以上の独立したプリミティブを連鎖させたものです（オラクル + ステップアップ認証の欠如 = ATO）。Bugcrowd のプログラムルールでは、次のように定められています。「1つの報告につき、1つの脆弱性を提出してください。影響を示すために複数の脆弱性を連鎖させる必要がある場合は、まとめて提出してもかまいませんが、連鎖の内容を明確に説明してください。」

5.1 連鎖の提出戦略

1. 連鎖によって生じる最も深刻な結果を特定します（通常、プログラムの重点領域にある P1/P2 の例に該当するものです）。
2. 連鎖を構成するプリミティブを先に、それぞれ個別の報告として提出します — 各プリミティブ単独での深刻度（通常は P3/P4）で提出してください。提出の UUID は提出後にのみ発行されるため、参照先となるプリミティブを先に作成しておく必要があります。各プリミティブの本文には、ひとまずプレースホルダーとして相互参照行を残しておきます。
3. 連鎖を利用する報告を提出します — 本文で、連鎖による完全な ATO/RCE などの影響を連鎖後の深刻度（例：P1）で説明する報告です。プリミティブはすでに存在するため、利用側の報告にある「Chain partners」ブロックに実際の UUID を記入します（§5.2 を参照）。
4. 利用側の報告を提出した後で、各プリミティブを編集し、利用側の UUID を追記します：「Chain partner: submission [UUID] for the full impact narrative.」（参照は双方向なので、一方の報告を提出した後にもう一方を編集する必要があります — 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 に該当すると主張しないでください。過大な主張は、関連するすべての報告の信頼性を損ないます。
• 連鎖全体に対して単一の報奨金を求めないでください。プログラムの「修正1件につき報奨金1件」というルールでは、独立した修正対象ごとに別々の報奨金が支払われます。連鎖はマージリクエストではなく、深刻度を引き上げる要因として説明してください。

---

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. 報告の「Notes for triagers」セクションに使用したエイリアスを記載し、トリアージ担当者がログ内のテストトラフィックを照合できるようにします

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. 複数の脆弱性を報告する際の提出順序

1 回のエンゲージメントで複数の脆弱性を発見した場合、提出順序が重要です。

8.1 推奨する順序

1. プリミティブを、その利用側より先に報告します。 利用側のレポートではプリミティブのレポート UUID を参照しますが、その UUID はプリミティブを提出した後にのみ取得できます（§5.1 を参照）。まず、最も証拠が揃ったプリミティブを提出してタイムスタンプを確保し、続いて残りのチェーンのプリミティブを提出します。
2. 次に、チェーンの利用側を提出します — 実際のプリミティブ UUID を記入し、その後、各プリミティブを編集して利用側の UUID を追記します（Bugcrowd では提出後に本文を編集できます）。
3. 次に、単独の P3 脆弱性を提出します。 証拠の質に応じて順序を決め、最も証拠が揃ったものから提出し、OOS に近いリスクの高い脆弱性は後にします。
4. OOS リスクの高い脆弱性は最後に提出します。 これらが届く頃には、このエンゲージメントで信頼できる実績を築けています。

8.2 提出 ID の管理

各提出の UUID、深刻度、1 行の説明を記載したシンプルなテキストファイルを管理します。これらの ID は、レポート間や、その後のトリアージ担当者とのやり取りで参照します。

8.3 避けるべきこと

• 数分の間にすべての脆弱性をまとめて提出しないでください。トリアージ担当者には、労力をかけていないスパムと見なされます。
• 同じエンゲージメントで、問題のない P3 脆弱性より先に OOS リスクの高い脆弱性を提出しないでください。問題のない脆弱性で信頼性を確立しておくと、リスクの高い脆弱性もその文脈で評価されます。
• プログラムから明示的に許可されるまで、脆弱性を公開しないでください。Bugcrowd の守秘義務は、未解決と解決済みの両方の問題に適用されます。

---

9. 他のスキルとの併用

この質問／タスクの場合	このスキルを使用
「この脆弱性を報告すべきですか？」	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 のレポートを提出する際は、両方のスキルを読み込んでください。役割が明確に分かれているため、2 つのスキルの内容は自然に組み合わせられます。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 の場合、このスキルがレポート作成の補助として機能します。