セッション設定

セッション設定では、Burpのセッションハンドリング機能の設定ができます。次の設定ができます:

• セッションハンドリングルール。
• Cookie jar。
• マクロ。

セッションハンドリングの概要

Webアプリケーションをテストする際、セッションハンドリングやアプリケーションの状態に関する課題に遭遇することがあります。例:

• 防御またはその他の理由で、テストで使用していたセッションをアプリケーションが破棄することがあります。それ以降のリクエストを送信するには、セッションを復元する必要があります。
• 一部の機能は、リクエストフォージェリ攻撃を防ぐために各リクエストごとに変化するトークンを要求することがあります。
• 機能によっては、テスト中のリクエストが受け入れられる適切なアプリケーション状態にしておくために、事前に一連のリクエストを行っておく必要があるかもしれません。

Burpのセッションハンドリング機能によって、バックグラウンドでセッションに関連する課題を処理するようにシステムを設定でき、テストを中断せずに継続できます。

セッションハンドリングルール

Burpのセッションハンドリングルールでは、対象のセッションハンドリング機構や関連する機能をBurpがどう扱うか、非常にきめ細かく制御できます。

各ルールには2つの部分があります:

• ルールが適用されるツール、URL、パラメータを示すスコープ。
• リクエストにルールが適用されたときに実行されるアクション。

Burpがリクエストを送信するたびに、定義したルールのうちどのルールが適用されるか判断し、関連するすべてのアクションを順番に実行します。

複数のルールを作成すると、それぞれのアプリケーションや機能に適用する動作の階層を定義できます。

たとえば、あるテストで次のようなルールを定義できます:

• すべてのリクエストに対して、Burpの cookie jarからcookieを追加する。
• 特定のドメインへのリクエストに対して、アプリケーションとのセッションがアクティブなままか検証し、もしアクティブではない場合は、アプリケーションにログインし直すマクロを実行し、結果のセッショントークンでcookie jarを更新する。もしセッションがアクティブではない場合、アプリケーションにログインし直すマクロを実行し、結果のセッショントークンでcookie jarを更新する。
• __csrftokenパラメータを含む特定のURLに対して、有効な__csrftoken値を取得するマクロを実行し、リクエスト生成時にそれを使用する。

セッションハンドリングトレーサ

セッションハンドリングトレーサは、セッションハンドリングルールのトラブルシューティングに便利です。トレーサを表示するには、セッショントレーサを開くをクリックします。

トレーサは、セッションハンドリング機能が処理したリクエスト(つまり、少なくとも1つのセッションルールが適用されたリクエスト)のリストを表示します。処理された各リクエストごとに、実行されたルールの配列とアクションを表示します。また配列のステップごとに、現在のリクエストで起こった変更も表示します。この情報は、現在のルール設定によって必要な結果が導き出せているかどうかの確認に役立ちます。

Burpツールでのセッションハンドリングルール

Burpのセッションハンドリングルールは、Burpのその他の機能と連係して動作します:

• デフォルトのセッションハンドリングルールとして、Scannerが生成するcookie付きのリクエストをcookie jarで更新するルールがあります。このルールは、Scannerによるクロール中やクロール駆動の診断中に行っている独自のセッション管理には適用されません。必要に応じて、このルールを無効化できます。
• リクエストを発行する前にセッションハンドリングルールがリクエストを変更する場合(たとえば、cookieやその他のパラメータを更新するなど)、IntruderやRepeaterには更新された最終リクエストが表示されます。ただし、Scannerが報告した問題内に表示されるリクエストは、元のリクエストとして表示されます。これにより、変更されたリクエストと元のリクエストを比較できます。セッションハンドラに変更されたスキャン項目の最終的なリクエストを表示するには、Burp Repeaterにリクエストを送信し、リクエストを発行してください。RepeaterとScannerが同じセッションハンドリングルールを設定する必要があることに注意してください。
• ScannerまたはIntruderが、セッションハンドリングアクションの影響を受けるcookieやパラメータを操作するリクエストを行う場合、セッションハンドリグアクションはそのリクエストに対してアクションを適用しません。これにより、実行中のテストへの干渉を回避できます。たとえば、Intruderを使用してリクエストのすべてのパラメータにファジングをする場合で、リクエストのsessid cookieを更新するセッションハンドリングルールも設定しているとします。この場合、Intruderが他のパラメータをファジングしているときは、sessid cookieは更新されます。Intruderがsessid cookie 自身をファジングするときは、セッションハンドリングルールはcookieを更新せず、Intruderのペイロード文字列をsessidの値として送信します。

セッションハンドリングルールの設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。

Cookie Jar

Burpのcookie jarは、アクセスしたWebサイトが発行したすべてのcookieを格納します。cookie jarは、すべてのBurpツールで共有されます。

セッションハンドリングルールとマクロはcookie jarを使用して、送信するリクエストのcookieを自動的に更新できます。

cookie jarはデフォルトで、Proxyからのトラフィックに基づいて更新されます。ただし、次のいずれかのツールからcookieが更新されるよう監視する設定ができます:

• Proxy。
• Intruder。
• Scanner。
• Sequencer。
• Repeater。
• Extensions。

Proxyの場合、Burpはブラウザから送信されたリクエストも調査します。これは、アプリケーションによって永続的なcookieがBurpブラウザに保存されており、それがセッション管理に必要な場合に便利です。Proxyを経由するリクエストを元にcookie jarを更新するということは、現在のアクセスでアプリケーションがcookieの値を更新しない場合でも、すべての必要なcookieがcookie jarに追加されることを意味します。

cookie jarは、cookieのドメインやパススコープに従います。

cookie jarの管理

cookie jarの中身を管理するには、cookie jarを開くをクリックします。cookieの手動編集、jarからcookieの削除、jarを完全に空にできます。

Cookie jar設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。

マクロ

マクロ設定では、Burpがテスト中に使用できるマクロを作成および管理できます。

マクロは、一つ以上の一連のリクエストを事前に定義したものです。セッションハンドリングルール内でマクロが使用でき、次のようなさまざまなタスクを実行できます:

• (ユーザの個別ページなど)アプリケーションのページを取得して、現在のセッションがまだ有効か確認する。
• 新しい有効なセッションを取得するためのログインを実行する。
• 別のリクエストのパラメータとして使用するトークンまたはnonceを取得する。
• 多段階処理のリクエストをスキャンまたはファジングする場合、必要な前処理リクエストをマクロで実行し、対象のリクエストをアプリケーションが受け入れられる状態する。
• 多段階処理で、"攻撃"リクエストの後に後処理を実行する。アクションが実行されたことの確認や、その他処理を完了させられます。

各マクロでは一連のリクエストと同時に、リクエストに含まれるcookieやパラメータの処理方法やアイテム間の依存関係を指定できます。

追加をクリックするとマクロエディタダイアログが表示されます。

既存のマクロの編集や、リスト内の位置変更ができます。

マクロ設定は、プロジェクト設定です。現在のプロジェクトにのみ適用されます。