対象：セキュリティエンジニア・Webアプリ開発者・ペネトレーションテスター

第1章：Burp Suiteで「見るべき通信」の全体像

Burp Suiteは単なるプロキシツールではありません。WebアプリとブラウザのHTTP/HTTPS通信を完全に掌握し、その中に潜む脆弱性を発見するための精密機器です。しかし、すべての通信を闇雲に追っても効率が悪いだけです。「どの通信に着目するか」を理解することが、実践的な分析の第一歩です。

1-1. HTTPリクエストの構造を理解する
1-2. 「攻撃対象面（Attack Surface）」を意識する
2-1. HTTPメソッドに着目する
2-2. HTTPステータスコードで「異常」を発見する
2-3. レスポンスの中身：「情報漏洩」を見つける
3-1. Repeaterの基本ワークフロー
3-2. SQLインジェクション（SQLi）の確認手順
3-3. IDOR（水平型アクセス制御不備）の確認
3-4. JWT（JSON Web Token）の解析と改ざん
4-1. Intruderの4つのAttack Typeを理解する
4-2. Sniper で脆弱なパラメータを発見する
4-3. Intruderのペイロードセット活用
5-1. フィルタリングで「ノイズ」を排除する
5-2. Scopeの設定で対象を絞る
5-3. サイトマップでAPI設計を把握する
6-1. Webアプリ診断の標準フロー
6-2. よくある見落とし：「レスポンスヘッダー」の確認
6-3. 実践チェックリスト

1-1. HTTPリクエストの構造を理解する

まず、BurpがキャプチャするHTTPリクエストの構造を把握しましょう。1本のリクエストは以下の要素で構成されています。

# Burpで見えるリクエストのサンプル

POST /api/v1/login HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Content-Type: application/json

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

Cookie: session=abc123; csrftoken=xyz789

Content-Length: 47

{"username":"admin","password":"P@ssw0rd123"}

この1つのリクエストの中に、セキュリティ診断で注目すべきポイントが複数含まれています。リクエストメソッド（POST）、エンドポイントURL（/api/v1/login）、ヘッダー群（Authorization、Cookie）、そしてボディのJSON（username、password）です。

1-2. 「攻撃対象面（Attack Surface）」を意識する

セキュリティ診断において、攻撃者が狙えるポイントを「アタックサーフェス（攻撃対象面）」と言います。Burpで見るべき通信は、このアタックサーフェスを網羅することが目的です。

カテゴリ	注目ポイント	想定される脆弱性
URLパラメータ	?id=123 ?search=keyword	SQLi / パストラバーサル
リクエストボディ	JSON / フォームデータ	SQLi / XXE / コマンドインジェクション
認証ヘッダー	Authorization / Cookie	トークン改ざん / セッションハイジャック
ファイルアップロード	multipart/form-data	ファイルタイプ偽装 / WebShell
レスポンス	エラーメッセージ / デバッグ情報	情報漏洩 / スタックトレース
リダイレクト	Location ヘッダー	オープンリダイレクト

第2章：Proxy画面で「まず見るべき」通信

2-1. HTTPメソッドに着目する

リクエストのメソッド（GET/POST/PUT/DELETE等）は、そのリクエストの「意図」を示します。診断時はメソッドごとに見方を変えましょう。

■ GETリクエスト：URLパラメータを狙う

GETリクエストのパラメータはURLに直接含まれるため、改ざんが容易です。Burpのプロキシで以下のようなURLが流れてきたら要注意です。

GET /product?id=42 HTTP/1.1

GET /user/profile?uid=1001 HTTP/1.1

GET /search?q=laptop&category=electronics HTTP/1.1

これらの数値パラメータ（id=42、uid=1001）は、SQLインジェクションや水平型アクセス制御不備（IDOR）の候補です。「id=42」を「id=43」に変えた場合に他のユーザーのデータが見えるとすれば、それはIDOR（Insecure Direct Object Reference）という脆弱性です。

■ POSTリクエスト：ボディの中身を精査する

POSTリクエストのボディには機密データが含まれることが多く、診断の宝庫です。

POST /api/v2/transfer HTTP/1.1

Content-Type: application/json

{"from_account":"ACC001","to_account":"ACC999","amount":1000}

このような金融取引APIでは「amount」の値を改ざんした場合の動作確認、「from_account」を他人のものに変えた場合の制御確認などが重要です。

■ PUTリクエスト：権限昇格を疑う

REST APIでPUTは「リソースの更新」を意味します。ロールや権限に関わるフィールドが含まれていないか確認します。

PUT /api/users/1001 HTTP/1.1

