Burp Suiteで学ぶWeb診断の基礎。自分の検証環境で安全に手を動かす

Webアプリケーションのセキュリティを学ぶうえで、避けて通れないのが「ブラウザとサーバーのあいだで実際に何がやり取りされているか」を自分の目で確かめる作業です。画面の見た目だけでは、どんなパラメータが送られ、どんなヘッダが返り、認可がどこで効いているのかは分かりません。この「見えない通信」を捕まえて、観察し、少しだけ書き換えて再送する。その一連の操作を一台で担うのが、Web診断の定番ツールであるBurp Suiteです。

この記事は、Burp Suiteをこれから触る開発者や診断の学習者に向けて、ProxyとRepeaterという二つの中核機能を軸に、ツールの原理と基本操作を解説します。派手な攻撃テクニックの紹介ではなく、「通信を観察し、仮説を立てて検証する」という診断の土台を、自分が管理する検証環境のうえで安全に身につけることを目的とします。なお、ここで扱う操作はすべて、自分の所有・管理する環境または明示的に許可された対象に対してのみ行うものです。許可のない実在サービスへの調査・攻撃は、不正アクセス禁止法をはじめとする法令や利用規約に違反するおそれがあり、決して行ってはいけません。この前提は本文中でも繰り返し確認します。

最初にお伝えしておきたいのは、Burp Suiteは「ボタンを押せば脆弱性が見つかる魔法の箱」ではないということです。本質はあくまで、人が通信を読み解くための観察と編集の道具です。だからこそ、ツールの操作以上に、HTTPの基本と「何を見るべきか」という観点が重要になります。

Burp Suiteとは何か。何ができる道具なのか#

Burp SuiteはPortSwigger社が開発するWebアプリケーション診断のための統合ツールです。中核にあるのは「インターセプトプロキシ」という仕組みで、ブラウザとサーバーのあいだに割り込んで、ブラウザ経由で行き来するHTTP/HTTPSの通信を手元で確認・編集できるようにします（HTTPSの傍受にはCA証明書の設定が必要で、証明書ピンニングを行うクライアントなどは別途対応が要ります）。

エディションは大きく無料のCommunity版と、有償のProfessional版に分かれます。学習や手動診断の入り口としては、Community版で十分に始められます。自動の脆弱性スキャナやレポート生成などはProfessional版の機能ですが、通信を観察し、手で書き換えて検証するという診断の根幹は、無料のCommunity版でも体験できます。

PortSwiggerの公式ドキュメントは、Proxy（通信の傍受）、Repeater（リクエストの手動再送）、Intruder（ペイロードの反復送信）、Target(サイトマップとスコープ管理)などを基本ツールとして紹介しています。自動スキャナ（Scanner）やレポート生成、Collaboratorなどは Professional 版の機能と明記されています。

Burp Suiteに含まれる主なツールを、入門時に押さえる順で整理すると次のようになります。実務でも学習でも、まずProxyとRepeaterに習熟することが出発点になります。

この表のとおり、Community版でも手動診断の主要な部品はそろっています。逆に言えば、無料版で学べないのは主に「自動化」と「レポート」の部分であり、原理を学ぶ段階では大きな支障になりません。

なぜプロキシで通信を見ると学びが深まるのか#

ブラウザの開発者ツールでもリクエストやレスポンスは見られます。それでもプロキシを使う価値があるのは、「通信を止めて、書き換えて、送り直せる」点にあります。開発者ツールにもリクエストの再送機能（FirefoxのEdit and Resendなど）はありますが、Burp Suiteのプロキシは通信の流れそのものに割り込み、サーバーに届く前のリクエストを止めて自由に編集できます。さらにProxy・履歴・Repeater・スコープ管理を一体で扱えるため、観察から検証までを連続した診断ワークフローとして回せる点に強みがあります。

