スキャンのクロールフェーズでは、アプリケーションを巡回し、リンクをたどり、フォームを送信し、必要な場合はログインし、アプリケーションのコンテンツとナビゲーション経路を列挙します。この一見単純な作業により、Burpのクローラがアクセスできるさまざまな課題点を提示し、アプリケーションの正確なマップを作成します。
Burpのクローラはデフォルトで、Burpブラウザを使用して対象アプリケーション内を遷移し、リンクをクリックして、可能な場合は入力を送信します。アプリケーションのコンテンツや機能について、アプリケーションの異なる場所とそれらの間のリンクを表す、有向グラフ形式のマッピングを構築します。
クローラは、アプリケーションが使用するURL構造は考慮しません。場所とは、到達したアイテムのURLではなく、コンテンツに基づいて識別(かつ後で再識別)されます。これによりクローラは、CSRFトークンやキャッシュバスターなど一時的なデータをURLに含めるような最新のアプリケーションを確実に処理できます。毎回各リンクのURL全体が変更されても、クローラは正確なマップを作成します。
アプリケーションの状態やユーザの操作に基づき、異なる場所に同じURLを使用するアプリケーションでも、クローラが処理できます。
クローラが巡回して対象アプリケーションを網羅すると、まだ完了していないグラフの先端を追跡します。これらは、アプリケーションで観察されたがまだ訪問していないリンク(または他のナビゲーション遷移)のリンクを表しています。しかしクローラは、保留中のリンクに"ジャンプ"したり、コンテキストを外れてアクセスはしません。代わりに、現在の場所から直接ナビゲートするか、開始場所に戻ってからナビゲートします。通常のユーザがWebサイトをブラウズするアクションを、可能な限り忠実に再現します:
URL構造について考慮しない手法のクロールは、最近のWebアプリケーションを扱う際に非常に効果的ですが、"多すぎる"コンテンツにアクセスしてしまう可能性があります。最近のWebサイトにはよく、(ページフッターやバーガーメニューなど経由)で大量の余分なナビゲーション経路があり、つまりすべてが直接他のすべてにリンクされています。この問題に対処するためにBurpのクローラは、さまざまな手法を採用しています: 既にアクセスした場所へのリンクのフィンガープリントを作成して、重複アクセスを防ぎます; 新しいコンテンツの発見を優先させるよう幅を優先してクロールします; クロール範囲を制限し中断する設定ができます。これらの対処は、カレンダーのような"無限の"アプリケーションを正しく処理するためにも役立ちます。
BurpのクローラはBurpブラウザを使用して対象アプリケーション内を遷移するため、最新のブラウザが実行できるほぼすべてのセッション管理メカニズムを自動的に処理できます。マクロを記録したり、セッションの取得方法や現在のセッションが有効か確認するセッションハンドリングルールを設定する必要はありません。
クローラは、複数のクローラ"エージェント"を使用して作業を並列化します。各エージェントは、それぞれのブラウザでアプリケーションを巡回する、別々のユーザになります。各エージェントは独自のcookie jarを持ち、アプリケーションがcookieを発行すると更新されます。エージェントが開始位置に戻ってそこからクロールを開始する場合、cookie jarはクリアされ、完全に新しいブラウザセッションをシミュレートします。
クローラが移動する際のリクエストは、先行するレスポンスに基づいて動的に生成されるため、URLまたはフォームフィールドのCSRFトークンは自動的に処理されます。よってクローラは、複雑なセッションハンドリングを使用する機能を正しくナビゲートでき、ユーザによる設定は不要です:
最近のWebアプリケーションは非常にステートフルで、ユーザが実行したアクションの結果によって、同じアプリケーション機能が別のタイミングでは異なるコンテンツを返すのが一般的です。Burpのクローラは、クロール中に実行した操作に起因する、アプリケーション状態の変化を検出できます。
次の例で、パスBCを移動すると、アプリケーションは状態1から状態2に遷移します。リンクDは、状態1と状態2では論理的に異なる位置になります。したがって、パスADは空のカートに移動し、ABCDは入っている状態のカートに移動します。リンクDが不確定であるとするのではなく、リンクDが依存する状態変化の経路をクローラが認識できるということです。クローラは以後、入っているカートの場所に確実に到達し、そこから入手可能な他の機能にアクセスできます。
Burpのクローラは、認証情報が送信されていない未認証フェーズから始まります。これが完了すると、Burpはアプリケーション内でログインと自己登録機能を検出します。
アプリケーションが自己登録をサポートしている場合、Burpはユーザの登録を試みます。1つ以上の既存の認証情報を使用するようなクローラ設定もできます。
その後、クローラは認証フェーズに進みます。何度かログイン機能にアクセスして、次を送信します:
ログインに送信された各認証情報のセットごとに、Burpはログインの後に発見されたコンテンツをクロールします。これによりクローラは、さまざまなタイプのユーザが使用できる、さまざまな機能を取得できます。
最近のWebアプリケーションでは、"同じ"場所や機能がユーザの行動の結果によるものとは限らず、さまざまな場面で大幅に異なるレスポンスを返すような、揮発性のコンテンツが多くあります。ソーシャルメディアチャネルのフィードや、ユーザのコメント、インライン広告、または本当にランダムなコンテンツ(今日のメッセージ、A/Bテストなど)によって、この挙動が発生する可能性があります。
Burpのクローラは、揮発性のコンテンツの多くの事例を識別し、異なるアクセスで異なるレスポンスであるにも関わらず、同じ場所を正しく再識別できます。これにより、一連のアプリケーションレスポンス内の"コア"要素に注目でき、これは興味深いアプリケーションのコンテンツと機能への主要なナビゲーション経路を発見する上で最も重要である可能性があります。
場合によって、異なるタイミングで特定のリンクを訪問すると、"同じ"とみなすにはあまりにも異なるレスポンスが返ってくる場合があります。この状況では、Burpのクローラは2つの異なる場所としてレスポンスの両方のバージョンを取得し、グラフ内の不確定エッジとしてプロットします。アプリケーション全体の不確定な範囲がそれほど大きくない場合、Burpは関連するコンテンツをクロールでき、不確定リンクの背後にあるコンテンツへの道を確実に見つけられます:
Burpはデフォルトで、マシンがそれをサポートしてそうな場合、対象WebサイトやアプリケーションのナビゲーションにBurpブラウザを使用します。このアプローチにはさまざまな大きな利点があり、最新のブラウザが持つクライアント側のテクノロジのほとんどをBurp Scannerが処理できるようになります。
主な利点の1つは、JavaScriptを多用するコンテンツを効果的に巡回できることです。一部のWebサイトでは、JavaScriptを使用してナビゲーションUIを動的に生成しています。こういったコンテンツには生のHTMLが存在していませんが、Burp ScannerはBurpブラウザを使用してページを読み込み、UIの構築に必要なスクリプトを実行して、通常どおりクロールを続行できます。
また、WebサイトがJavaScriptのイベントハンドラを使用してその場でリクエストを変更する場合でも、BurpブラウザのおかげでBurp Scannerが対応しています。クローラはこれらのイベントをトリガーし、関連するスクリプトを実行し、必要に応じてリクエストを変更します。たとえば、Webサイトがonclickイベント後にJavaScriptを使用し新しいCSRFトークンを生成し、後続のリクエストに追加する場合があります。JavaScriptイベントハンドラーによってクリック可能にされた要素を操作できます。
必要に応じて、ブラウザを利用したスキャンを有効または無効にするよう手動でスキャン設定を変更できます。このオプションは、クロールオプション > その他 > Burpブラウザオプションにあります。