burp-suite-testing

⚠️ 許可された用途のみ このスキルは、教育目的または許可を得たセキュリティ評価にのみ使用してください。 このツールを使用する前に、システム所有者から明示的な書面による許可を得る必要があります。 このツールの不正使用は違法であり、厳しく禁止されています。

必須の確認ゲート 対象に対して調査、悪用、変更、永続化、データの抽出、または認証情報へのアクセスを試みるコマンドを実行する前に、次の手順を実施してください。

1. ユーザーに、対象の正確な URL、IP アドレス、アカウント、またはリソースを明示するよう求めます。
2. 書面による許可と許可された範囲を確認するよう、ユーザーに求めます。
3. 正確なコマンドを提示し、想定される影響を説明します。
4. 現在の会話で明示的な確認が得られるまで待ちます。

確認が得られない場合は、読み取り専用の操作にとどめ、防御に関するガイダンスのみを提供してください。サンドボックス、使い捨て VM、または管理されたラボを優先してください。

許可された用途のみ：このスキルは、許可を得たセキュリティ評価、防御的な検証、または管理された教育環境でのみ使用してください。

Burp Suite Web アプリケーションテスト

目的

Burp Suite の統合ツールセットを使用して、HTTP トラフィックの傍受と変更、リクエストの分析と再送信、自動脆弱性スキャン、手動テストのワークフローなど、包括的な Web アプリケーションセキュリティテストを実施します。このスキルでは、プロキシベースのテスト手法を通じて、Web アプリケーションの脆弱性を体系的に発見し、悪用できます。

専用のテスト用ブラウザー／プロファイルを使用し、Burp の CA 証明書はその環境でのみ信頼してください。作業が終了したら、その信頼設定を削除してください。スコープフィルターはノイズを減らしますが、セキュリティ境界ではありません。スキャン／再送信の宛先、リダイレクト、外部サービス、アカウント操作、レートの上限を明示的に制限してください。認証情報のテストには、名前を指定したテストアカウントと、試行回数／ロックアウトの上限が必要です。取得したセッション情報は非公開で保管し、レポートではトークンやパスワードを伏せてください。以下の例は仮定上のものであり、評価で発見された内容ではありません。

入力／前提条件

必要なツール

• Burp Suite Community または Professional Edition がインストールされていること
• Burp に組み込まれたブラウザー、または設定済みの外部ブラウザー
• 対象の Web アプリケーション URL
• 認証テスト用の有効な認証情報（該当する場合）

環境設定

• 一時プロジェクトまたは名前付きプロジェクトで Burp Suite を起動していること
• 127.0.0.1:8080（デフォルト）でプロキシリスナーが有効になっていること
• Burp プロキシを使用するようブラウザーが設定されていること（または Burp のブラウザーを使用すること）
• HTTPS 傍受用に CA 証明書がインストールされていること

エディションの比較

機能	Community	Professional
プロキシ	✓	✓
Repeater	✓	✓
Intruder	制限あり	フル機能
Scanner	✗	✓
Extensions	✓	✓

出力／成果物

主な出力

• 傍受・変更した HTTP リクエスト／レスポンス
• 修正方法のアドバイスを含む脆弱性スキャンレポート
• HTTP 履歴とサイトマップのドキュメント
• 特定された脆弱性の概念実証エクスプロイト

基本的なワークフロー

フェーズ 1：HTTP トラフィックの傍受

Burp のブラウザーを起動する

統合ブラウザーに移動して、プロキシをシームレスに利用します。

1. Burp Suite を開き、プロジェクトを作成するか開きます
2. Proxy > Intercept タブに移動します
3. Open Browser をクリックして、事前設定済みのブラウザーを起動します
4. Burp とブラウザーの両方を同時に表示できるよう、ウィンドウを配置します

傍受を設定する

キャプチャするリクエストを制御します。

Proxy > Intercept > Intercept is on/off toggle

When ON: Requests pause for review/modification
When OFF: Requests pass through, logged to history

リクエストを傍受して転送する

傍受したトラフィックを処理します。

1. 傍受の切り替えを Intercept on に設定します
2. ブラウザーで対象 URL に移動します
3. Proxy > Intercept タブで保留中のリクエストを確認します
4. リクエストの内容（ヘッダー、パラメーター、本文）を確認します
5. Forward をクリックして、リクエストをサーバーに送信します
6. ページが読み込まれるまで、後続のリクエストも転送し続けます

HTTP 履歴を表示する

すべてのトラフィックログにアクセスします。

1. Proxy > HTTP history タブに移動します
2. 任意のエントリーをクリックして、リクエスト／レスポンス全体を表示します
3. 列見出しをクリックして並べ替えます（時系列順にするには # をクリックします）
4. フィルターを使用して、関連するトラフィックに絞り込みます

