Cache Poisoning and Cache Deception
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。 今すぐアクセスを取得:
違い
Webキャッシュ毒入れとWebキャッシュ欺瞞の違いは何ですか？
Webキャッシュ毒入れでは、攻撃者はアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、このコンテンツがキャッシュから他のアプリケーションユーザーに提供されます。
Webキャッシュ欺瞞では、攻撃者はアプリケーションに別のユーザーに属する機密コンテンツをキャッシュに保存させ、その後、このコンテンツをキャッシュから取得します。
キャッシュ毒入れ
キャッシュ毒入れは、クライアントサイドのキャッシュを操作して、クライアントが予期しない、部分的な、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の程度は、影響を受けるページの人気に依存します。なぜなら、汚染されたキャッシュ期間中にページを訪れるユーザーにのみ、汚染されたレスポンスが提供されるからです。
キャッシュ毒入れ攻撃の実行には、いくつかのステップが必要です:
キーのない入力の特定: これらは、リクエストがキャッシュされるために必要ではないが、サーバーから返されるレスポンスを変更できるパラメータです。これらの入力を特定することは重要です。なぜなら、これらはキャッシュを操作するために悪用される可能性があるからです。
キーのない入力の悪用: キーのない入力を特定した後、次のステップは、これらのパラメータをどのように悪用してサーバーのレスポンスを攻撃者に利益をもたらすように変更するかを理解することです。
毒入れされたレスポンスがキャッシュされていることを確認する: 最後のステップは、操作されたレスポンスがキャッシュに保存されるようにすることです。これにより、キャッシュが毒入れされている間に影響を受けるページにアクセスするユーザーは、汚染されたレスポンスを受け取ります。
発見: HTTPヘッダーをチェック
通常、レスポンスがキャッシュに保存されている場合、それを示すヘッダーがあります。どのヘッダーに注意を払うべきかを確認するには、この投稿を参照してください: HTTPキャッシュヘッダー。
発見: キャッシュエラーコードをチェック
レスポンスがキャッシュされていると思われる場合、不正なヘッダーを送信してみることができます。これにはステータスコード400が返されるはずです。その後、リクエストに通常アクセスして、レスポンスが400ステータスコードである場合、脆弱性があることがわかります（DoSを実行することもできます）。
詳細なオプションは次で見つけることができます:
pageCache Poisoning to DoSただし、この種のステータスコードがキャッシュされていない場合があるため、このテストは信頼できないかもしれません。
発見: キーのない入力を特定および評価
Param Minerを使用して、ページのレスポンスを変更する可能性のあるパラメータやヘッダーをブルートフォースすることができます。たとえば、ページがクライアントにそこからスクリプトを読み込むように指示するヘッダー X-Forwarded-For を使用しているかもしれません。
有害な応答をバックエンドサーバーから引き出す
特定されたパラメータ/ヘッダーを確認し、それがどのようにサニタイズされているか、どこで反映されているか、またはヘッダーからの応答にどのように影響を与えているかを確認します。それを悪用できますか（XSSを実行したり、自分が制御するJSコードをロードしたりしますか？DoSを実行しますか？...）
キャッシュされた応答を取得する
悪用できるページを特定し、どのパラメータ/ヘッダーを使用し、どのように悪用するかを特定したら、ページをキャッシュする必要があります。キャッシュされるリソースによっては、これには時間がかかる場合があり、数秒間試行する必要があるかもしれません。
応答のヘッダー**X-Cacheは非常に役立つ可能性があります。リクエストがキャッシュされていない場合は値がmissになり、キャッシュされている場合は値がhitになります。
ヘッダーCache-Controlも興味深い情報です。リソースがキャッシュされているかどうか、次にリソースが再度キャッシュされる予定の時間を知ることができます：Cache-Control: public, max-age=1800
もう1つの興味深いヘッダーはVaryです。このヘッダーは、通常はキーにならないヘッダーでも、キャッシュキーの一部として扱われる追加のヘッダーを示すことがよくあります。したがって、ユーザーがターゲットにしている被害者のUser-Agentを知っている場合、その特定のUser-Agentを使用しているユーザーのキャッシュを毒することができます。
キャッシュに関連するもう1つのヘッダーはAge**です。これは、オブジェクトがプロキシキャッシュに格納されている時間を秒単位で定義します。
リクエストをキャッシュする際には、使用するヘッダーに注意してください。いくつかのヘッダーは予期せぬ方法でキーとして使用される可能性があるため、被害者は同じヘッダーを使用する必要があります。常に異なるブラウザでキャッシュポイズニングをテストして機能しているかどうかを確認してください。
悪用の例
最も簡単な例
X-Forwarded-Forのようなヘッダーが、応答でサニタイズされずに反映されています。
基本的なXSSペイロードを送信し、ページにアクセスするすべてのユーザーがXSSを受けるようにキャッシュを毒すことができます：
注意：これは/enではなく/en?region=ukへのリクエストを毒化させます
DoSへのキャッシュ毒化
pageCache Poisoning to DoSクッキー処理の脆弱性を悪用するためのWebキャッシュ毒化の使用
クッキーはページのレスポンスにも反映される可能性があります。たとえば、XSSを引き起こすために悪用できる場合、悪意のあるキャッシュレスポンスを読み込む複数のクライアントでXSSを悪用することができます。
注意：脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリーニングします。
パス遍歴を使用したキャッシュ毒化によるAPIキーの盗難
この解説 によると、https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 のようなURLでOpenAI APIキーを盗むことが可能でした。なぜなら、/share/* に一致するものはCloudflareがURLを正規化せずにキャッシュするため、Webサーバーにリクエストが到達したときに行われたからです。
複数のヘッダーを使用してWebキャッシュ毒化の脆弱性を悪用する
時には、複数の未キー入力を悪用してキャッシュを悪用する必要があります。たとえば、X-Forwarded-Host を自分が制御するドメインに設定し、X-Forwarded-Scheme を http に設定すると、Open redirect を見つけることができます。サーバーがすべてのHTTPリクエストをHTTPSに転送し、リダイレクトのドメイン名としてヘッダー X-Forwarded-Scheme を使用している場合、リダイレクト先を制御できます。
限られた Vary ヘッダーを利用した攻撃
Vary ヘッダーを利用した攻撃もし、X-Host ヘッダーがドメイン名を表すために使用されているが、レスポンスの Vary ヘッダーが User-Agent を示している場合、被害者の User-Agent を外部に送信し、そのユーザーエージェントを使用してキャッシュを改ざんする方法を見つける必要があります。
Fat Get
GETリクエストを送信し、リクエストをURLとボディの両方に含めます。ウェブサーバーがボディからのパラメータを使用する場合でも、キャッシュサーバーがURLからのパラメータをキャッシュすると、そのURLにアクセスする誰もが実際にはボディからのパラメータを使用します。GitHubウェブサイトでJames Kettleが見つけた脆弱性のように。
パラメータクローキング
たとえば、& の代わりに ; 文字を使用して、ruby サーバーで パラメータ を分離することが可能です。これは、キー付きのパラメータ値をキーのないものの内部に配置し、それらを悪用するために使用できます。
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
HTTP リクエストスマグリングを悪用して HTTP キャッシュポイズニングを行う
HTTP リクエストスマグリングを悪用してキャッシュポイズニング攻撃を実行する方法についてこちらで学びます。
Web キャッシュポイズニングの自動テスト
Web キャッシュ脆弱性スキャナーを使用して、Web キャッシュポイズニングの自動テストを実行できます。多くの異なる技術をサポートし、高度にカスタマイズ可能です。
使用例: wcvs -u example.com
Trickestを使用して、世界で最も高度なコミュニティツールによって強化された ワークフローを簡単に構築 および 自動化 できます。 今すぐアクセスしてください:
脆弱な例
Apache Traffic Server (CVE-2021-27577)
ATS は URL 内のフラグメントを削除せずに転送し、キャッシュキーをホスト、パス、クエリのみを使用して生成しました（フラグメントを無視）。そのため、リクエスト /#/../?r=javascript:alert(1) はバックエンドに /#/../?r=javascript:alert(1) として送信され、キャッシュキーにはペイロードが含まれず、ホスト、パス、クエリのみが含まれていました。
GitHub CP-DoS
content-type ヘッダーに誤った値を送信すると、405 キャッシュ応答がトリガーされました。キャッシュキーにはクッキーが含まれていたため、認証されていないユーザーのみを攻撃することが可能でした。
GitLab + GCP CP-DoS
GitLab は静的コンテンツを保存するために GCP バケットを使用していました。GCP バケット は x-http-method-override ヘッダーをサポートしていました。そのため、ヘッダー x-http-method-override: HEAD を送信し、キャッシュを毒化して空の応答本体を返すことが可能でした。また、メソッド PURGE もサポートしていました。
Rack Middleware (Ruby on Rails)
Ruby on Rails アプリケーションでは、Rack ミドルウェアがよく利用されます。Rack コードの目的は、x-forwarded-scheme ヘッダーの値を取得し、リクエストのスキームとして設定することです。ヘッダー x-forwarded-scheme: http が送信されると、同じ場所への 301 リダイレクトが発生し、そのリソースへのサービス拒否（DoS）を引き起こす可能性があります。さらに、アプリケーションは X-forwarded-host ヘッダーを認識し、ユーザーを指定されたホストにリダイレクトするかもしれません。この動作は、攻撃者のサーバーから JavaScript ファイルを読み込む可能性があり、セキュリティリスクを引き起こす可能性があります。
403 およびストレージバケット
Cloudflare は以前、403 応答をキャッシュしていました。不正な Authorization ヘッダーで S3 または Azure Storage Blobs にアクセスしようとすると、403 応答がキャッシュされました。Cloudflare は 403 応答のキャッシュを停止しましたが、この動作は他のプロキシサービスにまだ存在する可能性があります。
キー付きパラメータの注入
キャッシュには、キャッシュキーに特定の GET パラメータが含まれることがよくあります。たとえば、Fastly の Varnish はリクエストの size パラメータをキャッシュしました。ただし、URL エンコードされたパラメータのバージョン（たとえば、siz%65）が誤った値で送信された場合、キャッシュキーは正しい size パラメータを使用して構築されます。しかし、バックエンドは URL エンコードされたパラメータの値を処理します。2 番目の size パラメータを URL エンコードすると、キャッシュには省略されますが、バックエンドには利用されます。このパラメータに値 0 を割り当てると、キャッシュ可能な 400 Bad Request エラーが発生します。
ユーザーエージェントルール
一部の開発者は、サーバー負荷を管理するために、高トラフィックツール（FFUF や Nuclei など）と一致するユーザーエージェントを持つリクエストをブロックします。皮肉なことに、このアプローチはキャッシュポイズニングや DoS などの脆弱性を導入する可能性があります。
不正なヘッダーフィールド
RFC7230 はヘッダー名に許容される文字を指定しています。指定された tchar 範囲外の文字を含むヘッダーは理想的には 400 Bad Request 応答をトリガーするはずです。実際には、サーバーは常にこの標準に従うわけではありません。Akamai などが、cache-control ヘッダーが存在しない限り、無効な文字を含むヘッダーを転送し、キャッシュ可能な 400 Bad Request エラーをキャッシュするパターンが特定されました。\ のような無効な文字を含むヘッダーを送信すると、キャッシュ可能な 400 Bad Request エラーが発生します。
新しいヘッダーの検出
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
キャッシュデセプション
キャッシュデセプションの目標は、クライアントが キャッシュに保存されるリソースを、それらの機密情報を持つまま 読み込むようにすることです。
まず、.css、.js、.png などの 拡張子 は通常、キャッシュに保存 されるように 構成 されています。したがって、www.example.com/profile.php/nonexistent.js にアクセスすると、.js 拡張子 が見えるため、キャッシュはおそらく応答を保存します。しかし、アプリケーション が www.example.com/profile.php に保存されている 機密 ユーザー内容を再生している場合、他のユーザーからその内容を 盗む ことができます。
他にテストすること:
www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
.avifなどのあまり知られていない拡張子を使用
別の非常に明確な例は、この解説で見つけることができます: https://hackerone.com/reports/593712。 この例では、http://www.example.com/home.php/non-existent.css のような存在しないページを読み込むと、http://www.example.com/home.php の内容（ユーザーの機密情報を含む）が返され、キャッシュサーバーが結果を保存します。 その後、攻撃者 は自分のブラウザで http://www.example.com/home.php/non-existent.css にアクセスし、以前にアクセスしたユーザーの 機密情報 を観察することができます。
キャッシュプロキシ は、ファイルを 拡張子 に基づいてキャッシュするように 構成 されている必要があることに注意してください（.css）。例では、http://www.example.com/home.php/non-existent.css は text/html コンテンツタイプではなく、text/css MIME タイプ（.css ファイルの期待されるタイプ）になります。HTTP リクエストスマグリングを悪用してキャッシュデセプション攻撃を実行する方法についてこちらで学びます。
自動ツール
toxicache: Golangスキャナーは、URLのリスト内でWebキャッシュ毒性の脆弱性を見つけ、複数のインジェクション技術をテストします。
参考文献
Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。 今すぐアクセスしてください：
Last updated
