
アプリケーションのWeb Cache Deception攻撃に対する脆弱性をテストするためのBurp Extension
Web Cache Deception攻撃に対する脆弱性をテストするためのBurp拡張機能です。
拡張機能をロードすると、Target - Sitemapタブでテスト対象のリソースを右クリックしてアクセスできます。コンテキストメニューに"Web Cache Deception Test"項目が表示され、テストの実施に使用できます。リソースが脆弱な場合、脆弱性の詳細を示すIssueが作成されます。
このコンテキストメニュー項目は、Proxy - Http Historyタブのリクエストでも利用できます。
2017年2月、セキュリティ研究者のOmer Gil氏が「Web Cache Deception」と呼ばれる新たな攻撃ベクトルを発表しました(https://omergil.blogspot.co.il/2017/02/web-cache-deception-attack.html)。
Web Cache Deception攻撃は結果的に甚大な被害をもたらす可能性がありますが、実行は非常に簡単です:
** もちろん、この攻撃は攻撃者がアクセス可能な脆弱なリソースが機密データを返す場合にのみ意味を持ちます。
この攻撃が成立するには、アプリケーションを脆弱にする非常に特定の状況が必要です:
1. アプリケーションは返すリソースを決定するためにURLの最初の部分のみを読み取る。
被害者が以下をリクエストした場合:
https://www.example.com/my_profile
アプリケーションは被害者のプロフィールページを返します。アプリケーションはURLの最初の部分のみを使用してプロフィールページを返すべきと判断します。アプリケーションが次のリクエストを受け取った場合
https://www.example.com/my_profile_test
追加されたテキストを無視して、被害者のプロフィールページを返します。これは次のような他のURLにも適用されます
https://www.example.com/my_profile/test
2. アプリケーションスタックはキャッシュヘッダーの値ではなく、ファイル拡張子に従ってリソースをキャッシュする。
アプリケーションスタックが画像ファイルをキャッシュするように設定されている場合、.jpg .png .gif 拡張子を持つすべてのリソースをキャッシュします。つまり、例えば次の画像
https://www.example.com/images/dog.jpg
は初回リクエスト時にアプリケーションサーバーから取得されます。その後はキャッシュから取得され、最初にキャッシュされたリソースと同じものが返されます(キャッシュタイムアウトが設定されている限り)。
これらの前提条件は、以下の方法でWeb Cache Deception攻撃に悪用される可能性があります:
https://www.example.com/my_profile/test.jpg
https://www.example.com/my_profile/test.jpg
MIND BLOWN なんて簡単なのでしょう?