フェーズ 2：リクエストの変更

インターセプトと変更

転送前にリクエストパラメーターを変更します。

1. インターセプトを有効にします：Intercept on
2. ブラウザーで対象のリクエストを発生させます
3. インターセプトされたリクエストから変更するパラメーターを探します
4. リクエストエディターで値を直接編集します
5. Forward をクリックして、変更したリクエストを送信します

よくある変更対象

対象	例	目的
価格パラメーター	price=1	ビジネスロジックをテストする
ユーザー ID	userId=admin	アクセス制御をテストする
数量の値	qty=-1	入力値の検証をテストする
隠しフィールド	isAdmin=true	権限昇格をテストする

例：価格の改ざん

POST /cart HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded

productId=1&quantity=1&price=100

# Modify to:
productId=1&quantity=1&price=1

脆弱性がある場合に想定される結果：変更した価格で商品が追加されます。観測したサーバーの挙動を記録してください。リクエストが変更されたという事実だけでは、何も証明できません。

フェーズ 3：対象スコープの設定

スコープの定義

特定の対象にテストを絞ります。

1. Target > Site map に移動します
2. 左側のパネルで対象ホストを右クリックします
3. Add to scope を選択します
4. プロンプトが表示されたら Yes をクリックして、スコープ外のトラフィックを除外します

スコープによるフィルタリング

HTTP 履歴から不要な情報を除外します。

1. HTTP 履歴の上にある表示フィルターをクリックします
2. Show only in-scope items を選択します
3. 履歴に対象サイトのトラフィックのみが表示されます

スコープを設定するメリット

• サードパーティのリクエストによる煩雑さを軽減します
• スコープ外のサイトを誤ってテストするのを防ぎます
• スキャンの効率が向上します
• より整理されたレポートを作成できます

フェーズ 4：Burp Repeater の使用

リクエストを Repeater に送信する

手動テスト用のリクエストを準備します。

1. HTTP 履歴から調査対象のリクエストを特定します
2. リクエストを右クリックして Send to Repeater を選択します
3. Repeater タブに移動してリクエストにアクセスします

変更して再送信する

さまざまな入力を効率的にテストします。

1. View request in Repeater tab
2. Modify parameter values
3. Click Send to submit request
4. Review response in right panel
5. Use navigation arrows to review request history

Repeater のテストワークフロー

Original Request:
GET /product?productId=1 HTTP/1.1

Test 1: productId=2    → Valid product response
Test 2: productId=999  → Not Found response  
Test 3: productId='    → Error/exception response
Test 4: productId=1 OR 1=1 → SQL injection test

レスポンスの分析

脆弱性を示す兆候を探します。

• スタックトレースを明らかにするエラーメッセージ
• フレームワークやバージョン情報の漏えい
• ロジックの不備を示す、レスポンス長の違い
• ブラインドインジェクションを示唆する応答時間の違い
• レスポンス内の予期しないデータ

フェーズ 5：自動スキャンの実行

新しいスキャンの開始

脆弱性スキャンを開始します（Professional のみ）。

1. Dashboard タブに移動します
2. New scan をクリックします
3. URLs to scan フィールドに対象 URL を入力します
4. スキャン設定を構成します

スキャン設定オプション

モード	説明	所要時間
Lightweight	概要レベルの調査	約 15 分
Fast	脆弱性の簡易チェック	約 30 分
Balanced	標準的な包括スキャン	約 1～2 時間
Deep	徹底的なテスト	数時間

スキャンの進行状況を監視する

スキャンの状況を追跡します。

1. Dashboard でタスクの状態を確認します
2. Target > Site map がリアルタイムで更新される様子を確認します
3. 検出された脆弱性を Issues タブで確認します

特定された問題を確認する

スキャン結果を分析します。

1. Dashboard でスキャンタスクを選択します
2. Issues タブに移動します
3. 問題をクリックして、以下を確認します。
   • Advisory：説明と修正方法
   • Request：問題を引き起こした HTTP リクエスト
   • Response：脆弱性を示すサーバーのレスポンス

フェーズ 6：Intruder 攻撃

Intruder の設定

自動攻撃を設定します。

1. リクエストを Intruder に送信します（右クリック > Send to Intruder）
2. Intruder タブに移動します
3. § マーカーを使ってペイロードの位置を定義します
4. 攻撃タイプを選択します

攻撃タイプ

タイプ	説明	用途
Sniper	単一の位置でペイロードを順に反復	1 つのパラメーターのファジング
Battering ram	すべての位置に同じペイロードを使用	認証情報のテスト
Pitchfork	ペイロードを並行して反復	ユーザー名とパスワードの組み合わせ
Cluster bomb	すべてのペイロードの組み合わせを試行	総当たり攻撃

ペイロードの設定

