メインコンテンツへスキップ
友田 陽大
ホワイトハッカー入門
セキュリティ
ホワイトハッカー
Burp Suite
脆弱性診断
倫理的ハッキング

Burp Suite 入門・実践ガイド【2026】Proxy・Repeater・Intruderで“合法に”Webを診断する — 公式ドキュメント忠実版

Web診断の世界標準ツール Burp Suite の使い方を、PortSwigger公式ドキュメントに忠実に解説。インターセプトプロキシの仕組み、Burp内蔵ブラウザのセットアップ、Target/Scopeで“許可範囲”を技術的に固定する方法、Repeaterでの手動検証(IDOR例)、Intruderの4攻撃タイプ(Sniper/Battering ram/Pitchfork/Cluster bomb)、Community版とProfessional版の正直な違い、そしてMontoya APIによる自作拡張のJavaコードまで、実リクエスト例とともに。すべて自分の資産・許可スコープ内で完結する合法な手順です。

公開日
読了時間
16分
著者
友田 陽大
シェア

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つの攻撃タイプです。§の数とペイロードセットの対応が、それぞれ全く違います。

攻撃タイプペイロードセット位置への入り方リクエスト数典型用途
Sniper1セット各位置に1つずつ順番に(他位置は元値)位置数 × ペイロード数1パラメータずつ個別にファジング
Battering ram1セット全位置に同じ値を同時投入ペイロード数同じ値を複数箇所に入れる攻撃
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、または用途特化のツール(ZAPffufsqlmap 等)と使い分けます。

倫理の再確認: 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周のレシピ

ツールが揃ったら、毎回考えずに回せるにします。

  1. スコープを固定(§2)— 対象だけをScopeに入れ、スコープ外を遮断。ここを飛ばさない。
  2. マッピング — 内蔵ブラウザでアプリを一通り操作し、Proxy > HTTP history / Target > Site mapに全通信を貯める(Interceptはオフ)。
  3. 当たりを付ける — historyから「認可が絡む」「入力をDBに渡す」「リダイレクトする」リクエストを探す。
  4. 手動検証(Repeater) — 怪しい1本をCtrl+R。IDの差し替え・トークン除去・メソッド変更で差分を観察
  5. 自動投入(Intruder) — 列挙・ファジングが要る箇所だけCtrl+I。攻撃タイプと件数を確認してから実行。
  6. (Pro)Scanner — 水平に網羅すべき注入・ヘッダ系を自動監査。
  7. 記録・報告 — 再現手順(リクエスト/レスポンス)を残す。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 で体に入れた人ほど、守る側として「どこが破れるか」を設計段階で見抜けます。 攻めと守りは同じコインの裏表——次はホワイトハッカーの仕事・年収・キャリアで、この力が市場でどう評価され、案件につながるかを解説します。


参考(公式一次情報)

友田

友田 陽大

経済産業大臣賞 受賞プロダクト開発者。TypeScript + Python + AWS で、SaaS・業界DX・ 実用レベルの生成AI(RAG)を、要件定義からインフラ・運用まで一人で完遂します。

この記事の対策、ツールで自動化できます

Next.js / Supabase のセキュリティ統制を、OSS の Aegis で自動化

この記事の対策の多くは、ミドルウェア1枚と静的解析で機械的に検出・強化できます。無料・MIT の Aegis なら、いまのプロジェクトを1コマンドからスキャンできます。設計が要る「縦のリスク」は監査でも承ります。

プロジェクト単位(請負)・技術顧問のどちらにも対応可能です。まずは30分の無料技術相談から。

あわせて読みたい