Shikata Ga Nai

Private? There is no such things.

LAB: パス区切り文字を悪用したWebキャッシュ・ディセプションの実践解説

Hello there, ('ω')ノ

✅ このラボで学べること

このラボでは、Webキャッシュ・ディセプション(Web Cache Deception)攻撃の一種である「パス区切り文字の解釈の違い」を悪用した手法を学びます。具体的には、キャッシュサーバーとオリジンサーバーがURLのパスを異なる方法で解釈することにより、攻撃者が他のユーザーの機密情報を取得できる脆弱性を突きます。


🎯 攻撃の全体像

  1. 攻撃者が自身のアカウントでログインし、APIキーを含むレスポンスを取得します。
  2. URLに特定の区切り文字(例:;)と静的ファイルの拡張子(例:.js)を追加し、キャッシュサーバーにレスポンスを保存させます。
  3. 被害者が同じURLにアクセスすると、そのレスポンスがキャッシュされ、攻撃者が被害者のAPIキーを取得できるようになります。

🛠️ 手順詳細

1. ターゲットエンドポイントの特定

  • Burpのブラウザでラボにアクセスし、wiener:peterでログインします。
  • /my-accountページにアクセスし、レスポンスに自身のAPIキーが含まれていることを確認します。

2. オリジンサーバーの区切り文字の特定

  • BurpのProxy > HTTP historyでGET /my-accountリクエストを右クリックし、「Send to Repeater」を選択します。

  • Repeaterでパスを/my-account/abcに変更し、リクエストを送信します。

    • 404 Not Foundが返されることを確認します。
  • パスを/my-accountabcに変更し、再度リクエストを送信します。

    • 同様に404 Not Foundが返されることを確認します。
  • このリクエストを右クリックし、「Send to Intruder」を選択します。

  • Intruderタブで、攻撃タイプを「Sniper」に設定し、パスを/my-account§§abcとします。

  • Payloadsタブで、PortSwiggerの区切り文字リストから以下の文字を追加します:

  ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
  • Payload encodingで「URL-encode these characters」のチェックを外します。

  • 「Start attack」をクリックし、攻撃を開始します。

  • ステータスコードで結果をソートし、;?200 OKを返し、他の文字が404 Not Foundを返すことを確認します。([PortSwigger][2])

3. キャッシュサーバーの挙動の確認

  • Repeaterでパスを/my-account?abc.jsに変更し、リクエストを送信します。

    • レスポンスにキャッシュの証拠がないことを確認します。
  • 同様に、パスを/my-account;abc.jsに変更し、リクエストを送信します。

    • レスポンスヘッダーにX-Cache: missが含まれていることを確認します。
  • 同じリクエストを再度送信し、X-Cache: hitに変わることを確認します。

    • これは、キャッシュサーバーが;を区切り文字として解釈せず、.js拡張子に基づいてレスポンスをキャッシュしていることを示します。

4. 攻撃用のURLの作成と実行

  • Burpのブラウザで「Go to exploit server」をクリックします。

  • Bodyセクションに以下のスクリプトを入力します(YOUR-LAB-IDは実際のラボIDに置き換えてください):

  <script>
    document.location="https://YOUR-LAB-ID.web-security-academy.net/my-account;wcd.js"
  </script>
  • 「Deliver exploit to victim」をクリックし、被害者にこのURLをアクセスさせます。

  • その後、以下のURLにアクセスし、被害者のAPIキーが含まれていることを確認します:

  https://YOUR-LAB-ID.web-security-academy.net/my-account;wcd.js
  • 取得したAPIキーをコピーし、ラボの「Submit solution」に貼り付けて提出します。([Medium][4])

🧠 攻撃成功のポイント

  • オリジンサーバーが;?を区切り文字として解釈し、パスを/my-accountとして処理する一方で、キャッシュサーバーはこれらを区切り文字とせず、.js拡張子に基づいてレスポンスをキャッシュするという挙動の違いを突いています。
  • このような挙動の違いにより、攻撃者は被害者の機密情報を含むレスポンスをキャッシュさせ、それを取得することが可能になります。

✅ まとめ

  • URLの区切り文字に対するオリジンサーバーとキャッシュサーバーの解釈の違いを悪用することで、Webキャッシュ・ディセプション攻撃が成立します。
  • このラボでは、;を区切り文字として使用し、.js拡張子を追加することで、被害者のAPIキーを含むレスポンスをキャッシュさせ、取得する手法を学びました。
  • このような攻撃を防ぐためには、キャッシュポリシーの適切な設定や、URLの正規化処理の一貫性を保つことが重要です。

Best regards, (^^ゞ