report-writing

レポートの書き方

影響を最初に。人間味のある文体で。理論的な表現は避けてください。トリアージ担当者も人間です。

---

最も重要なルール

「could potentially」「could be used to」「may allow」は絶対に使わないでください。 実際にできるか、できないかのどちらかです。証明できていないなら、主張しないでください。

BAD:  "This vulnerability could potentially allow an attacker to access user data."
GOOD: "An attacker can access any user's order history by changing the user_id
       parameter to the target user's ID. I confirmed this using two test accounts:
       [email protected] (ID 123) successfully retrieved [email protected] (ID 456)
       orders, including their shipping address and payment method last 4 digits."

---

タイトルの形式

[Bug Class] in [Exact Endpoint/Feature] allows [attacker role] to [impact] [victim scope]

良いタイトル（具体的で、影響を最初に示している）：

IDOR in /api/v2/invoices/{id} allows authenticated user to read any customer's invoice data
Missing auth on POST /api/admin/users allows unauthenticated attacker to create admin accounts
Stored XSS in profile bio field executes in admin panel — allows privilege escalation
SSRF via image import URL parameter reaches AWS EC2 metadata service
Race condition in coupon redemption allows same code to be used unlimited times

悪いタイトル（曖昧で、トリアージ担当者の役に立たない）：

IDOR vulnerability found
Broken access control
XSS in user input
Security issue in API
Unauthorized access to user data

---

HACKERONE レポートテンプレート

## Summary

[One paragraph: what the bug is, where it is, what an attacker can do. Be specific.
Include: endpoint, method, parameter, data exposed, required access level.]

Example: "The `/api/users/{user_id}/orders` endpoint does not verify that the
authenticated user owns the requested user_id. An attacker can enumerate any
user's order history, including PII (email, address, phone) and purchase history,
by incrementing the user_id parameter. No privileges beyond a standard free
account are required."

## Vulnerability Details

**Vulnerability Type:** IDOR / Broken Object Level Authorization
**CVSS 3.1 Score:** 6.5 (Medium) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
**Affected Endpoint:** GET /api/users/{user_id}/orders

## Steps to Reproduce

**Environment:**
- Attacker account: [email protected], user_id = 123
- Victim account: [email protected], user_id = 456
- Target: https://target.com

**Steps:**

1. Log in as [email protected], obtain Bearer token

2. Send the following request:

GET /api/users/456/orders HTTP/1.1 Host: target.com Authorization: Bearer ATTACKER_TOKEN_HERE

3. Observe response:

```json
{
  "orders": [
    {"id": 789, "items": [...], "email": "[email protected]", "address": "123 Main St..."}
  ]
}

別のユーザーからのリクエストにもかかわらず、レスポンスには被害者のすべての注文履歴と個人識別情報（PII）が含まれています。

影響

認証済みの攻撃者は、user_id の値を順に変えることで、すべてのユーザーの注文を列挙できます。 これにより、氏名、メールアドレス、配送先住所、購入履歴、支払い方法（下4桁）が漏えいします。 約10万人のユーザーがいる場合、登録ユーザー全員に影響する大規模な個人識別情報（PII）の漏えいとなります。悪用に必要なのは無料アカウントのみで、簡単なループを使えば数分で実行できます。

推奨する修正

サーバー側で所有者を検証してください。

if order.user_id != current_user.id:
    raise Forbidden()

補足資料

[攻撃者のセッションから被害者の注文データが返されていることを示すスクリーンショット] [可能であれば、手順を解説する動画]

---

## BUGCROWD REPORT TEMPLATE

```markdown
# [IDOR] User order history accessible without authorization via /api/users/{id}/orders

**VRT Category:** Broken Access Control > IDOR > P2

## Description

[Same impact-first paragraph as HackerOne summary]

## Steps to Reproduce

[Same structured steps — exact HTTP requests, exact responses]

## Proof of Concept

[Screenshot/video showing the actual impact]

## Expected vs Actual Behavior

**Expected:** 403 Forbidden when user_id does not match authenticated user
**Actual:** 200 OK with victim's full order data

## Severity Justification

P2 (High) — Direct read access to other users' PII. Affects all user accounts.
No user interaction required. Exploitable by any authenticated user.
Automated enumeration could exfil all [N] user records in minutes.

## Remediation

Add ownership verification: `if order.user_id != current_user.id: raise 403`

---

INTIGRITI レポートテンプレート

# [Bug Class]: [Exact Impact] in [Endpoint/Feature]

## Description

