Webアプリケーションのセキュリティ診断において、Burp Suiteはプロフェッショナルが最も信頼を寄せるツールのひとつです。

その中でも「Repeater」は、特定のHTTPリクエストを何度も再送信し、レスポンスの変化を詳細に観察するための極めて重要な機能です。

診断員はRepeaterを使用することで、ブラウザを介さずにリクエストパラメータを自在に操作し、脆弱性の有無を効率的に検証することが可能になります。

本記事では、Repeaterを用いたリクエスト改ざんの具体的な手順から、効率的な検証を行うための高度なテクニックまでを詳しく紹介します。

Burp Suite Repeaterの概要と基本的な役割

Burp SuiteのRepeaterは、キャプチャしたHTTPリクエストを一時的に保存し、その内容を手動で編集して再送するための機能です。

Proxy機能がブラウザとサーバ間の通信をリアルタイムで中継するのに対し、Repeaterは特定の通信を「切り出して」深掘りすることに特化しています。

Repeaterを使用する最大のメリット

Repeaterを使用する最大の利点は、ブラウザ側のJavaScriptによる制限や入力バリデーションを完全に無視できる点にあります。

通常、Webブラウザ上のフォームには文字数制限や型チェックが施されていますが、Repeaterで直接リクエストを送信すれば、これらの制限を容易にバイパスできます。

また、同じリクエストに対してパラメータを一箇所ずつ変更しながら試行錯誤できるため、脆弱性の特定精度が格段に向上します。

一度送信したリクエストの履歴がタブ形式で管理されるため、過去の検証結果との比較もスムーズに行えるのが特徴です。

Proxy機能とRepeaterの使い分け

Webアプリケーション全体の挙動を把握したり、画面遷移を追ったりする際にはProxy機能の「HTTP history」が適しています。

しかし、特定の入力項目にSQLインジェクションやクロスサイトスクリプティング(XSS)の脆弱性があるかを確認する場合は、Repeaterへ転送するのが一般的です。

Proxyで全ての通信をインターセプトして改ざんする方法もありますが、Repeaterの方が通信の試行回数を増やしても他の通信を妨げないため、効率的かつ安全に検証を進められます。

Repeaterの基本的な使い方と画面構成

まずは、ブラウザから送信されたリクエストをRepeaterに送る基本的な流れを理解しましょう。

リクエストをRepeaterへ転送する

Burp SuiteのProxyタブ内にある「HTTP history」から、検証対象のリクエストを右クリックします。

コンテキストメニューから「Send to Repeater」を選択するか、ショートカットキーのCtrl + R(Macの場合はCmd + R)を押下します。

すると、上部のRepeaterタブがオレンジ色に点灯し、リクエストがコピーされたことを知らせてくれます。

RequestパネルとResponseパネルの役割

Repeaterの画面は、大きく分けて左側の「Request」パネルと右側の「Response」パネルに分かれています。

Requestパネルでは、HTTPメソッド、URL、ヘッダー、ボディの内容を自由に変更することが可能です。

「Send」ボタンをクリックすると編集したリクエストがサーバへ送信され、その結果が即座にResponseパネルに表示されます。

Responseパネルでは、ステータスコードやレスポンスヘッダー、そして描画されたHTMLやJSONの内容を確認し、アプリケーションの挙動を分析します。

リクエスト改ざんによる脆弱性検証の手法

Repeaterの本領は、リクエストを自在に書き換えることで現れます。

ここでは、代表的な改ざん手法とその検証目的について解説します。

パラメータ操作による入力値チェックの検証

最も基本的な検証は、GETパラメータやPOSTボディ内の値を書き換えることです。

例えば、ユーザーIDを指定するパラメータがid=101となっている場合、これをid=102に変更して送信してみます。

もし自分以外のユーザー情報が表示された場合、それは不適切な直接オブジェクト参照(IDOR)という脆弱性が存在することを示唆しています。

また、数値が期待されている場所にシングルクォート(’)を挿入し、レスポンスにデータベースエラーが含まれないかを確認することで、SQLインジェクションの足がかりを掴むことができます。

HTTP
POST /api/user/profile HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

user_id=101' OR '1'='1

HTTPヘッダーの操作と認証認可のテスト

Repeaterではボディだけでなく、HTTPヘッダーも自由に編集できます。

User-Agentヘッダーを書き換えて、モバイル端末や特定のブラウザを装った際の挙動の違いを調査できます。

特に重要なのが、認証に関連するCookieヘッダーやAuthorizationヘッダーの検証です。

セッションクッキーの一部を意図的に削除したり、他人のトークンに差し替えたりすることで、認可制御が正しく行われているかを厳密にチェックします。

また、X-Forwarded-Forヘッダーを付与して、IPアドレス制限をバイパスできるかどうかを試すことも、ネットワーク境界の検証において有効です。

HTTPメソッドの変更(動詞の改ざん)

Webアプリケーションの中には、特定の処理に対してGETやPOST以外のメソッドを受け付けるものがあります。

