evidence-hygiene

証拠の衛生管理 — PoC のキャプチャとマスキングの規律

スクリーンショットの撮影、HAR のエクスポート、バグバウンティの報告への証拠の添付を行う前に、このスキルを使用してください。Cookie の漏えい、同意のない PII の共有、トリアージに不適切なスクリーンショットなど、証拠の衛生管理に関するよくあるミスを防ぎます。

基本原則：バグバウンティの証拠は、トリアージ担当者を納得させるためのものです。それ以上のもの、たとえば有効な Cookie、実在ユーザーの PII、役に立たない内部トレース ID は、証拠に含めるべきではありません。

---

1. 機密データの 2 つのカテゴリ

各 PoC 成果物（スクリーンショット、HAR、HTTP リクエストの生データ、ターミナルの記録）には、それぞれ異なる扱いが必要なデータが含まれている可能性があります。

カテゴリ	例	扱い
自分のアカウントの秘密情報	セッション Cookie、OAuth トークン、リフレッシュトークン、API キー	必ずマスキングしてください。非公開のバグバウンティプラットフォームへの添付であっても同様です。自分のアカウントとセッションを保護してください。
他のユーザーの PII	実名、メールアドレス、電話番号、住所、プロフィール写真、アカウント ID	アカウントをまたぐ影響を明示的に示す場合を除き、マスキングしてください。その場合でも、顔を隠し、表示するデータを最小限にしてください。
トリアージに役立つメタデータ	トレース ID（x-datadog-trace-id）、リクエスト ID、サーバーのタイムスタンプ、自分のテストアカウントの UID／メールアドレス、GraphQL のオペレーション名、レスポンスの形式	見える状態にしてください。トリアージ担当者がログを照合し、再現する際に役立ちます。
テストアカウントのパスワード（限定的な使用）	テストアカウントで使い捨てのパスワード（例：Testing@5678）	報告の提出後すぐに変更するのであれば、スクリーンショットに含めても問題ありません。実際に使用しているパスワードを証拠に残さないでください。

---

2. Cookie のマスキング手順

2.1 マスキングが必要なもの

セッション Cookie の値は、あらゆる PoC で最も価値の高い秘密情報です。以下をマスキングしてください。

• セッション Cookie（authn、session、sid、__Secure-id など。名前は対象によって異なります）
• セッションに紐づいている場合の csrf-token
• Authorization ヘッダー（Bearer トークン、JWT）
• セッションを保持する Cookie の値を含む Cookie リクエストヘッダー
• セッションを保持する Cookie の値を含む Set-Cookie レスポンスヘッダー

2.2 見える状態にしても安全なもの

• Cloudflare Cookie（__cf_bm、_cfuvid） — これらはボット管理用で、セッションを保持するものではありません
• アナリティクス Cookie（ajs_anonymous_id、_ga）
• トレース照合 ID（x-datadog-trace-id、x-request-id）
• サーバー／フレームワークのヘッダー（Server: cloudflare、X-Frame-Options）
• 自分のテストアカウントのメールアドレス／UID（bugcrowd-reporting の Bugcrowdninja エイリアスのセクションを参照）

2.3 マスキング方法（実用性の高い順）

方法 A — そもそも Cookie をキャプチャしない（可能な場合は推奨）

• DevTools Console の PoC では、credentials: 'include' を使い、ブラウザーに Cookie を自動送信させます。Console の出力に Cookie は表示されません。Console の出力をスクリーンショットに撮り、Network タブの Headers パネルは撮影しないでください。
• Burp Repeater の PoC では、スクリーンショットを撮る前に、下部のリクエスト／レスポンスパネルの境界線を下へドラッグしてリクエスト本文を隠します。Intruder の実行では、Results テーブルのみをキャプチャしてください。

方法 B — 画像編集ソフトで黒塗りする（キャプチャに Cookie が含まれてしまう場合）