[Impact-first paragraph. Start with what an attacker can do, not with how you found it.
Include: endpoint, method, parameter, data exposed, required privileges.]

## Steps to Reproduce

**Environment:**
- Attacker: [email protected] (standard account, no special role)
- Victim: [email protected]
- Tested: [date]

**Reproduction steps:**

1. [Login as attacker / visit URL / send request]

2. Send the following HTTP request:

\```http
METHOD /endpoint HTTP/1.1
Host: target.com
Authorization: Bearer ATTACKER_TOKEN
Content-Type: application/json

{"param": "victim_id_here"}
\```

3. Observe response contains victim's private data:

\```json
{"email": "[email protected]", "address": "123 Main St", ...}
\```

## Impact

[Specific, quantified impact. What data, how many users, what can attacker do.]

CVSS 3.1 Score: X.X ([Severity]) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

## Remediation

[1-3 sentence concrete fix. Include code if helpful.]

## Attachments

[Screenshot or Loom video showing the impact — Intigriti triagers prefer video for complex bugs]

Intigriti 固有の注意事項：

• タイトル形式：[Bug Class]: [One-line impact]（決まった形式は必要ありませんが、具体的にしてください）
• 深刻度は自分で設定します：Critical／High／Medium／Low／Exceptional
• 標準は CVSS 3.1 です（新しいプログラムでは CVSS 4.0 も受け付けています）
• スクリーンショットだけよりも PoC 動画が高く評価されます。Loom で録画してください
• セーフハーバー：Intigriti はこれを適用しているため、やや積極的なテストも安心して行えます

---

IMMUNEFI レポートテンプレート

# [Bug Class] — [Protocol Name] — [Severity]

## Summary

[One paragraph with: root cause, affected function, economic impact, attack cost.
Include numbers where possible: "attacker can drain $X in Y transactions."]

## Vulnerability Details

**Contract:** `VulnerableContract.sol`
**Function:** `claimRedemption()`
**Bug Class:** Accounting State Desynchronization
**Severity:** Critical

### Root Cause

[Exact code snippet showing the vulnerable code with comments]

## Proof of Concept

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
// Foundry PoC — run: forge test --match-test test_exploit -vvvv

contract ExploitTest is Test {
    // ... full working exploit
}

影響

[定量化：「攻撃者は TVL の X%（現在のレートで $Y）を引き出せます。 必要なガス代は $Z です。攻撃は繰り返し実行できます。」]

推奨する修正

[変更前／変更後を示した具体的なコード変更]

---

## CVSS 3.1 QUICK SCORING

### Formula

CVSS = f(AV, AC, PR, UI, S, C, I, A)

### Metric Quick Picks

| Metric | Value | Weight | When |
|---|---|---|---|
| **Attack Vector (AV)** | Network | +0.85 | Via internet |
| | Local | +0.55 | Local access needed |
| **Attack Complexity (AC)** | Low | +0.77 | Repeatable |
| | High | +0.44 | Race/timing needed |
| **Privileges Required (PR)** | None | +0.85 | No login |
| | Low | +0.62 | Regular user account |
| | High | +0.27 | Admin account |
| **User Interaction (UI)** | None | +0.85 | No victim action |
| | Required | +0.62 | Victim must click |
| **Scope (S)** | Changed | higher | Affects browser/OS/other |
| | Unchanged | lower | Stays in app |
| **Confidentiality (C)** | High | +0.56 | All data exposed |
| | Low | +0.22 | Limited data |
| **Integrity (I)** | High | +0.56 | Can modify any data |
| **Availability (A)** | High | +0.56 | Crashes service |

### Typical Scores by Bug Class

| Bug | Typical CVSS | Severity |
|---|---|---|
| IDOR (read PII) | 6.5 | Medium |
| IDOR (write/delete) | 7.5 | High |
| Auth bypass → admin | 9.8 | Critical |
| Stored XSS (any user) | 5.4–8.8 | Med–High |
| SQLi (data exfil) | 8.6 | High |
| SSRF (cloud metadata) | 9.1 | Critical |
| Race condition (double spend) | 7.5 | High |
| GraphQL auth bypass | 8.7 | High |
| JWT none algorithm | 9.1 | Critical |

---

## SEVERITY DECISION GUIDE

### Critical (P1)
- Full account takeover of any user without interaction
- Remote code execution
- SQLi with ability to dump/modify entire DB
- Auth bypass to admin panel
- SSRF to cloud metadata → IAM credentials exfil

### High (P2)
- Mass PII exposure (email, phone, SSN, payment data)
- Privilege escalation from user to admin
- SSRF reaching internal services (data returned)
- Stored XSS executing for all users of sensitive feature
- Payment bypass / financial loss without limit

### Medium (P3)
- IDOR on specific user's non-critical data
- XSS on low-sensitivity page requiring victim interaction
- CSRF on important but non-critical action
- Rate limit bypass on OTP (with effort demonstrated)

### Low (P4)
- Information disclosure (non-sensitive, no PII)
- Clickjacking on sensitive action WITH working PoC
- CORS on limited data

---

## SEVERITY SELF-ASSESSMENT

Each YES raises severity:

1. 他のユーザーの個人情報／健康情報／金融情報が漏えいするか？ → 深刻度 +1
2. アカウント乗っ取りや権限昇格が可能か？ → 深刻度 +2
3. 被害者側の操作がまったく不要か？ → 深刻度 +1
4. 特定の条件に限らず、すべてのユーザーに影響するか？ → 深刻度 +1
5. 内部ネットワークへのアクセスなしでリモートから悪用できるか？ → High+ の基本条件

---

## DOWNGRADE COUNTERS

| Program Says | Counter With |
|---|---|
| "Requires authentication" | "Attacker needs only a free account — no special role or permission" |
| "Limited impact" | "Affects [N] users / exposes [PII type] / $[amount] at risk" |
| "Already known" | "Show me the report number — I searched hacktivity and found none" |
| "By design" | "Show me the documentation stating this is intended behavior" |
| "Low CVSS" | "CVSS doesn't capture business impact — attacker can extract [X] in [Y] minutes" |
| "Not exploitable" | "Here is the exact response showing victim's data returned to attacker session" |

---

## THE 60-SECOND PRE-SUBMIT CHECKLIST

[ ] タイトルが次の形式に従っている：[Class] in [endpoint] allows [actor] to [impact] [ ] 最初の文で、正確な影響を平易な英語で説明している [ ] 再現手順に、コピーしてすぐ使える正確な HTTP リクエストが含まれている [ ] バグを示すレスポンスが含まれている（スクリーンショットまたは JSON 本文） [ ] 2つのテストアカウントを使用している。1つのアカウントを使った自己テストだけではない [ ] CVSS スコアを算出して記載している [ ] 推奨する修正が1～2文で書かれている（長々とした説明ではない） [ ] エンドポイントのパスやパラメーター名に誤記がない [ ] レポートが600語未満である。トリアージ担当者は長いレポートを流し読みします [ ] 主張した深刻度が説明した影響と一致している。誇張しない [ ] 「could potentially」や「may allow」を使っていない [ ] トリアージ担当者が初期状態から再現できる PoC になっている

---

## CVSS 4.0 QUICK REFERENCE (newer programs)

CVSS 4.0 replaced CVSS 3.1 in November 2023. Some newer programs require it.

### Key Differences from CVSS 3.1

| Metric | CVSS 3.1 | CVSS 4.0 |
|---|---|---|
| Attack Vector | Network/Adjacent/Local/Physical | Same |
| Attack Complexity | Low/High | Low/High |
| **NEW**: Attack Requirements | (didn't exist) | None/Present (replaces some PR/UI) |
| Privileges Required | None/Low/High | Same |
| User Interaction | None/Required | None/Passive/Active |
| Scope | Unchanged/Changed | REMOVED |
| **NEW**: Sub-Impact metrics | (didn't exist) | Vulnerable/Subsequent system impact |

### CVSS 4.0 Score Examples

| Finding | CVSS 4.0 Score | Vector |
|---|---|---|
| Unauthenticated RCE | 10.0 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H |
| IDOR read PII, auth required | 6.9 | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N |
| Stored XSS, admin views it | 8.2 | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N |
| SSRF → cloud metadata | 8.7 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N |

### Quick CVSS 4.0 Calculator

使用先：https://www.first.org/cvss/calculator/4.0 主なフィールド： VC/VI/VA = 脆弱なシステムの機密性／完全性／可用性 SC/SI/SA = 影響を受ける後続システム（下流への影響） AT = None（特別な条件なし）| Present（競合状態／特定の設定が必要） UI = None | Passive（被害者が URL にアクセスする）| Active（被害者が明示的な操作を行う）

**Practical rule**: If program uses CVSS 4.0 and you don't know the vector, use the calculator and include the full string starting with `CVSS:4.0/AV:...`. Programs cannot dispute a valid vector string.

---

## HUMAN TONE GUIDELINES

**Write to a person, not a system:**
- Triagers are tired. Get to the impact in sentence 1.
- Use "I" not "the researcher" — you found it, own it
- Short paragraphs, bullet points for steps
- Hyperlink relevant docs if needed

**Escalation language (when payout is being downgraded):**

「この脆弱性の悪用に特別な権限は必要ありません。無料アカウントだけで実行できます。」 「漏えいするデータには[PII の種類]が含まれており、GDPR の要件の対象です。」 「攻撃者は簡単なループで自動化でき、数分ですべての[N]件のレコードを取得できます。」 「内部システムへのネットワークアクセスなしで、外部から悪用できます。」 「影響は、[機能／データの種類]の完全なデータ漏えいに相当します。」

**Avoid:**
- Jargon the triager might not know
- 5-paragraph explanations of what IDOR is (they know)
- Theoretical chains ("could be combined with X to...")
- Passive voice ("it was observed that...")
- Qualifying language ("seems to," "appears to")

---

## STEPS TO REPRODUCE FORMAT (triager-optimized)

```markdown
**Setup:**
- Account A (attacker): [email protected], ID=111
- Account B (victim): [email protected], ID=222
- Both created via normal registration — no special access