{"name":"Alice","email":"alice@example.com","role":"user"}

「role」フィールドを「user」から「admin」に書き換えて送信した場合に権限昇格が起きれば、それは重大な脆弱性です。Burp Repeaterで確認します。

2-2. HTTPステータスコードで「異常」を発見する

Burp ProxyのHTTP historyを眺めるとき、レスポンスのステータスコードに着目するだけで多くのことがわかります。

ステータスコード	意味	診断での着眼点
200 OK	正常処理	エラーなのに200を返す「サイレントフェイル」に注意
302 Found	リダイレクト	Location先が外部URLならオープンリダイレクトの可能性
400 Bad Request	リクエスト不正	バリデーションが働いている証拠。回避できるか試す
401 Unauthorized	認証必要	認証なしで同じURLにアクセスできないか確認
403 Forbidden	アクセス禁止	別ユーザーのCookieで試すと通る場合がある（水平越権）
500 Internal Server Error	サーバーエラー	スタックトレースや内部情報が漏洩している可能性
503 Service Unavailable	サービス不能	負荷試験で意図せずDoSになっていないか確認

💡 診断のコツ：BurpのProxy→HTTP history画面で「Filter」ボタンをクリックし、ステータスコードやMIMEタイプで絞り込むと、大量の通信の中から注目すべきリクエストだけを素早く抽出できます。

2-3. レスポンスの中身：「情報漏洩」を見つける

攻撃の多くは「情報収集」から始まります。レスポンスボディに意図しない情報が含まれていないか確認することは非常に重要です。

■ エラーメッセージに含まれるスタックトレース

HTTP/1.1 500 Internal Server Error

{

  "error": "NullPointerException at com.example.app.UserService:142",

  "stackTrace": "java.lang.NullPointerException\n\tat com.example..."

}

このようなレスポンスは、サーバーの言語（Java）、パッケージ構造（com.example.app）、ファイル名、行番号を攻撃者に教えてしまいます。本番環境では絶対に出してはいけません。

■ APIレスポンスに含まれる過剰なフィールド

GET /api/v1/me HTTP/1.1 ← ログインユーザー自身の情報を取得するAPI

レスポンス：

{

  "id": 1001,

  "name": "Alice",

  "email": "alice@example.com",

  "role": "admin",          ← roleが見えてしまう

  "internal_notes": "...",  ← 内部メモが漏洩

  "password_hash": "$2b$10$..." ← ハッシュでも漏洩はNG！

}

このように、フロントエンドに表示しない情報であっても、APIレスポンスに含まれていれば攻撃者には丸見えです。Burpのレスポンス画面を丁寧に読むことで発見できます。

第3章：Repeaterを使った具体的な分析手法

3-1. Repeaterの基本ワークフロー

Burp RepeaterはキャプチャしたリクエストをGUI上で自由に編集して繰り返し送信できる機能です。脆弱性診断の「実験台」として最も多用されます。

① Proxyの「HTTP history」で気になるリクエストを右クリック
② 「Send to Repeater」を選択（ショートカット：Ctrl+R）
③ Repeaterタブに切り替え
④ リクエスト左ペインでパラメータを編集
⑤ 「Send」ボタンで送信
⑥ 右ペインでレスポンスを確認

3-2. SQLインジェクション（SQLi）の確認手順

SQLiはデータベースへの不正なSQL文を注入する攻撃です。Repeaterで段階的に試します。

ステップ1：正常リクエストで動作確認

GET /product?id=1 HTTP/1.1

→ 商品ID=1の情報が返ってくる（正常）

ステップ2：シングルクォートを挿入してエラーを誘発

GET /product?id=1' HTTP/1.1

→ SQLエラーが返れば、生のSQL文にパラメータが直接組み込まれている証拠

例：You have an error in your SQL syntax near ‘1”

ステップ3：コメント文字で残りのSQL文を無効化

GET /product?id=1'-- - HTTP/1.1

→ シングルクォートのエラーが消えたら、SQLiが成立している

ステップ4：UNION句でデータ抽出を試みる

GET /product?id=-1 UNION SELECT null,null,null-- - HTTP/1.1

→ nullの数をカラム数に合わせて調整

GET /product?id=-1 UNION SELECT username,password,null FROM users-- - HTTP/1.1

→ usersテーブルからデータを抽出できれば重大な脆弱性

⚠️ 上記手順は、必ず自分が管理するシステムまたはPortSwigger Web Security AcademyのようなCTF/学習環境でのみ実施してください。本番の他者サービスに対して実行することは不正アクセス禁止法違反です。

3-3. IDOR（水平型アクセス制御不備）の確認