• macOS：スクリーンショットを Preview で開き、Tools → Annotate → Rectangle の順に選択します。塗りつぶしの色を黒に設定し、Cookie の値を四角形で覆ってから保存します。
• Windows：Snip & Sketch の注釈ツール、または任意の画像編集ソフト（Paint.NET など）を使用します。
• Burp 自体：Burp の Proxy → Match and Replace で、スクリーンショットを撮る前に Cookie の値をプレースホルダー文字列へ事前に置換できます。

方法 C — 生テキストで検索・置換する（HAR ファイル、ターミナルの記録の場合）

• jq コマンドについては §4 を参照してください。

2.4 スクリーンショット撮影前のチェックリスト

Capture をクリックする前に：

[ ] Network tab Headers panel is collapsed or out of frame
[ ] Burp's Request panel is hidden behind the divider drag
[ ] No "Copy as cURL" output is visible on screen
[ ] DevTools Application → Storage → Cookies tab is closed
[ ] Browser URL bar doesn't show a session token in query string (rare but possible)

撮影後：

[ ] Open the screenshot at full resolution before saving
[ ] Search for the session cookie name substring in any visible text — if present, redact
[ ] Search for the literal first 6 chars of your cookie value — if present, redact
[ ] Compare to the previous PoC screenshot in the same engagement — same redaction discipline

---

3. PII の黒塗り手順

PoC で他のユーザーのデータをどうしても表示する必要がある場合（例：攻撃者のセッションでのレスポンスに被害者のメールアドレスを表示して IDOR を実証する場合）、非公開の添付ファイルであっても実際の PII をマスキングしてください。

3.1 マスキングする情報（他のユーザーのデータ）

• 名、姓（すべて、または一部）
• メールアドレス（ローカル部をマスキングします。個人を特定できない場合はドメインを残してもかまいません）
• 電話番号（末尾7桁をマスキングします。国番号は任意で残せます）
• 住所（市区町村より下の情報をすべてマスキングします）
• 生年月日（年をマスキングします。月は任意でマスキングできます）
• 公的な身分証明書番号（SSN、パスポート番号など。すべてマスキングします）
• プロフィール写真／顔画像（顔全体を黒塗りします）
• ユーザーが公開プロフィールと照合できるアカウント ID

3.2 表示したままにする情報（ユーザーではなくバグを証明する情報）

• フィールドが返された事実（JSON キー名）
• フィールドの形式／型（"first_name": "<REDACTED>"）
• 自分の（攻撃者セッションの）UID／メールアドレス — アカウント間のアクセスであることを証明します
• エンドポイント URL とリクエストメソッド
• トレース ID

3.3 使用例 — IDOR PoC の本文

悪い例（被害者の個人情報をすべて漏えい）：

{"data":{"contact":{"first_name":"Nadene","last_name":"Afton","email":"[email protected]","phone":"+1-555-867-5309"}}}

良い例（バグを証明しつつ、個人情報をマスキング）：

{"data":{"contact":{"first_name":"<REDACTED — real first name>","last_name":"<REDACTED — real last name>","email":"<REDACTED>@example.com","phone":"<REDACTED>"}}}

スクリーンショットの場合は、各値を四角形の注釈で黒塗りし、スペースがあれば「REAL PII REDACTED」とラベルを付けてください。

3.4 レポート本文での記載

マスキングしたことを明示してください。

## Proof of Concept

The screenshot below demonstrates the IDOR. The attacker session (uid 12345678) successfully retrieves the victim's profile data (uid 99887766). **Real PII fields in the response are masked with black rectangles to limit unauthorized exposure of victim data, per responsible-disclosure hygiene.** The unredacted response is available privately on request.

これにより、報告内容を慎重に扱っていることがトリアージ担当者に伝わり、検証に必要な場合にマスキング前の情報を確認するための明確な手段も提供できます。

---

4. HAR ファイルのサニタイズ

HAR（HTTP Archive）ファイルは、リクエスト／レスポンス本文とヘッダーを含む、ネットワークトラフィックの JSON ダンプです。Cookie、認証トークン、転送中のあらゆる個人情報が含まれます。

4.1 HAR を生成する

Chrome DevTools → Network タブ → リクエスト一覧の任意の場所を右クリック → 「Save all as HAR with content」