ここが診断の本質に直結します。多くの脆弱性は、「ブラウザの画面では入力できない値」や「フロント側のJavaScriptが弾くはずの値」が、サーバーにそのまま届いたときに表面化します。たとえば、画面上は選べない他人のIDをパラメータに入れて送ったらどうなるか。隠しフィールドの金額を書き換えたらどうなるか。こうした検証は、サーバーに届く直前のリクエストを編集できて初めて成り立ちます。

つまり、プロキシは「クライアント側の制約を外して、サーバーの素の挙動を確かめる」ための道具です。フロントエンドのバリデーションは利便性のためのものであり、セキュリティの境界はあくまでサーバー側にある。この当たり前を体感できることが、プロキシで通信を扱う最大の学びです。

まず整える。安全な検証環境の作り方#

操作を始める前に、最も大切な準備が「対象を間違えない環境」を整えることです。Burp Suiteは強力な道具であり、向ける先を誤れば違法行為になりかねません。次の手順で、閉じた検証環境を用意します。

環境構築でつまずきやすいのが、HTTPSのページで証明書エラーが出る、あるいは通信がHistoryに出てこない、というケースです。前者はBurpのCA証明書がブラウザに信頼されていないことが原因で、後者はブラウザのプロキシ設定がBurpを向いていないか、インターセプトが「オン」のまま通信が止まっていることが多い、という当たりを付けると解決が早くなります。

Proxyの基本。通信を観察し、必要なときだけ止める#

Proxyの使い方には、大きく二つのモードがあります。一つは「すべての通信を記録しつつ素通しする」観察モード、もう一つは「リクエストを一つずつ止めて確認・編集する」インターセプトモードです。入門時に押さえたいのは、この二つを目的に応じて切り替えることです。

最初に慣れたいのは観察モードです。インターセプトを「オフ」にしておくと、通信は止まらずにそのまま流れ、その記録がHTTP historyに溜まっていきます。まずは検証用アプリを普通に操作し、historyに並ぶリクエストとレスポンスを眺めるところから始めましょう。どのページがどんなパラメータを送り、どんなCookieやヘッダをやり取りしているかが、一覧で見えてきます。

次に、特定のリクエストだけを止めたいときにインターセプトを「オン」にします。たとえば「ログインの送信ボタンを押した瞬間のリクエスト」を捕まえて、中身を確認・編集してから通すといった使い方です。ただし、インターセプトをオンにしたまま放置すると、ページの読み込みに必要な通信まで全部止まってしまい、「ブラウザが固まった」ように見えます。これは入門者が最もよく戸惑う点なので、普段はオフ、止めたいときだけオンにする、と覚えておくと快適です。

historyを観察するときに見るべきポイントは、CTFのWeb問題で観察する場所とほぼ共通です。具体的な観察の型は

Repeaterの基本。一発のリクエストを書き換えて再送する#

Proxyで「これは怪しい」と思ったリクエストが見つかったら、それをRepeaterに送ります。Repeaterは、一つのリクエストを手で自由に書き換えて、何度でも送り直し、レスポンスの違いを見比べるためのツールです。診断作業で最も使う機能と言ってよく、ここに習熟することが上達の近道です。

典型的な流れはこうです。Proxyのhistoryやインターセプト画面で対象のリクエストを右クリックし、「Send to Repeater」を選びます。Repeaterタブに移ると、そのリクエストの全文が編集可能な状態で表示されます。あとはパラメータやヘッダ、ボディの値を一箇所だけ書き換えて「Send」を押し、左にリクエスト、右にレスポンスが並ぶ画面で、変更前後の差を観察します。

この「一箇所だけ変えて差を見る」という進め方が決定的に重要です。一度に複数の値を変えてしまうと、どの変更が結果に効いたのか分からなくなります。仮説検証は、変える要素を一つに絞る。これは科学実験の基本と同じで、診断でもまったく同じ規律が効きます。

たとえば、自分の検証環境で次のような確認ができます。いずれも「サーバーがクライアントの値をどこまで信じているか」を見る観点です。