**Steps:**

1. Log in as Account A
2. Send this request (replace `111` with victim ID `222`):

\```
GET /api/v2/resource/222 HTTP/1.1
Host: target.com
Authorization: Bearer ACCOUNT_A_TOKEN
\```

3. Response contains Account B's private data:

\```json
{"id": 222, "email": "[email protected]", "name": "Victim User", "address": "..."}
\```

**Expected:** 403 Forbidden
**Actual:** 200 OK with victim's private data

---

関連スキルとチェーン

• triage-validation — レポートを作成するかどうかを判断するときに使用します。ワークフローの基本ルール：triage-validation の7つの質問によるゲートを通過する前に、このスキルを絶対に開かないでください。ゲートを通過できない指摘事項は、レポートにまとめず、却下してください。
• bugcrowd-reporting — 対象がBugcrowdのプログラムである場合に使用します。ワークフローの基本ルール：このスキルの本文テンプレートを土台として、bugcrowd-reporting でVRTの選定、重大度引き上げを求める段落、OOS条項への反論を追加します。
• evidence-hygiene — PoCのスクリーンショットやHARファイルをレポートに添付するときに使用します。ワークフローの基本ルール：「Supporting Materials」／「Proof of Concept」セクションで参照するすべての成果物は、添付前に evidence-hygiene に通し、CookieとPIIを編集・削除します。
• redteam-report-template — エンゲージメントが外部レッドチームの場合（バグバウンティではない場合）に使用します。ワークフローの基本ルール：bb-methodology PART 0でエンゲージメントのモードを確認します。レッドチームの場合は、このスキルを redteam-report-template に切り替えてください（対象読者と構成が異なります：Subject／Observations／Description／Impact／Recommendation／PoC）。

---

オペレーター向けメモ（Claude-BugHunter）

ベンダー提供の基盤に、エンゲージメントから得た知見を追加したものです。実際に許可を得て行ったエンゲージメントと、このリポジトリの31以上のスキル領域におけるライブテストでのPhase 2検証から得た知見です。上流の方法論がWHATを扱うのに対し、このレイヤーでは、実際に機能する条件と失敗モードを扱います。

実践におけるタイトルの構成

<asset> | <bug class> | <impact> — 3つの要素で構成し、無駄な言葉は入れません。トリアージ担当者がタイトルを読むのにかける時間はおよそ3秒で、タイトルをもとにキューの順序を決めます。

• 悪い例：「/api/usersで興味深い問題を発見」
• 悪い例：「APIのIDOR脆弱性」
• 良い例：「認証済みIDORにより、/api/users/{uid}で管理者のメールアドレスとロールが漏えい」
• 良い例：「未認証SSRFにより、/preview?url=からAWSメタデータ169.254.169.254にアクセス可能」

悪いタイトルのレポートは、最後に開かれます。良いタイトルのレポートは、最初に開かれます。同じ指摘事項でも、キュー内の位置、トリアージの日、報奨金の支払い速度が変わります。

トリアージ担当者が実際に読むもの

新しいレポートを読む順序は次のとおりです。

1. タイトル（3秒）
2. 影響／概要の最初の段落（15秒）
3. curlコマンドまたはHTTPリクエストのブロック（30秒）
4. 再現手順（最初の3項目に納得した場合のみ）
5. その他すべて（フォローアップレビューの場合のみ）

レポートの冒頭を徹底的に最適化してください。説明文は中盤に回します。手順3で納得したトリアージ担当者は、残りをそのまま承認します。手順3で納得しなければ、手順5まで読みません。

CVSS 3.1、Bugcrowd VRT、H1のデフォルト重大度

この3つのシステムは、約30％の確率で評価が一致しません。よくある差異として、CVSSスコアが7.x（High）の指摘事項が、BugcrowdではP4（Low）、またはH1ではデフォルトでMediumに分類されます。プラットフォームのデフォルト評価がCVSSより低い場合：

1. 重大度引き上げを求める段落を、本文の最初のセクションに記載します。 Bugcrowdではこの方法が有効です。（標準テンプレートについては bugcrowd-reporting を参照してください。）
2. 主観ではなく、CVSSベクター文字列とビジネスへの影響を根拠に依頼します。 「CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5 High。これは、テナント間のデータ漏えいにConfidentiality:Highが適用されるためです。」
3. 指摘事項に該当する、プラットフォーム独自のVRT項目を引用します。 プラットフォームに異議を唱えるのではなく、プラットフォームの分類に沿って申請してください。

許可を得たバグバウンティエンゲージメントでは、デフォルトでP4だった指摘事項が、重大度引き上げを求める段落によってP3に引き上げられました。引き上げは自動ではありません。根拠を示し、本文の最初のセクションで明確に依頼する必要があります。

証拠のローテーション

提出本文の内容はすべて、プラットフォームによって永久に記録されます。それを踏まえて行動してください：

• この業務のために専用に作成した使い捨てのテストアカウントを使用してください。
• 各提出後に Cookie / トークンをローテーションしてください（レポートに貼り付けた Cookie を再利用しないでください）。
• 本番環境の Cookie、実在ユーザーのメールアドレス、実際の PII をレポート本文に貼り付けないでください — PoC の手順で伏せ字にしてください。
• 管理パネルのスクリーンショット：ユーザー一覧をぼかし、URL バーにトークンが含まれる場合はぼかしてください。

完全なキャプチャと伏せ字のプロトコルについては evidence-hygiene を相互参照してください。

プラットフォーム別テンプレート — 異なる場合

プラットフォーム	トーン	必須の構成	深刻度の仕組み
HackerOne	物語形式	概要 -> 手順 -> 影響 -> 修正案	トリアージ担当者が設定、異議申し立て可能
Bugcrowd	構造化	深刻度の申請 -> VRT カテゴリ -> タイトル -> 本文 -> 修正	VRT デフォルト + 手動上書きの段落
Intigriti	中間	概要 -> PoC -> 影響 -> 推奨事項	研究者が提案、トリアージ担当者が確認
Immunefi	PoC 優先	動作する PoC コード -> ウォークスルー -> 影響 -> 深刻度	Foundry/Hardhat のコードが主要な成果物

誤ったテンプレートスタイルを選ぶと、有効性を損ないます。物語形式に偏った Bugcrowd レポートは、トリアージ担当者が必要とする VRT マッピングを欠きます。構造化された H1 レポートはそっけなく読まれ、支払いを遅らせる追加質問を受けることになります。

レポート作成における最大の単一の過ち

攻撃が「理論上」機能する、あるいは「[より大きな影響] に連鎖させられる」と、それを実証せずに主張することです。トリアージ検証の Q6（技術的に可能な範囲を超えた影響）は、検証側でこれらを排除します。レポート作成は、作成側でそれを反映しなければなりません。

有効な道は 2 つあります：

1. 具体的な影響をエンドツーエンドで示す。 テストアカウントで連鎖をキャプチャしてください。リクエスト / レスポンスのシーケンス全体を貼り付けてください。以上です。
2. 実際に実証した内容に合わせて深刻度の主張を引き下げる。 「/api/users/{uid} における IDOR でメール + ロールを読み取る」は現実的で報告可能ですが、「管理者乗っ取りの可能性に連鎖する IDOR」は、乗っ取りを実証するまではそうではありません。

どちらかを選んでください。「可能性がある」「〜を許すかもしれない」で折衷してはいけません — これらの表現は、レポートが理論的であるというトリアージ担当者へのシグナルであり、理論的なレポートは N/A になります。

• bb-methodology — フェーズ 5 のレポート作成ステップが始まるとき。ワークフローのプリミティブ：フェーズ 5 が /report を呼び出し、これがプラットフォーム固有のテンプレート（H1 / Bugcrowd / Intigriti / Immunefi）のためにこのスキルを読み込みます。