なぜBurp Suiteが開発者のツールキットに必要なのか
私にとってセキュリティが単なる理論上の「チェックボックス」ではなくなったのは、ある火曜日の午前3時のことでした。サーバーログが、単一のボットネットからの1万回を超えるSSHログイン試行で埋め尽くされるのを目撃したのです。この事件は、私のワークフローを永遠に変えました。今では、ユニットテストをパスしたからといってコードが安全だと思い込むことはありません。誰かに悪用される前に、Burp Suiteを使って自らロジックの穴を探すようにしています。
Burp Suite Community Editionは、インターセプティングプロキシ（割り込みプロキシ）のゴールドスタンダードです。ブラウザとサーバーの間に置かれた透明な壁だと考えてください。ウェブトラフィックを途中で一時停止し、内容を確認し、さらには書き換えることさえ可能です。プロフェッショナル版は自動スキャン機能に年間449ドルかかりますが、無料のCommunity版でも、どのレバーを操作すべきかを知っていれば、手動監査において非常に強力なツールになります。
5分で完了するBurp Suiteのセットアップ
インターセプト環境の構築は、多くの人が躓くポイントです。大抵は証明書の問題です。以下の手順に従って、一回で正しく設定しましょう。
1. プロキシの設定
Burpを開き、ProxyタブからProxy Settingsに進みます。リスナーが127.0.0.1:8080でアクティブであることを確認してください。システム全体のプロキシ設定を変更するのは面倒なので避けましょう。代わりに、FirefoxにFoxyProxy Standard拡張機能をインストールします。ポート8080を使用するBurp用の新しいプロファイルを作成してください。これにより、2回のクリックでインターセプトのオン/オフを切り替えられるようになります。
2. CA証明書のインストール
今日、ほとんどすべてのサイトがHTTPSを使用しています。Burpのルート証明書がないと、ブラウザは大規模なセキュリティ警告を表示し、接続をブロックします。プロキシをオンにした状態でhttp://burpにアクセスしてください。CA Certificateをクリックしてファイルをダウンロードします。次に、ブラウザの証明書マネージャーを開き、インポートします。「この認証局によるウェブサイトの識別を信頼する」というチェックボックスを必ずオンにしてください。
3. 最初のリクエストをキャッチする
Proxy -> Interceptタブに切り替え、Intercept is onになっていることを確認します。適当なウェブサイトを更新してください。リクエストが一時停止し、Burpの中に表示されます。Forwardを押してリクエストを送信するか、Dropを押してサーバーに届く前に破棄することができます。
一般的なバグの実践テスト
ここでは、影響の大きい3つの脆弱性に焦点を当てます。これらはBurpのRepeaterツールに最適です。Repeaterを使えば、ブラウザを操作することなく、単一のリクエストを異なるペイロードで何度も再送信できます。
1. 反射型クロスサイトスクリプティング (XSS)
XSSは、アプリケーションがユーザー入力をサニタイズ（浄化）せずにそのまま画面に表示（エコー）したときに発生します。検索バー、?query=のようなURLパラメータ、またはカスタムエラーメッセージを探しましょう。
- 検索フィールドを見つけ、
FIND_ME_123のようなユニークな文字列を入力します。 - BurpのHTTP Historyで、その
GETリクエストを探します。 Ctrl+Rを押して、Repeaterに送信します。- Repeaterで、
FIND_ME_123を<script>alert('XSS')</script>に置き換えます。 - Sendをクリックします。レスポンスペインに、入力した通りのスクリプトタグが表示されれば、脆弱性が見つかったことになります。もし
<script>のように表示されていれば、開発者が適切に入力をサニタイズしているということです。
2. SQLインジェクション (SQLi)
SQLインジェクション (SQLi)は、依然としてデータベースに対する最大の脅威の一つです。私はいつも、product_id=101やcat=5のようにデータベースのキーに見えるパラメータを探します。モダンなフレームワークであっても、開発者が「手っ取り早い修正」のために生のクエリ（raw query）を使用していれば、脆弱になる可能性があります。
基本的なSQLiをテストするには、リクエストをRepeaterに送り、値にシングルクォート（'）を追加します：
GET /api/products?id=101' HTTP/1.1
Host: example.com500 Internal Server Errorや、”MySQL”、”PostgreSQL”に言及するメッセージが表示されたら、それは重大な危険信号です。クォートによってデータベースクエリが壊れたことを意味します。確認のために、論理テストを試してください。id=101 AND 1=1でページが正常に読み込まれ、id=101 AND 1=2でエラーや空のページが返される場合、データベースは注入したコードを実行しています。
3. 不適切な直接オブジェクト参照 (IDOR)
IDORは、スキャナーが見落としがちなロジックの欠陥です。アプリケーションが、アクセスするレコードの指定をユーザーに任せきりにしている場合に発生します。例えば、自分の請求書を/billing/view?id=5001で閲覧しているとします。
- 請求書へのリクエストをインターセプトします。
- それをRepeaterに送信します。
- IDを
5001から5000や4999に変更します。 - Sendをクリックします。
もしサーバーが他人の請求書データを返してきたら、それは深刻なIDORです。私は「プロフィールの更新」や「PDFのダウンロード」ボタンでこれを必ずチェックします。開発者は、ログイン中のユーザーが要求されたIDの所有者であるかどうかを確認し忘れることがよくあります。
「安全な」フォームのバイパス
クライアントサイドのバリデーションはユーザー体験のためのものであり、セキュリティのためではありません。JavaScriptのフォームが負の数値や長い文字列の入力を防いでいたとしても、Burpはそれを完全にバイパスします。Burpはブラウザの処理が終わった後のトラフィックをキャッチするため、JSによるチェックはもはや存在しません。
以前、ある決済ページをテストした際、「数量」のドロップダウンが1から10までしか選択できないようになっていました。リクエストをインターセプトして数量を-1に変更したところ、合計金額がマイナスになり、実質的にアカウントにクレジットが追加される状態になりました。クライアントサイドは攻撃者の制御下にあるため、データは必ずサーバー側で検証してください。
Intruderによるファジング
Community EditionではIntruderツールの速度が制限されていますが、小規模な作業には依然として有用です。.envやconfig.phpのような50種類の一般的なファイルがサーバーに存在するか確認する必要がある場合、Intruderは最高の相棒になります。ファイル名をペイロードの位置として設定し、リストを読み込ませて、コーヒーを飲んでいる間に実行させましょう。
より良いテストのための最終アドバイス
- スコープを設定する： Target -> Scopeタブを使用して、テスト対象のURLのみを含めるようにします。HTTP Historyを「Show only in-scope items（スコープ内のアイテムのみ表示）」でフィルタリングしてください。これにより、GmailやYouTubeのタブからのバックグラウンドトラフィックで履歴が埋め尽くされるのを防げます。
- Decoderを活用する： 機密データを適当な「Base64デコーダー」サイトに貼り付けないでください。Burpには、URL、Base64、Hexなどを安全に処理できるDecoderタブが内蔵されています。
- 法を遵守する： 自分が所有しているアプリ、または公開されているバグバウンティ（脆弱性報奨金）プログラムがあるアプリのみをテストしてください。これらのツールは、より堅牢なソフトウェアを構築するために使用し、被害を与えるために使用しないでください。
- ショートカットで高速化：
Ctrl+R(Repeater) とCtrl+I(Intruder) を使いこなしましょう。これらのタブ間を素早く移動できるようになれば、詳細な監査の時間を大幅に短縮できます。
データが「回線上を流れる」様子を実際に見ることは、コードレビューだけでは得られない視点を与えてくれます。Burp Suiteを使用することで、ウェブの隠れた仕組みが見えるようになり、開発者としてもセキュリティリサーチャーとしても、より効果的な活動ができるようになるでしょう。
