Webアプリの脆弱性診断を学ぶとき、ほぼ全員が最初に手にするツールが Burp Suite です。バグバウンティでも、商用のペネトレーションテストでも、事実上の世界標準。本記事は、その Burp Suite を PortSwigger公式ドキュメントに忠実に、しかし公式より噛み砕いて、実際のリクエスト例とコードつきで解説します。
ただし、最初に一線を引きます。Burp Suite は強力すぎる道具です。 向ける先を1つ間違えれば、学習が犯罪に変わります。本記事のすべての操作は、ホワイトハッカーと法律で定めた**3つの安全地帯(①自分の資産 ②CTF ③書面で許可されたスコープ)**の中で完結します。柵の外には一歩も出ません。
これはホワイトハッカーの独学ロードマップで「自分のlabのプロキシ解析に使う」と紹介した Burp Suite を、ツール単体で深掘りするスポークです。練習対象には、同記事で構築した localhost限定の OWASP Juice Shop を使う前提で進めます。
1. Burp Suite とは何か — “インターセプトプロキシ”の正体
Burp Suite の中核は、たった1つの発想です。あなたのブラウザとWebサーバーの「間」に割り込む。
[ブラウザ] ⇄ 🛡️ Burp Proxy(ここで止めて読む・書き換える)⇄ [Webサーバー]
通常、ブラウザが送るHTTPリクエストは一瞬でサーバーに飛んでいきます。Burp はこれを途中で握り(intercept)、人間が読める形で停止させます。あなたは中身を観察し、書き換え、再送できる。
なぜこれが決定的か。ブラウザのUIは「正規の操作」しかさせてくれないからです。<select> に無い値、送信ボタンが押せない不正な組み合わせ、隠しフィールドの改ざん、他人のIDへの差し替え——画面では不可能な入力を、Burp はプロトコルの層で自由に作れます。脆弱性の多くは、まさにこの「想定外の入力」に潜んでいます。
公式のGetting Startedも、この Proxy → 改ざん → 再送 → 解析 の流れを軸に構成されています。本記事もその順でなぞります。
2. 【最重要】手を動かす前に — Scopeで“許可”を技術的に固定する
多くの入門記事はここを飛ばしますが、プロ(と、捕まらないホワイトハッカー)は逆に、ここから始めます。
法律上、合法/違法を分けるのは技術ではなく 「許可(スコープ)」 です。バグバウンティならプログラムが定めたスコープ、業務診断なら契約書のスコープ。この「許可された対象だけ」を、Burpの設定として固定します。 うっかり対象外(CDN、外部解析、第三者API…)にリクエストを飛ばす事故を、構造的に防ぐためです。
Burp の Target > Scope に、対象だけを登録します。
# 含める(In scope)— 自分の練習labだけ
http://127.0.0.1:3000/ ← localhostのJuice Shopのみ
# 除外(Exclude from scope)— ログアウトや破壊的操作を誤爆しない
http://127.0.0.1:3000/logout
設定したら、必ず 「Proxy intercepts out-of-scope items(スコープ外は握らない)」 系のフィルタを有効化し、各ツールを "In scope items only" に絞ります。これで Burp はスコープ外の通信を表示・処理しなくなり、視界がノイズで埋まらず、かつ範囲外への手出しを技術的に抑止できます。
設計思想として: 「気をつける」を運用の注意力に頼らず、設定(コード)で不可能にする。 これは決済の二重課金を“注意”ではなく冪等性で防ぐのと同じ発想です。許可の境界も、人間の集中力ではなくツールの制約で守りましょう。
3. セットアップ — Community版とProfessional版の“正直な”違い
Burp Suite にはエディションがあります。誇張なく、何ができて何ができないかを正直に並べます。
| 機能 | Community(無料) | Professional(有料) |
|---|---|---|
| Proxy(インターセプト) | ✅ | ✅ |
| Repeater(手動再送) | ✅ | ✅ |
| Intruder(自動投入) | ⚠️ 速度制限あり(デモ用スロットル) | ✅ フル速度 |
| Target / Site map / Scope | ✅ | ✅ |
| Decoder / Comparer / Sequencer | ✅ | ✅ |
| Burp内蔵ブラウザ | ✅ | ✅ |
| Scanner(自動脆弱性診断) | ❌ | ✅【Pro専用】 |
| Burp Collaborator(OOB検出) | ❌(公式インスタンス利用は制限) | ✅【Pro専用】 |
| プロジェクトの保存 | ❌ 一時プロジェクトのみ | ✅ ディスク保存 |
| レポート出力 | ❌ | ✅【Pro専用】 |
結論: 学習と手動検証は Community で十分始められます。Web Security Academy のラボも Community で解けます。一方、Scannerによる自動診断・大量反復・成果物のレポート化が要る本番のプロ診断は Professional が前提です。本記事のハンズオンは、Community で完結します。
Burp内蔵ブラウザを使う(プロキシ設定で消耗しない)
昔は「ブラウザのプロキシをBurpに向け、自己署名CA証明書をインストールして…」という面倒があり、初学者の最初の壁でした。今は不要です。 Burp は 内蔵ブラウザ(Burp's browser) を同梱しており、プロキシもCA証明書も最初から設定済み。HTTPSサイトも追加設定なしで握れます。
Proxy > Intercept タブの "Open Browser" を押すだけ。ここで開いたタブの通信が、そのまま Burp を通ります。まずこれで始めてください。 外部ブラウザ+証明書のセットアップは、必要になってからで構いません。
4. Proxy — 通信を“止めて読む”
セットアップが済んだら、最初のインターセプトです。make up で合法labのJuice Shopを起動し、内蔵ブラウザで http://127.0.0.1:3000 を開きます。
Proxy > Intercept で "Intercept is on" にして、ログイン操作をすると、Burp がリクエストを握って停止します。生のHTTPがこう見えます。
POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
Content-Length: 52
{"email":"test@example.com","password":"password123"}
ここでの操作は3つだけ。
- Forward:このリクエストを(必要なら書き換えてから)サーバーへ流す
- Drop:このリクエストを破棄して送らない
- Action > Send to ...:他のツール(Repeater / Intruder)へ送る
公式のModifying requestsが示す通り、Forwardの前に本文を書き換えれば、UIでは送れない値をサーバーに届けられます。たとえば上の email を ' OR 1=1-- に変えて送る、といった検証はここで行います。
ただし Intercept を常時オンにすると、画像やAPIのたびに止まって鬱陶しい。実務では Intercept は普段オフにして全通信を Proxy > HTTP history に記録させ、怪しい1本を見つけたら Repeater / Intruder に送る、という流れが基本です。
5. Repeater — 1リクエストを“手で”精密検証する(IDORの実例)
Repeater は、1本のリクエストを編集 → 再送 → レスポンス確認、を何度でも繰り返すツールです。手動の脆弱性検証の主戦場であり、特に**認可の不備(IDOR)**の確認に最適です。
HTTP history で「自分の注文を見る」リクエストを見つけ、右クリック > Send to Repeater(Ctrl+R)。Repeater タブでこう編集します。
GET /api/orders/1023 HTTP/1.1 ← 1023 は“自分の”注文ID
Host: 127.0.0.1:3000
Authorization: Bearer eyJhbGciOi... ← 自分のトークンのまま
1023 を **1024(他人の注文ID)**に書き換えて Send。ここでレスポンスがこう返ったら——
HTTP/1.1 200 OK
Content-Type: application/json
{"id":1024,"userId":42,"items":[...],"total":12800}
自分のトークンのまま、他人(userId:42)の注文が見えてしまった。 これが典型的な IDOR(Insecure Direct Object Reference)= アクセス制御の不備で、OWASP Top 10:2025 でも **A01「アクセス制御の不備」**として依然1位の最頻出カテゴリです。
Repeater の強みは、1リクエストを軸に「条件を1つだけ変えて」挙動の差分を観察できること。トークンを外したら? IDを 0 や -1 にしたら? メソッドを DELETE にしたら?——この仮説 → 1変数だけ変更 → 再送 → 差分観察の反復が、診断の核です。
このIDOR、攻める側の検証はRepeaterで一瞬ですが、守る側で“設計から”潰すのは別の難しさがあります。サーバー側の所有者チェックやRLSをどう堅牢化するかは、Next.js × Supabase のIDOR/認可不備をどう検出するかで解説しています。攻撃の理解と防御の設計は、同じコインの裏表です。
6. Intruder — 同じ位置に“大量のペイロード”を自動投入する
Intruder は、1つのリクエストの「指定位置」に、ペイロード(候補値)を次々入れ替えて自動送信するツールです。総当たり・ファジング・ユーザー列挙などに使います。
リクエストを **Send to Intruder(Ctrl+I)**し、ペイロードを入れたい箇所を §マーカーで囲みます。
POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
{"email":"§admin@juice-sh.op§","password":"§password§"}
ここで決定的に重要なのが、公式が定める4つの攻撃タイプです。§の数とペイロードセットの対応が、それぞれ全く違います。
| 攻撃タイプ | ペイロードセット | 位置への入り方 | リクエスト数 | 典型用途 |
|---|---|---|---|---|
| Sniper | 1セット | 各位置に1つずつ順番に(他位置は元値) | 位置数 × ペイロード数 | 1パラメータずつ個別にファジング |
| Battering ram | 1セット | 全位置に同じ値を同時投入 | ペイロード数 | 同じ値を複数箇所に入れる攻撃 |
| Pitchfork | 位置ごとに別セット | 各セットを並行に1つずつ(zip的) | 最小セットの要素数 | 関連する値の組(user/token対)を順に試す |
| Cluster bomb | 位置ごとに別セット | 全組み合わせを総当たり | 各セットの積(爆発的) | 無関係な値の総当たり(user × pass) |
選び方の勘所:
- 1箇所だけを試す(例:パスワードリスト攻撃で
password位置のみ)→ Sniper - 2箇所に同じ値(例:同じトークンをヘッダとボディに)→ Battering ram
- 対応する組(例:流出した
user1:passA,user2:passBをそのまま)→ Pitchfork - 総当たり(例:ユーザー10 × パスワード100 = 1,000通り全部)→ Cluster bomb
Cluster bomb は組み合わせ数が 積になるため、100 × 100 = 10,000 のように簡単に爆発します。ペイロード数を必ず見積もってから走らせてください。
⚠️ Community版のIntruderは“わざと遅い”
ここは公式情報として正直に。Burp Suite Community Edition の Intruder は、デモ目的で速度が制限(スロットル)されています。 リクエスト間に遅延が入り、大量試行を現実的な時間で回すのには向きません(PortSwigger公式フォーラムでも明言)。フル速度の自動攻撃は Professional版が前提です。
学習目的なら、**少数のペイロードで「攻撃タイプの挙動を理解する」**用途には Community でも十分使えます。総当たりの実戦は Pro、または用途特化のツール(ZAP や ffuf、sqlmap 等)と使い分けます。
倫理の再確認: Intruder は認証への総当たりを容易にします。これを他人のサイトに向ければ、それは攻撃そのものであり、不正アクセス禁止法に直結します。向けてよいのは自分のlab・CTF・書面で許可されたスコープだけ。§の数を間違えるより、向ける先を間違える方が、はるかに重大です。
7. Scanner と周辺ツール — 何が自動化でき、何ができないか
**Burp Scanner【Professional専用】**は、クロール(サイト探索)と監査(脆弱性検出)を自動化します。XSS・SQLi・各種ヘッダ不備などを機械的に洗い出し、再現手順つきで報告します。ただしこれは“水平に網羅できる脆弱性”の話です。
ここに、本ブログが一貫して主張する線引きがあります。
- 自動化できる(水平統制): XSS・SQLi・ヘッダ不備・既知パターンの注入——ツールが網羅検出できる。ScannerやZAP、SAST/DASTの土俵。
- 自動化できない(垂直リスク): IDOR・認可ロジックの正しさ・テナント越境・業務ルールの破れ——ツールは「IDを変えたら200が返った」と気づけても、「それが仕様違反かどうか」は人間の業務理解でしか判断できない。
だから Burp は Scanner(網羅)と Repeater(人間の判断) の両方を持っています。Community でも Repeater による垂直リスクの手動検証は完全にできる——ここが、無料でも学習価値が高い理由です。
その他、覚えておくと良い周辺ツール(多くはCommunityでも利用可):
- Inspector — リクエスト/レスポンスを構造化して読む(ヘッダ・パラメータを整形表示)
- Decoder / Comparer — エンコード変換、2レスポンスの差分比較
- Sequencer — セッショントークンの乱数性を統計分析(予測可能なら重大)
- DOM Invader — ブラウザ内蔵でDOM-based XSSの発見を補助
8. 【拡張】Montoya APIで“自分専用チェッカー”を作る(実コード)
Burp の真価は拡張性にあります。公式の現行API **Montoya API(Java)**を使えば、全通信を横断する自分専用の検査ロジックを数十行で書けます(古い IBurpExtender 系APIは非推奨・メンテ停止済み。新規はMontoya一択です)。
ここでは**「全レスポンスを監視し、セキュリティヘッダの欠落を自動で警告する」拡張**を作ります。診断のたびに目視確認していた項目を、一度コードに畳み込めば二度と忘れない——これはまさにDRYです。
8.1 エントリポイント
Montoya拡張は BurpExtension を実装し、initialize でツールを登録します。
// SecurityHeaderExtension.java
package com.example.burp;
import burp.api.montoya.BurpExtension;
import burp.api.montoya.MontoyaApi;
/**
* 拡張のエントリポイント。Burpが起動時に initialize を1度だけ呼ぶ。
* ここで「全HTTP通信を見るハンドラ」を登録する。
*/
public class SecurityHeaderExtension implements BurpExtension {
@Override
public void initialize(MontoyaApi api) {
api.extension().setName("Security Header Auditor");
// HTTPハンドラを登録:以後、Burpを通る全リクエスト/レスポンスがここを通過する
api.http().registerHttpHandler(new SecurityHeaderHandler(api));
api.logging().logToOutput("Security Header Auditor: 有効化しました");
}
}
8.2 レスポンスを横断検査するハンドラ
HttpHandler を実装すると、リクエスト送信前とレスポンス受信後にフックできます。ここではレスポンス側で、重要なセキュリティヘッダの有無を点検します。
// SecurityHeaderHandler.java
package com.example.burp;
import burp.api.montoya.MontoyaApi;
import burp.api.montoya.http.handler.*;
import java.util.List;
/**
* 全レスポンスを監視し、欠落しているセキュリティヘッダを Output に列挙する。
* 検査ロジックを1か所に集約(SRP)。判定基準を増やすのはこのクラスだけで済む(ETC)。
*/
class SecurityHeaderHandler implements HttpHandler {
// 「最低限あるべき」ヘッダ。判定基準の単一の真実源(DRY)。
private static final List<String> REQUIRED = List.of(
"Content-Security-Policy",
"Strict-Transport-Security",
"X-Content-Type-Options",
"X-Frame-Options"
);
private final MontoyaApi api;
SecurityHeaderHandler(MontoyaApi api) {
this.api = api;
}
// リクエストは素通し(今回は改ざんしない)
@Override
public RequestToBeSentAction handleHttpRequestToBeSent(HttpRequestToBeSent req) {
return RequestToBeSentAction.continueWith(req);
}
// レスポンス受信時に欠落ヘッダを検査
@Override
public ResponseReceivedAction handleHttpResponseReceived(HttpResponseReceived res) {
// hasHeader はヘッダ名を大文字小文字区別なく判定する(公式API)
List<String> missing = REQUIRED.stream()
.filter(h -> !res.hasHeader(h))
.toList();
if (!missing.isEmpty()) {
// どのURLで何が欠けているかを Output に出す(後でまとめてレポート化できる)
api.logging().logToOutput(
"[欠落] " + res.initiatingRequest().url() + " → " + String.join(", ", missing)
);
}
// レスポンスはそのまま流す(観察に徹し、通信は壊さない=冪等・非破壊)
return ResponseReceivedAction.continueWith(res);
}
}
8.3 ビルドして読み込む
Kotlin/Java を .jar にビルドし、Extensions タブ > Add で読み込むだけ。以後、Burpを通る全レスポンスが自動で検査され、ヘッダが欠けたエンドポイントが Output に積み上がります。
# 例:Gradleでfat-jarを生成し、BurpのExtensionsタブから.jarを追加する
./gradlew jar
# → build/libs/security-header-auditor.jar を Burp の Extensions > Add で読み込む
応用の発想: この「全通信を横断し、自分の基準で機械チェックする」型は、そのまま継続的なセキュリティ統制に発展します。診断時だけBurpで見るのではなく、同じ検査をCIに常駐させれば、ヘッダ欠落はマージ前に止められる。手動診断で得た知見を、コード化 → 自動化 → CIに常駐と昇華させるのが、本番運用に効く考え方です。PortSwigger は拡張開発のスターターに
CLAUDE.md(LLM向けの開発コンテキスト)まで同梱しており、生成AIで拡張を書くのも現実的な選択肢になっています。
9. 実務の“型” — 診断1周のレシピ
ツールが揃ったら、毎回考えずに回せる型にします。
- スコープを固定(§2)— 対象だけをScopeに入れ、スコープ外を遮断。ここを飛ばさない。
- マッピング — 内蔵ブラウザでアプリを一通り操作し、Proxy > HTTP history / Target > Site mapに全通信を貯める(Interceptはオフ)。
- 当たりを付ける — historyから「認可が絡む」「入力をDBに渡す」「リダイレクトする」リクエストを探す。
- 手動検証(Repeater) — 怪しい1本を
Ctrl+R。IDの差し替え・トークン除去・メソッド変更で差分を観察。 - 自動投入(Intruder) — 列挙・ファジングが要る箇所だけ
Ctrl+I。攻撃タイプと件数を確認してから実行。 - (Pro)Scanner — 水平に網羅すべき注入・ヘッダ系を自動監査。
- 記録・報告 — 再現手順(リクエスト/レスポンス)を残す。OSSや自作拡張で機械チェックも併走。
この型は、ZAPを使ったSAST/DAST診断とも共通です。ツールが変わっても、観察→仮説→検証→記録の骨格は同じ。Burp/ZAPの機能差や使い分けはスキャナ比較ガイドを参照してください。
10. まとめ — 道具の強さは、向ける先の正しさで決まる
- Burpの正体は割り込みプロキシ:通信を止めて読み・書き換え・再送する。UIでは作れない入力を、プロトコルの層で自由に作れる。
- 手を動かす前にScope:許可された対象だけをScopeに固定し、スコープ外を遮断する。“許可”を設定で固定してから始める。
- 役割で使い分け:Proxy(観察)→ Repeater(手動の精密検証=IDORに最適)→ Intruder(4タイプの自動投入)。Scannerは網羅、Repeaterは判断。
- Community/Proの正直な線引き:手動検証と学習はCommunityで完結。自動診断・大量反復・レポートはPro。
- Montoya APIで自分の基準をコード化:診断の知見をHttpHandlerに畳み込み、CIまで延ばせば本番統制になる。
Burp Suite は、攻撃者の道具であると同時に、**最も多くを学べる“防御者の顕微鏡”**です。攻撃の手筋を Repeater で体に入れた人ほど、守る側として「どこが破れるか」を設計段階で見抜けます。 攻めと守りは同じコインの裏表——次はホワイトハッカーの仕事・年収・キャリアで、この力が市場でどう評価され、案件につながるかを解説します。