IDORは「他のユーザーのリソースに自分のセッションでアクセスできてしまう」脆弱性です。Burp Suiteの「Authz」拡張機能や、手動でCookieを使い回すことで確認します。

確認手順：

ユーザーA（一般ユーザー）でログインし、自分のプロフィールAPIを傍受
GET /api/v1/users/1001/profile のリクエストをRepeaterに送る
URLの1001をユーザーBのID（例：1002）に変更して送信
ユーザーBの情報が返ってくれば、IDORが成立

# ユーザーAのリクエスト（正常）

GET /api/v1/users/1001/profile

Cookie: session=USER_A_SESSION_TOKEN

# IDORテスト：IDを1002に変えてユーザーAのセッションで送信

GET /api/v1/users/1002/profile

Cookie: session=USER_A_SESSION_TOKEN ← Aのセッションのまま

→ Bのプロフィールが返ってきたら脆弱性あり！

💡 IDORは非常に見つかりやすく、かつ深刻なOWASP Top 10の常連脆弱性（Broken Access Control）です。数値IDやUUIDをURLやパラメータで使っているAPIは必ず確認しましょう。

3-4. JWT（JSON Web Token）の解析と改ざん

現代のWebアプリはセッション管理にJWTを使うことが多くなっています。JWTはAuthorizationヘッダーやCookieに含まれ、Base64でエンコードされています。

JWTの構造（3つのパートに分かれている）:

eyJhbGciOiJIUzI1NiJ9  ← ヘッダー（Base64）

.eyJ1c2VyX2lkIjoxMDAxLCJyb2xlIjoidXNlciJ9  ← ペイロード（Base64）

.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← 署名

BurpでJWTを解析する手順：

① AuthorizationヘッダーのBearerトークンをコピー
② BurpのDecoder（またはhttps://jwt.io）でペイロードをBase64デコード
③ ペイロードの内容（role、user_id等）を確認
④ Burp拡張の「JWT Editor」（BApp Store から無料インストール）でトークンを改ざん

JWT Editor で確認すべき脆弱性：

{"alg":"HS256","typ":"JWT"}  ← algorithm を "none" に変えてみる

→ 「alg: none」を受け入れるサーバーは署名検証なし！無効なトークンでも認証される

{"user_id":1001,"role":"user"}  ← role を "admin" に変えてみる

→ 署名検証が弱い場合、ペイロードを書き換えても通ってしまう

✅ 確認方法：BApp Store（Burpの拡張マーケット）で「JWT Editor」を検索してインストール。リクエストを右クリック→「Send to JWT Editor」で改ざんが簡単に試せます。

第4章：Intruder（イントルーダー）で体系的に試す

4-1. Intruderの4つのAttack Typeを理解する

Burp Intruderはパラメータを自動的に変化させながら大量リクエストを送れる機能です。攻撃タイプによって用途が異なります。

タイプ	動作	主な用途
Sniper	1つの変数を変化させる	パラメータ1つのブルートフォース、ファジング
Battering ram	全変数に同じ値を適用	同じ値を複数フィールドに入れたい場合
Pitchfork	複数変数を対応させて変化	ユーザー名リストとパスワードリストを対応させる
Cluster bomb	全変数の組み合わせを試す	ユーザー名✕パスワードの全組み合わせ

4-2. Sniper で脆弱なパラメータを発見する

手順：パスワードリセットのトークン予測を確認する例

① パスワードリセットAPIのリクエストをProxyで傍受
② Intruderに送信（Ctrl+I）
③ 「Positions」タブでトークンの値を§マーカーで囲む
④ 「Payloads」タブで「Numbers」を選択し、連番や短い文字列を設定
⑤ 「Attack」で実行
⑥ レスポンスの文字数やステータスコードが他と違う行を探す

POST /api/v1/reset-password HTTP/1.1

{"token":"§AAAAAA§","new_password":"NewPass123!"}

→ §で囲んだ箇所にペイロードが順番に挿入される

💡 Community版のIntruderはレート制限（リクエスト間に遅延）がありますが、少数のペイロードを試すには十分です。Professional版は制限がなく高速です。

4-3. Intruderのペイロードセット活用

Intruderで効果的な診断をするには、適切なペイロードリストが重要です。

■ SQLiテスト用ペイロード（Sniper）

'

''

' OR '1'='1

' OR 1=1--

1; DROP TABLE users--

1' AND SLEEP(5)--  ← 時間ベースのブラインドSQLi検出

■ XSS（クロスサイトスクリプティング）テスト用ペイロード

<script>alert(1)</script>