4.2 添付する前にサニタイズする

jq を使って機密性の高いヘッダーを削除します。再利用できるように、これをシェル関数またはワンライナーとして保存してください。

sanitize_har() {
  local input="$1"
  local output="${1%.har}.sanitized.har"

  jq '
    .log.entries |= map(
      (.request.headers |= map(
        if .name | ascii_downcase | IN("cookie", "authorization", "x-csrf-token") then .value = "<REDACTED>" else . end
      )) |
      (.response.headers |= map(
        if .name | ascii_downcase | IN("set-cookie") then .value = "<REDACTED>" else . end
      )) |
      (.request.cookies |= map(.value = "<REDACTED>")) |
      (.response.cookies |= map(.value = "<REDACTED>"))
    )
  ' "$input" > "$output"

  echo "Sanitized: $output"
}

使用方法：

sanitize_har /path/to/exported.har
# Output: /path/to/exported.sanitized.har

4.3 添付する前に確認する

# Check that no Cookie or Authorization values are leaking
grep -i 'authn\|"cookie"\|authorization' /path/to/exported.sanitized.har | head -20

出力に実際の Cookie 値が表示される場合、サニタイズで見落としがあります。そのフィールド名に合わせて jq フィルターを修正してください。

4.4 他のユーザーの個人情報を削除する（該当する場合）

HAR にアカウント間のデータ（例：IDOR のデモ中に取得したデータ）が記録されている場合は、被害者の個人情報を含むレスポンス本文のフィールドも削除してください。jq フィルターに次を追加します。