Repeater上でリクエスト行を右クリックし、「Change HTTP method」を選択することで、GETからPOSTへの変換、あるいはその逆を簡単に行えます。

例えば、本来POSTでしか受け付けないはずの更新処理が、GETメソッドでも実行可能である場合、CSRF(クロスサイトリクエストフォージェリ)攻撃の脆弱性を高める要因となります。

さらに、PUTやDELETEといったメソッドを試すことで、本来許可されていないファイル操作が可能かどうかも検証の対象となります。

効率的な検証のためのRepeater活用テクニック

Repeaterには、単にリクエストを送信するだけでなく、作業を効率化するための便利な機能が多数備わっています。

タブの管理とグループ化

検証を進めていくと、Repeaterのタブが数十個に増えてしまうことがよくあります。

最新のBurp Suiteでは、タブを右クリックして「Add tab to group」を選択することで、関連するリクエストを色分けしてグループ化できます。

「ログイン関連」「商品検索関連」「決済処理関連」のようにカテゴリ分けをすることで、複雑な診断対象でも混乱することなく作業を継続できます。

Inspectorパネルの活用による効率化

画面の右側に表示される「Inspector」パネルは、リクエストの内容を構造的に把握するのに非常に役立ちます。

URLデコードやHTMLエンコードが必要な複雑な文字列も、Inspector上で直接編集すれば、自動的に適切なエンコード処理を施してリクエストに反映してくれます。

バイナリデータや長大なBase64文字列が含まれる場合でも、このパネルを使えば人間に読みやすい形式で値を操作することが可能です。

レスポンスのレンダリング確認

Responseパネルの下部にある「Render」タブを使用すると、サーバから返ってきたHTMLを簡易的にブラウザ表示した状態で確認できます。

XSSの検証において、スクリプトがページ内のどの位置に挿入されたかを目視で素早く確認する際に便利です。

ただし、JavaScriptの実行までは完全には再現されないため、動的な挙動についてはブラウザでの確認と併用するのがベストです。

Repeater使用時の比較表

検証の目的によって、Repeaterのどの機能を重視すべきかを以下の表にまとめました。

検証カテゴリ主な操作対象Repeaterでのポイント
認証・認可の検証Cookie, Authorizationヘッダートークンの削除や置換を行い、401/403エラーが出るか確認。
入力値バリデーションPOSTパラメータ, JSONキー境界値や不正な型を送信し、エラーハンドリングを確認。
インジェクション系全入力パラメータ特殊文字を挿入し、レスポンスの遅延や内容変化を詳細に分析。
ビジネスロジック価格, 数量, ステータス本来変更できないはずの値を書き換え、処理が通るか確認。

検証における注意点とトラブルシューティング

Repeaterを用いた検証を行う際には、いくつか注意すべき技術的・倫理的なポイントがあります。

セッション切れとタイムアウトへの対応

Repeaterで同じリクエストを何度も再送しているうちに、サーバ側のセッションがタイムアウトしてしまうことがあります。

その場合、どれだけパラメータを書き換えても「ログイン画面へリダイレクトされる」といった同様のレスポンスしか返ってこなくなります。

このような時は、再度ブラウザでログインし直して最新のセッションクッキーを取得し、Repeater内のヘッダーを更新する必要があります。

Burpの「Session Handling Rules」を設定すれば、セッションが切れた際に自動で再ログインするよう自動化することも可能ですが、まずは手動での更新に慣れておくことが大切です。

コンテンツ長(Content-Length)の整合性

リクエストボディを手動で書き換えた場合、Content-Lengthヘッダーの値が実際の内容と乖離してしまうことがあります。

値が正しくないと、サーバ側でリクエストが途中で切断されたり、逆にタイムアウトまで待機されたりする原因となります。

Repeaterには「Update Content-Length automatically」という設定がデフォルトで有効になっており、基本的には自動調整されますが、手動でヘッダーをいじる際は意識しておきましょう。

法的な注意点と倫理的な責任

Repeaterによるリクエスト改ざんは非常に強力な攻撃手法そのものです。

必ず自身が管理する環境、もしくは明示的に診断許可を得たターゲットに対してのみ実行してください。

許可なく他者のシステムに対してリクエストを改ざんして送信する行為は、不正アクセス禁止法などの法令に抵触する恐れがあります。

技術の習得には、OWASP Juice Shopのような脆弱性学習用の意図的に作り込まれた環境を利用することを強く推奨します。

まとめ

Burp SuiteのRepeaterは、Webアプリケーション診断の核心部を担う非常に強力なツールです。

リクエストを自由に改ざんし、再送信することで、ブラウザ経由では見えてこないサーバ側の処理の不備を浮き彫りにすることができます。

基本的な操作に慣れた後は、Inspectorパネルの活用やタブのグループ化を駆使して、より高度で効率的な検証を目指しましょう。

正確なリクエスト操作と緻密なレスポンス分析こそが、高品質なセキュリティ診断を実現するための第一歩となります。