AutoRepeater: Burp Suite による HTTP リクエストの自動繰り返し

tl;dr

Extender 内で AutoRepeater.jar をインポートしてください。

簡単な説明

AutoRepeater は、定義された置換によって変更されたリクエストのみを再送信します。AutoRepeater は、特定のタブに設定された条件に一致するリクエストを受信すると、まず定義されたすべてのベース置換をリクエストに適用し、次に定義された各置換について、ベース置換が適用されたリクエストをコピーして、そのリクエストに指定された置換を適用します。

はじめに

Burp Suite は、インターセプト型 HTTP プロキシであり、Web アプリケーションのセキュリティテストを実施するための事実上の標準ツールです。Burp Suite は非常に便利なツールですが、これを使用して認可テストを実施することは、「リクエストを変更して再送信する」ループを伴う面倒な作業になることが多く、脆弱性を見逃したり、テストを遅らせたりする可能性があります。この労力を軽減するために開発されたのが、オープンソースの Burp Suite 拡張機能である AutoRepeater です。AutoRepeater は、Web アプリケーションの認可テストを自動化および効率化し、Burp Suite 内でリクエストを自動的に複製・変更・再送信するとともに、レスポンスの差分をすばやく評価できる、セキュリティ研究者にとって使いやすいツールを提供します。

AutoRepeater

AutoRepeater がない場合、基本的な Burp Suite の Web アプリケーションテストの流れは次のとおりです。

1. ユーザーは Web アプリケーションをあちこち閲覧して、興味深いリクエストを見つける
2. ユーザーはリクエストを Burp Suite の「Repeater」ツールに送信する
3. ユーザーは「Repeater」内でリクエストを変更し、サーバーに再送信する
4. 脆弱性が見つかるまで手順 3 を繰り返す
5. テスト時間がなくなるか、バグバウンティの収入で引退できるまで、手順 1 から再度開始する

このテストの流れは機能しますが、任意のリクエストに存在し得る問題をテストするには特に退屈です。たとえば、電子メールアドレス、アカウント ID、ロール、URL、CSRF トークンの変更は、いずれも脆弱性につながる可能性があります。現在、Burp Suite は Web アプリケーション内のこれらのタイプの脆弱性をすばやくテストすることはできません。

認可テストを容易にする既存の Burp Suite プラグイン (AuthMatrix、Authz、Autorize) がいくつかありますが、それぞれに有用性を制限する問題があります。AuthMatrix と Authz は、ユーザーが特定のリクエストをプラグインに送信し、認可テストの実行方法に関するルールを設定する必要があるため、重要なリクエストを見逃すリスクが生じ、テストが遅くなります。Autorize は、汎用的なテキスト置換機能をユーザーに提供せず、ユーザーインターフェースもわかりにくいものです。AutoRepeater は、これらのプラグインの優れたアイデアをすべて取り入れ、Burp Suite の使い慣れたユーザーインターフェースと組み合わせて、最も効率的な認可テストプラグインを実現しました。

AutoRepeater は、Web アプリケーション内の認可テストを効率化するための汎用的なソリューションを提供します。AutoRepeater には次の機能があります。

• 任意のリクエストを自動的に複製、変更、再送信
• 条件付き置換
• ヘッダー、Cookie、パラメータ値のクイック置換
• 分割表示のリクエスト/レスポンスビューア
• 変更前と変更後のリクエスト/レスポンス差分ビューア
• CSRF トークンやセッション Cookie など、リクエストを壊す値のベース置換
• 名前を変更できるタブ
• ロギング
• エクスポート
• アクティベーションの切り替え
• 他の Burp Suite ツールから「Send to AutoRepeater」

使用例

以下は、AutoRepeater の一般的な使用例です。ツールを使用する際の参考になるヒントは次のとおりです。

• ブラウジングを開始する準備ができるまで、AutoRepeater を有効化しないでください。
• Extender が Burp の Cookie ジャー (Project Options > Session) の Cookie を使用しないようにしてください。
• 置換が期待どおりに機能しているかどうかを早い段階で確認してください。
• タブと設定は再起動後も保持されますが、データは失われます。

未認証ユーザーアクセスのテスト

未認証ユーザーがアプリケーションにアクセスできるかどうかをテストするには、Base Replacements に Remove Header By Name のルールを 1 つ設定し、"Cookie" をマッチさせます。

認証済みユーザーアクセスのテスト

認証済みユーザー間のアクセス (例: 低権限から高権限へ) をテストするには、使用される各セッション Cookie の置換を定義する必要があります。

1. 低権限セッションの Cookie 名と値をメモします。
2. 各 Cookie について、Base Replacements に Match Cookie Name, Replace Value のルールを設定します。Cookie 名をマッチさせ、低権限ユーザーの Cookie に置き換えます。
3. テストしたいロールの数だけ繰り返します。
4. 最高権限ユーザーとしてアプリケーションを閲覧します。
5. 結果を確認します。

ユーザーアクセス結果の確認

アクセステストの結果を確認するには、まず最新バージョンのツール (BApp ストアではなく Git) を使用していることを確認します。

1. URL で並べ替え、次に Resp. Len. Diff. で並べ替えます。差分が 0 でステータスコードが同一の項目は、アクセスが成功したことを強く示しています。
2. Logs > Log Filter を使用して、無関係なデータの除外を設定します (例: File Extension = (png|gif|css|ico)、Modified Status Code = (403|404))。
3. 結果を確認し、異常に見えるものを手動で調査します。

参考文献

• BSides Rochester 2018 - AutoRepeater: Automated HTTP Request Repeating With Burp Suite
• AutoRepeater: Automated HTTP Request Repeating With Burp Suite