# 元のリクエスト（自分の検証環境のアプリに対して）
GET /account?id=1001 HTTP/1.1
Host: localhost:3000
Cookie: session=...

# Repeaterでidだけを書き換えて再送し、
# 他人のアカウント情報が返らないか（認可の不備=IDOR）を確認する
GET /account?id=1002 HTTP/1.1
Host: localhost:3000
Cookie: session=...

このように、画面上は操作できないパラメータをRepeaterで直接書き換え、サーバーの反応を見る。返ってきたレスポンスが他人のデータを含んでいれば、認可がクライアント側にしか無かった可能性を疑う、という具合に仮説を絞り込んでいきます。XSSのような入力起点の脆弱性を試す際も、Repeaterで入力値を変えながらレスポンスへの反映のされ方を観察するのが基本です。入力の扱いに関する基礎は

IntruderとDecoderの位置づけ。便利だが入門の主役ではない#

Intruderは、リクエストの特定箇所に多数の値を順に差し込んで反復送信するツールです。たとえばパラメータに用意したリストの値を次々に入れて、レスポンスの長さやステータスの違いを並べて観察する、といった使い方をします。便利ですが、Community版では送信速度に制限がかかります。入門段階では、まずRepeaterで「一発の挙動」を理解してから触れるのが順序として自然です。

Decoderは、URLエンコードやBase64、HTMLエンティティなどの変換を手早く行う補助ツールです。リクエストやレスポンスに現れる「読めない文字列」をデコードして中身を確かめたり、逆に送りたい値をエンコードして組み立てたりするのに使います。地味ですが、通信の中身を正確に読むうえで重宝します。

これらはあくまで観察と再送を補助する道具です。主役はProxyとRepeater、という優先順位を崩さないことが、入門時に遠回りしないコツです。自動化や反復送信に頼る前に、「一つのリクエストを完全に読み解けるか」を自分に問うようにしましょう。

法的・倫理的な前提を、もう一度確認する#

ここまで繰り返してきたとおり、Burp Suiteの操作は対象を選びます。日本では、アクセス制御がかかったコンピュータに対し、他人の識別符号を入力するなどして不正に利用する行為は、不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）で禁じられています。

総務省の国民向け解説によれば、不正アクセス禁止法はアクセス制御機能を持つ特定電子計算機に対する不正なアクセス行為を禁止しており、違反には罰則が定められています。許可のない他人のシステムへの調査・侵入は、たとえ「試すだけ」でも対象になり得ます。

実務でWeb診断を行う場合は、対象組織との契約や、対象範囲・禁止事項・実施時間などを定めた合意（いわゆるルール・オブ・エンゲージメント）が前提になります。バグバウンティに参加する場合も、各プログラムの規約と対象範囲（スコープ）を必ず読み、許可された範囲でのみ手を動かします。学習段階では、この「許可された範囲」を、自分のローカル環境や公式の学習ラボに限定するのが最も安全です。

PortSwiggerが提供するWeb Security Academyは、無料で利用できる学習ラボを備えており、安全かつ合法に攻撃手法と防御を試せる環境として案内されています。練習は、こうした許可された環境で行うのが原則です。

診断手法を体系的に学ぶ際は、OWASPのWeb Security Testing Guideのような公開資料が、テストの観点を網羅的に整理するうえで役立ちます。ツールの操作とあわせて、「何を確認すべきか」という診断の地図を持っておくと、闇雲な試行から抜け出せます。

よくある質問#

まとめ#

Burp Suiteは、Webの通信を観察し、書き換え、再送するための強力な道具です。しかし本質はツールの操作ではなく、「サーバーがクライアントの値をどこまで信じているか」を一つずつ確かめる、観察と仮説検証の規律にあります。許可された環境のうえで手を動かし、得た理解を必ず防御の設計に還元していきましょう。攻撃者の視点をつかむことは、自分のシステムの弱点に先回りして気づくための、最も確かな近道です。