<img src=x onerror=alert(1)>

"><script>alert(document.cookie)</script>

javascript:alert(1)

■ パストラバーサルテスト用ペイロード

../../../etc/passwd

....//....//....//etc/passwd

%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd  ← URLエンコード

✅ SecListsというオープンソースプロジェクト（https://github.com/danielmiessler/SecLists）には、セキュリティ診断用の膨大なペイロードリストが集まっています。Kali Linuxには /usr/share/seclists/ にデフォルト収録されています。

第5章：HTTP History の効率的な読み方

5-1. フィルタリングで「ノイズ」を排除する

実際の診断では、ブラウザが静的ファイル（画像、CSS、JS等）を大量に読み込みます。これらはセキュリティ上重要ではないことが多く、ノイズになります。Burpのフィルターを使って本質的な通信だけを見ましょう。

Proxy → HTTP history → Filter設定のポイント：

「Hide CSS」「Hide image and other binary」にチェック → 静的ファイルを除外
「Show only in-scope items」にチェック → 診断対象のドメインだけに絞る
MIMEタイプ「JSON」「XML」「HTML」にチェック → APIレスポンスを優先して確認

5-2. Scopeの設定で対象を絞る

BurpのScopeを設定すると、診断対象のドメインやURLパターンだけに絞って通信を記録できます。

「Target」タブ → 「Scope」サブタブを開く
「Add」ボタンからターゲットのURLを追加
例：https://example.com/* と入力すればexample.comのすべてのパスが対象
「Project options」でScope外の通信をProxyが傍受しないよう設定も可能

5-3. サイトマップでAPI設計を把握する

BurpのTarget → Site mapには、傍受したすべてのURLがツリー構造で表示されます。これを見るだけで、そのWebアプリのAPI設計（エンドポイント一覧）を把握できます。

Site mapで注目すべきポイント：

/admin/ や /internal/ など「管理系」エンドポイントが露出していないか
/api/v1/ と /api/v2/ が混在していないか（古いバージョンに脆弱性が残る場合がある）
/debug/ や /test/ など本番に残ったデバッグ用エンドポイントがないか
URLにユーザーIDやトークンが含まれる設計になっていないか（ログに残って危険）

💡 BurpのProxyが傍受した通信だけでなく、拡張の「Param Miner」を使うと、推測できる隠しパラメータを自動で探索してくれます。BApp Storeから無料でインストールできます。

第6章：実際の診断フローとチェックリスト

6-1. Webアプリ診断の標準フロー

実際のペネトレーションテストでBurp Suiteをどう使うか、標準的なフローをまとめます。

Phase 1：偵察（Reconnaissance）

サイトを手動でブラウズし、すべての機能を操作 → Burpにすべての通信を記録させる
Site mapを見てエンドポイント一覧を把握する
使われているフレームワーク・技術スタックをレスポンスヘッダーから読む

Server: nginx/1.18.0

X-Powered-By: PHP/8.1.2 ← バージョン情報が漏洩（本来は隠すべき）

Set-Cookie: PHPSESSID=xxx ← PHPのセッション（HttpOnly属性の有無を確認）

Phase 2：脆弱性探索

HTTP historyからAPIエンドポイントをすべてRepeaterに送り、パラメータを変化させる
認証が必要なエンドポイントに認証なしでアクセスを試みる
数値パラメータをすべてIDOR観点でチェックする
入力フィールドに特殊文字（’、<、”）を入力してエラーの有無を確認

Phase 3：脆弱性の検証と影響度評価

発見した脆弱性をRepeaterで再現性を確認する
CVSSスコアに基づいて深刻度を評価する（Critical/High/Medium/Low）
Burpの「Logger」で全リクエストをログとして保存し、証拠として提出する

6-2. よくある見落とし：「レスポンスヘッダー」の確認

脆弱性は入力パラメータだけでなく、HTTPレスポンスヘッダーにも現れます。以下はBurpのレスポンス画面で必ず確認すべきヘッダーです。

ヘッダー	あるべき設定	ない場合のリスク
Content-Security-Policy	スクリプト読み込み元を制限	XSS攻撃が成功しやすくなる
X-Frame-Options	DENY または SAMEORIGIN	クリックジャッキング攻撃
Strict-Transport-Security	max-age=31536000; includeSubDomains	HTTP通信へのダウングレード攻撃
X-Content-Type-Options	nosniff	MIMEスニッフィング攻撃
Set-Cookie	HttpOnly; Secure; SameSite=Strict	XSS/CSRF によるセッション窃取
Server / X-Powered-By	空白または削除	バージョン情報から既知脆弱性を利用される