Positions Tab:
POST /login HTTP/1.1
...
username=§admin§&password=§password§

Payloads Tab:
Set 1: admin, user, test, guest
Set 2: password, 123456, admin, letmein

結果の分析

攻撃の出力を確認します。

• レスポンス長で並べ替えて異常を探します
• ステータスコードでフィルタリングして、成功した試行を見つけます
• grep を使って特定の文字列を検索します
• 結果をエクスポートして記録します

クイックリファレンス

キーボードショートカット

操作	Windows/Linux	macOS
リクエストを転送	Ctrl+F	Cmd+F
リクエストを破棄	Ctrl+D	Cmd+D
Repeater に送信	Ctrl+R	Cmd+R
Intruder に送信	Ctrl+I	Cmd+I
インターセプトの切り替え	Ctrl+T	Cmd+T

よく使うテスト用ペイロード

# SQL Injection
' OR '1'='1
' OR '1'='1'--
1 UNION SELECT NULL--

# XSS
<script>alert(1)</script>
"><img src=x onerror=alert(1)>
javascript:alert(1)

# Path Traversal
../../../etc/passwd
..\..\..\..\windows\win.ini

# Command Injection
; ls -la
| cat /etc/passwd
`whoami`

リクエスト変更のヒント

• 右クリックしてコンテキストメニューのオプションを表示します
• エンコード／デコードにはデコーダーを使用します
• Comparer ツールを使ってリクエストを比較します
• 興味深いリクエストをプロジェクトに保存します

制約とガードレール

運用上の境界

• 許可を得たアプリケーションのみをテストします
• スコープを設定し、意図せずスコープ外をテストしないようにします
• サービス拒否を避けるため、スキャンにレート制限を設定します
• すべての調査結果と操作を記録します

技術的な制限

• Community Edition には自動スキャナーがありません
• サイトによってはプロキシ経由のトラフィックがブロックされることがあります
• HSTS／証明書ピンニングでは、追加の設定が必要な場合があります
• 大規模なスキャンにより、WAF のブロックが発生することがあります

ベストプラクティス

• 大規模なテストを始める前に、必ずターゲットスコープを設定します
• 確実にインターセプトするには、Burp のブラウザーを使用します
• 作業を保護するため、プロジェクトを定期的に保存します
• 誤検知がないか、スキャン結果を手動で確認します

例

例 1：ビジネスロジックのテスト

シナリオ：E コマースでの価格改ざん

1. 商品を通常どおりカートに追加し、リクエストをインターセプトします
2. POST ボディ内の price=9999 パラメーターを特定します
3. price=1 に変更します
4. リクエストを転送します
5. サンドボックスのカート／テスト決済を使用して、サーバーが計算した合計金額を確認します。別途明示的にスコープが許可されていない限り、実際の注文は行わないでください

調査結果：サーバーがクライアントから提供された価格値を信頼しています。

例 2：認証のバイパス

シナリオ：ログインフォームのテスト

1. 有効な認証情報を送信し、Repeater でリクエストを取得します
2. テストのためにリクエストを Repeater に送信します
3. 次を試します：username=admin' OR '1'='1'--
4. ログイン成功のレスポンスを確認します

調査結果：認証に SQL インジェクションがあります。

例 3：情報漏えい

シナリオ：エラーを利用した情報収集

1. 商品ページに移動し、productId パラメーターを確認します
2. リクエストを Repeater に送信します
3. productId=1 を productId=test に変更します
4. フレームワークのバージョンが明らかになる詳細なエラーを確認します

調査結果：スタックトレースに Apache Struts 2.5.12 が開示されています。

トラブルシューティング

ブラウザーがプロキシ経由で接続できない

• プロキシリスナーが有効になっていることを確認します（Proxy > Options）
• ブラウザーのプロキシ設定が 127.0.0.1:8080 を指していることを確認します
• ファイアウォールがローカル接続をブロックしていないことを確認します
• 確実に設定するには、Burp の組み込みブラウザーを使用します

HTTPS のインターセプトに失敗する

• Burp CA 証明書をブラウザー／システムにインストールします
• http://burp にアクセスして証明書をダウンロードします
• 証明書を信頼されたルートに追加します
• インストール後にブラウザーを再起動します

パフォーマンスが遅い

• スコープを絞って処理を減らします
• 不要な拡張機能を無効にします
• 起動オプションで Java ヒープサイズを増やします
• 使用していない Burp のタブや機能を閉じます

リクエストがインターセプトされない

• 「Intercept on」が有効になっていることを確認します
• インターセプトルールによってターゲットがフィルタリングされていないか確認します
• ブラウザーが Burp プロキシを使用していることを確認します
• ターゲットがサポート対象外のプロトコルを使用していないことを確認します

使用する場面

このスキルは、概要で説明されているワークフローまたは操作を実行する場合に適用できます。