サイトマップの比較

この機能により、2つのサイトマップを比較し、差異を強調表示できます。この機能は、アクセス制御系の脆弱性を見つけるさまざまな方法や、大規模なアプリケーションのうちどの部分を手動検査すれば良いかの確認に使えます。この機能の典型的な使用例は次の通りです:

• 異なる権限のアカウントを使用してアプリケーションをマッピングし比較すると、一方のユーザだけに表示される機能が確認できます。
• 高い権限を持つアカウントを使用してアプリケーションをマッピングし、低い権限のアカウントを使用してサイト全体を再度リクエストすると、特権機能へのアクセスが適切に制御されているかどうか確認できます。
• 同じタイプの2つの異なるアカウントを使用してアプリケーションをマッピングすると、機密性の高いリソースへアクセスする際どこでユーザ固有のIDが使われているか特定でき、ユーザ毎のデータが適切に分離されているかどうか判断できます。

メインサイトマップのコンテキストメニューのサイトマップ比較で、この機能にアクセスできます。比較元のサイトマップ、そのサイトマップとどのようなリクエストをマッチさせるのか、どのようなレスポンスの比較をする必要があるのかを設定するウィザードが開きます。Burpは比較を実行し、レビュー用に結果を表示します。

サイトマップソース

サイトマップを比較するには、比較する元サイトマップを選択する必要があります。次のオプションがあります:

• BurpのTargetタブに表示されている現在のサイトマップ
• Professional 以前保存したBurpのプロジェクトファイルやステートファイルから読み込むサイトマップ。このオプションは、異なる権限レベルを持つアカウントを使用したアプリケーションマップが既にある場合に便利です。
• 上記のいずれかと別のセッションコンテキストで再リクエスト。このオプションは、高い権限のアカウントでアプリケーションのマッピングをしている場合で、低い権限のアカウントを使って再リクエストし特権の機能へのアクセスが適切に制御されているかどうか確認したい場合に便利です。

サイトマップのすべてのコンテンツを含めるか、スコープ内のアイテムだけに制限するか、選択できます。

別のセッションコンテキストでサイトマップを再リクエストする場合、次の点に注意してください:

• まず、比較時に作られるリクエストが目的のセッションコンテキスト内で行われるように、適切なセッションハンドリングルールを作成する必要があります。これらのルールは、Targetツールで作られたリクエストに適用されるように校正する必要があります。最も単純なケースでは、Targetツールのリクエストのcookieを、Burpのcookie jarで更新するセッションハンドリングルールを使い、比較を実行する前に目的のセッションコンテキストをブラウザで取得すればよいでしょう。他のケースでは、現在のセッションを検証して必要に応じて再ログインするなど、より複雑なセッションハンドリングルールを作成する必要があります - 詳細はセッションハンドリングルールのヘルプを参照してください。
• 一般的に、セッションコンテキストを混乱させる可能性のあるリクエストの除外が望ましいです - たとえばログイン、ログアウト、ユーザ偽装機能などです。選択済みまたはスコープ内のアイテムのみに比較を制限するオプションを使用すれば可能です。

リクエストマッチ

比較を実行するため、Burpは1つ目のサイトマップの各リクエストごとに、2つめのサイトマップのリクエストと対応付け、逆も同様に行います。対象アプリケーションの機能に合わせて、どのようにリクエストの対応付けするか、詳細な設定が可能です。

リクエストの対応付けに次のどのアイテムを使用するか選択できます:

• URLファイルパス - これは常に対応付けプロセスに含める必要があり、2つのリクエストが同等であることを確認するための最低限の基準です。
• HTTPメソッド - 一般的にこれを含むべきで、ほとんどのアプリケーションは、同じURLでもGETとPOSTメソッドで異なる挙動をします。
• URLクエリーストリング - 一般的にこれを含むべきで、異なるURLパラメータは異なるアプリケーションの機能で使われます。パラメータ名のみ一致サブオプションは、同じパラメータ名で値が異なるクエリーストリングでも対応付けします。これは、(たとえばパラメータ値にユーザ固有または一時的なデータが含まれている場合など)望ましい場合がありますが、実行されるアプリケーション機能の特定にパラメータが使われている(たとえばaction=CreateUserなど)場合は、無効にすべきです。これらのパラメータを無視するサブオプションは、対応付けの際、完全に無視するクエリーストリングのパラメータを指定できます。
• リクエストボディ - 一般的にこれを含むべきで、異なるボディパラメータは異なるアプリケーションの機能で使われます。URLクエリストリングパラメータの説明と同じオプションがあります。
• リクエストヘッダ - このオプションは、リクエストの先頭行の後の、HTTPヘッダが異なるリクエストに影響があります。アプリケーションレベルの機能では使われないのに、ブラウザがさまざま理由でリクエストごとにヘッダを変更する可能性があるため、この動作は通常望ましくありません。ただしたとえば、スクリプトが生成したカスタムHTTPヘッダを含むリクエストをアプリケーションが利用していて、それがリクエストする機能の特定に使われている場合、このオプションを有効にしてもよいです。

ほとんどの状況でデフォルトオプションで問題なく、URLファイルパス、HTTPメソッド、クエリーストリングとメッセージボディのパラメータ名によって、対応付けを行います。

レスポンス比較

リクエストを対応付けるため、レスポンスを比較し違いを見つけます。対象アプリケーションの機能に合わせて、レスポンスの比較方法の詳細を設定できます。

次のオプションがあります:

• レスポンスヘッダ - すべてのヘッダ(指定した一部を除く)を含めるか、指定したヘッダのみを含めるか、選択できます。アプリケーションの機能や状態が値に反映されるヘッダ(Set-Cookieなど)を含めることが一般的に望ましいです。
• フォームフィールド値 - すべてのフォームフィールド値(指定した一部を除く)を含めるか、指定した値だけを含めるか、選択できます。一般的に、アクセス制御の問題を確認する際、フォームフィールド値に差異が現れる場合が多く、手動レビューで注目する必要があります。この設定を変更して、無関係なフィールドを除外し、比較を繰り返せます。
• 空白 - 空白のみのレスポンスは、一般的にアクセス制御の問題に関係しないため、無視もできます。
• MIMEタイプ - テキスト以外のコンテンツの比較を省略できます。これらのレスポンスにはイメージなどの静的コンテンツが含まれていることが多く、アクセス制御の問題に関係しないため、このような比較は計算集約的に望ましい方法です。

ほとんどの状況でデフォルトのオプションで機能します。この設定では、一般的なHTTPヘッダや一時的な値を持つフォームフィールドを無視し、空白のみのレスポンスも無視します。デフォルトのオプションは、レスポンス内の細かい変化によるノイズを減らすように設計されており、問題の可能性が高い差異の方に集中できます。

比較結果

比較結果には、両方のサイトマップがツリービューとテーブルビューで表示され、関連する差異が強調表示されます。2つのサイトマップ間で追加、削除、変更されたアイテムは、それに応じて色分けされます。テーブルビューには差異箇所数列もあり、マップ1のレスポンスをマップ2のレスポンスに一致させるために編集が必要なテキスト数の最小値を表しています。

マップやツリーで1つ以上のアイテムを選択すると、他方のマップでも同じツリーのブランチが表示されるよう選択が自動的に更新され、またはテーブル内の同じアイテムが選択されます。選択を同期オプションをオフにするとこの動作を変更できます。

選択したアイテムの完全なリクエストとレスポンスがリクエスト/レスポンスビューアに表示され、関連する差異がレスポンス内で強調表示されます。

1つのディスプレイフィルタが両方のサイトマップに適用され、デフォルトではすべてのアイテムが表示されています。

サイトマップ比較の結果を解釈するには、人間の知能と、指定されたアプリケーション機能の意味とコンテキストを理解する必要があります。例:

• レスポンスの一部の差異はセキュリティと関係ありません。たとえば、異なる2人のアプリケーションのホームページには、異なる表示名、リンク、ユーザ固有のコンテンツが含まれる場合があります。これらの差異は予想通りで、ユーザインタフェースのみに関連するためアプリケーションのアクセス制御の有効性には関係ありません。
• 一部の差異は、アクセス制御が設計通りに機能していることを示しています。たとえば、管理者ユーザは特権機能にアクセスでき、低権限ユーザには"許可されていません"というメッセージが表示されます。
• 同じレスポンスが2人のユーザに返された場合、セキュリティの問題を表しています。たとえば、管理者ページにアプリケーションユーザに関する機密情報を含むページへのリンクがあり、低権限ユーザも同じページを表示できる場合などです。
• 他のケースでは、同じレスポンスが2人のユーザに返ってもセキュリティ的に問題ありません。たとえば、アプリケーションの公開検索機能は、ユーザのコンテキストに関係なく同じ結果を返すように設計されているでしょう。
• 場合によっては、ユーザごとのUIカスタマイズ(異なる表示名やリンクなど)による差異が多くのページに存在し、アクセス制御の評価に関連する他のページでも同じ部分と異なる部分があります。

すべてのこれらのシナリオは同じアプリケーションで共存するため、実際のアクセス制御の問題を特定する作業は困難です。これを行う唯一の方法は、比較結果の手動レビューです。Burpには、このプロセスを簡単にするためのいくつかの方法があります:

• ディスプレイフィルタを利用して、指定した文字列を含む(または含まない)アイテムを除外できます。たとえば、ほとんど管理者機能が、低権限のユーザのリクエストに"許可されていません"というメッセージを返す場合、これらのレスポンスをマップで非表示にし、アプリケーションの特権モデルに問題のあるアイテムのみを残せます。
• テーブルビューの"差異箇所数"列は、手がかりに便利です。たとえば、アプリケーションのほとんどのページに、ユーザごとのUIカスタマイズによる差異が2つある場合、差異箇所数でレスポンスをソートしすると、この値から逸脱したレスポンスを探せます。また、特定の差異箇所数でアクセス制御の脆弱性を1つ見つけた場合、同じまたは似た数の他のレスポンスは同様に脆弱な機能かもしれません。
• 比較結果を確認していて、レスポンスヘッダやフォームフィールド値に関連性のない規則的な差異があると判断した場合は、比較対象から除外するべきです。クエリーストリングやボディパラメータに基づくマッチが、一部のリクエストで正しくないことがあります。この場合、レスポンス比較またはリクエストマッチオプションに戻り微調整し、比較を再実行してください(これらのオプションを変更した際は、サイトマップを再リクエストする必要はありません)。

このような複雑なアクセス制御の評価を行う理由は、全自動ツールではアクセス制御の脆弱性をほとんど特定できないためです。実際には、その目的のツールのほとんどがノイズを生成し、誤検出や検知漏れになりがちです。アプリケーションの機能を詳細に調査し、それぞれの場合にアクセス制御が適切に実装されているかどうか評価するタスクを、Burpがすべて行ってくれるわけではありません。サイトマップ比較機能は、できるだけ多くの処理を自動化し、必要なすべての情報を明確な形式で提供し、アプリケーションの機能の知識を活用して実際の脆弱性を特定できるようにします。