AutoRepeater: Burp Suite による自動 HTTP リクエストリピート

概要

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

簡単な説明

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

はじめに

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

AutoRepeater

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

ユーザーは Web アプリケーションを探索して、興味深いリクエストを見つける
ユーザーはリクエストを Burp Suite の「Repeater」ツールに送信する
ユーザーは「Repeater」内でリクエストを変更し、サーバーに再送信する
お目当ての脆弱性が見つかるまで手順 3 を繰り返す
テスト時間がなくなるか、バグバウンティの収入で引退できるようになるまで、手順 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 ジャーの Cookie を使用していないことを確認してください (Project Options > Session)。
置換が期待どおりに機能していることを早い段階で確認してください。
タブと設定は再起動後も保持されますが、データは失われます。

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

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

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

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

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

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

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

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

auto-repeater

人気