(.response.content.text |= (
  if . then 
    (fromjson? // .) | tostring | gsub("real.first.name.example"; "<REDACTED>")
  else . end
))

取得したデータに合わせて gsub パターンを調整してください。

---

5. Burp Suite のスクリーンショットを安全に扱う

5.1 Repeater（単一リクエストのデモ）

1. Repeater のリクエストパネルでは、Cookie ヘッダーは独立した行にあります。パネルの境界線を下にドラッグし、リクエスト行／ターゲット行より下をすべて隠します
2. または、スクリーンショットを撮る前に Repeater ペインから Cookie ヘッダーのテキストを一時的に削除します（元のキャプチャ済みリクエストには影響しません）。撮影後に戻してください
3. バグを示す JSON／HTML レスポンスが表示された右側のレスポンスパネルのみをキャプチャします

5.2 Intruder の結果テーブル（レート制限／総当たり攻撃のデモ）

結果ウィンドウは、レート制限の調査結果を示す最も有力な証拠です。見やすくキャプチャするには、次の手順に従います。

1. 攻撃が完了したら、結果テーブルとリクエスト／レスポンスパネルの間にある水平の境界線を下にドラッグし、結果テーブルだけが表示されるようにします
2. 次の列だけをスクリーンショットに含めます：Request#、Payload、Status code、Response received、Length
3. リクエスト／レスポンスのサブパネルは含めないでください。Cookie が含まれています

5.3 Proxy の HTTP 履歴（キャプチャのデモ）

スクリーンショットとして適切なことはほとんどありません。Cookie を含むリクエスト／レスポンス全体が表示されるためです。デモには代わりに Repeater を使用してください。

5.4 Scanner の検出結果（該当する場合）

Scanner タブの Issues パネルは、通常、安全にスクリーンショットを撮れます。元のリクエスト本文を表示せずに、検出結果の概要が表示されます。特定の検出結果を開いてからスクリーンショットを撮る場合は、先にその証拠をマスキングしてください。

---

6. Chrome DevTools のコンソール PoC パターン

6.1 クリーンな PoC のパターン

fetch('/api/endpoint', {
  method: 'POST',
  headers: {'content-type': 'application/json'},
  credentials: 'include',  // sends cookies automatically — they won't appear in your code
  body: JSON.stringify({ /* your payload */ })
}).then(r => r.json()).then(j => console.log("LABEL:", JSON.stringify(j)))

これがクリーンである理由：

• credentials: 'include' により、ブラウザーは Cookie を送信します。コードから Cookie を参照することはありません。スクリーンショットにも表示されません。
• console.log("LABEL:", ...) によって、スクリーンショット内で検索できる、ラベル付きの出力行が生成されます。
• JSON.stringify(j) はレスポンスを 1 行に整形するため、きれいに切り抜きやすくなります。

6.2 複数ステップの PoC（呼び出しの間にコンソールをクリアする）

4 ステップの PoC（変更前の確認／変更／変更後の確認／元に戻す）の場合、各スクリーンショットに 1 回の呼び出しと 1 件のレスポンスだけが表示されるよう、呼び出しの間にコンソールをクリアします。

• Mac：Cmd+K
• Windows / Linux：Ctrl+L

レスポンスが表示されたら、すぐにスクリーンショットを撮影してください。無関係なフレームワークの警告が表示されるまで待たないでください。

6.3 長いレスポンス（スクリーンショット用に切り詰める）

レスポンス本文が長すぎて、きれいなスクリーンショットを撮れない場合は、代わりに要約を出力します。

fetch('/api/endpoint', { /* ... */ })
  .then(r => r.json())
  .then(j => {
    console.log("RESPONSE SHAPE:", Object.keys(j.data || {}));
    console.log("CRITICAL FIELD:", j.data?.victim_id, j.data?.email);
    // (Don't dump the full j — your screenshot becomes unreadable)
  })

6.4 貼り付け許可に関する注意

Chrome は、自己 XSS 対策として DevTools のコンソールへの貼り付けをブロックします。各セッションの開始時に、allow pasting（そのままのフレーズ）を一度入力してください。「PoC 実行中」のスクリーンショットを撮る前に行ってください。そうしないと、警告文がスクリーンショットに表示されます。

---

7. スクリーンショット撮影順序の徹底

7.1 5 ステップの PoC パターン（状態変更に関する報告向け）

「追加認証なしでパスワードを変更できる」のような報告には、次の 5 枚のスクリーンショットを撮るのが標準的なパターンです。

1. 変更前の状態確認 — verify_password("current") → true。開始時の状態を把握していたことを証明します。
2. 脆弱性そのもの — 追加認証なしで update_password(...) が成功します。最も重要なスクリーンショットです。
3. 変更後の状態確認（否定） — verify_password("old") → false。変更が反映されたことを証明します。
4. 変更後の状態確認（肯定） — verify_password("new") → true。新しい認証情報が有効であることを証明します。
5. 帯域外の副作用 — 通知メールが届いたかどうかを示す受信トレイのスクリーンショット。受動的な防御策の有無を証明します。

7.2 ファイル名の規則

番号付きで、内容が分かりやすく、ハイフンで区切ります。

{finding-#}-step{step-#}-{description}.png

Examples:
04-step1-verify-true-before.png
04-step2-update-password-no-stepup.png
04-step3-verify-false-after.png
04-step4-verify-true-new-pw.png
04-step5-inbox-notification-check.png

報告本文では、各ファイルをファイル名で参照します。

- **Screenshot 1 (`04-step1-verify-true-before.png`)** — verify_password returns true with the current password.
- **Screenshot 2 (`04-step2-update-password-no-stepup.png`)** — update_password returns User with no StepUpRequiredError. THIS IS THE BUG.
- **Screenshot 3 (`04-step3-verify-false-after.png`)** — verify_password with old password returns false.
- **Screenshot 4 (`04-step4-verify-true-new-pw.png`)** — verify_password with new password returns true.
- **Screenshot 5 (`04-step5-inbox-notification-check.png`)** — inbox showing whether out-of-band notification was sent.

7.3 撮影のタイミング

• 複数のセッションに分けず、一度にすべてのスクリーンショットを撮影してください。セッション途中での不一致（ブラウザーのサイズの違い、Cookie の値の違いなど）は、トリアージ担当者を混乱させます。
• 可能であれば、スクリーンショットの合間にページを再読み込みしないでください。再読み込みによって Cookie が再生成され、以前のキャプチャが無効になる場合があります。

---

8. 提出後の情報管理

バグ報奨金プラットフォームで［Submit］をクリックした後：

8.1 テストアカウントの認証情報を変更する

1. Log out of the target
2. Log back in (this rotates the session cookie — any cookie shown in your screenshots is now dead)
3. Change the password to a fresh value not used elsewhere (any password shown in your screenshots is now dead)

8.2 未編集の成果物を非公開で保存する

未編集の HAR やスクリーンショットは、自分だけがアクセスできるローカルフォルダーに保管してください。トリアージ担当者から、検証時に未編集版の提示を求められる場合があります。未編集の成果物をメールで共有してはいけません。既存の提出スレッドで、プラットフォームの非公開添付機能を使用してください。

8.3 報告内容を公開しない

ほとんどのプラットフォームでは、未解決か解決済みかを問わず、問題の機密保持が求められます。プログラムから明示的な許可が出るまで、発見内容をツイートしたり、ブログに書いたり、フォーラムで話し合ったりしないでください。

8.4 ローカルの成果物を監査する

四半期ごとに、~/security-research/ と ~/Downloads/ を調べ、過去の案件の古い HAR やスクリーンショットを整理してください。適切に暗号化されたアーカイブに移すか、削除してください。バグ報奨金プログラムの成果物には機密情報が含まれます。すぐに蓄積し、リスクになります。

---

9. 他のスキルとの組み合わせ

この質問／タスクの場合	使用するスキル
「この発見事項は報告すべきですか？」	triage-validation
「報告本文のテンプレートはどこにありますか？」	report-writing
「Bugcrowd 向けの VRT／深刻度／OOS への反論は？」	bugcrowd-reporting
「この証拠をどのように編集／無害化しますか？」	このスキル（evidence-hygiene）
「脆弱性が実際に発生することを、どう示せばよいですか？」	security-arsenal
「この資産クラス向けの偵察プローブはどこにありますか？」	offensive-osint

---

使用上の注意

このスキルは、提出内容を準備する際に report-writing と（Bugcrowd の場合は）bugcrowd-reporting と併せて読み込むことを想定しています。次の内容は対象外です。

• 何を記録するか（それは triage-validation と report-writing の役割です。レポートを受理してもらうために必要な証拠を示します）
• 悪用をどのように実証するか（それは security-arsenal の役割です。送信するペイロードを扱います）
• アセットをどこで見つけるか（それは offensive-osint の役割です。偵察を扱います）

このスキルが扱うのは、「証拠が手元にある」状態から「プラットフォームに添付する」までの、墨消し／サニタイズ／衛生管理のレイヤーのみです。

---

関連スキルと連携フロー

• report-writing — 証拠の墨消しが済み、レポート本文に使用できる状態になったときに使います。ワークフローの基本：墨消しがスクリーンショット撮影前のチェックリストを通過したら、report-writing に引き継ぎ、プラットフォーム固有のレポートテンプレート（H1／Bugcrowd／Intigriti／Immunefi）を作成します。
• bugcrowd-reporting — 墨消し済みの証拠を特に Bugcrowd に提出する場合に使います。ワークフローの基本：墨消し済みのスクリーンショットとサニタイズ済みの HAR が、bugcrowd-reporting の VRT に対応付けられた提出本文で参照する添付ファイルになります。
• triage-validation — そもそもどの証拠が必要かを判断するときに使います。ワークフローの基本：triage-validation が「ステップアップ認証なしのパスワード変更について、5 枚のスクリーンショットによる PoC が必要」と示したら、このスキルが「その 5 枚のスクリーンショットを適切に記録し、墨消しする方法」を示します。
• security-arsenal — 証拠を生成したペイロードを文書化するときに使います。ワークフローの基本：ペイロード（security-arsenal から取得）はそのままレポートに記載し、出力／レスポンス（このスキルで処理）はスクリーンショットを撮る前に Cookie／PII を墨消しします。
• bb-methodology — フェーズ 5（検証とレポート）で証拠の記録が必要なときに使います。ワークフローの基本：レポートの作成前に、フェーズ 5 の証拠記録ステップでこのスキルを利用します。