Cache Poisoning and Cache Deception
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
Trickestを使用して、世界で最も高度なコミュニティツールによって駆動されるワークフローを簡単に構築し、自動化します。 今すぐアクセスを取得：
違い
ウェブキャッシュポイズニングとウェブキャッシュデセプションの違いは何ですか？
ウェブキャッシュポイズニングでは、攻撃者がアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツが他のアプリケーションユーザーに提供されます。
ウェブキャッシュデセプションでは、攻撃者がアプリケーションに他のユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者がそのコンテンツをキャッシュから取得します。
キャッシュポイズニング
キャッシュポイズニングは、クライアント側のキャッシュを操作して、クライアントが予期しない、部分的、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の程度は、影響を受けるページの人気に依存します。汚染された応答は、キャッシュ汚染の期間中にページを訪れるユーザーにのみ提供されます。
キャッシュポイズニング攻撃の実行には、いくつかのステップが含まれます：
未キー入力の特定：これらは、リクエストがキャッシュされるために必要ではないパラメータですが、サーバーが返す応答を変更する可能性があります。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。
未キー入力の悪用：未キー入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーの応答を変更するためにこれらのパラメータを誤用する方法を見つけることです。
汚染された応答がキャッシュされることを確認：最終ステップは、操作された応答がキャッシュに保存されることを確認することです。これにより、キャッシュが汚染されている間に影響を受けるページにアクセスするユーザーは、汚染された応答を受け取ります。
発見：HTTPヘッダーを確認
通常、応答がキャッシュに保存された場合、それを示すヘッダーが存在します。どのヘッダーに注意を払うべきかは、この投稿で確認できます：HTTPキャッシュヘッダー。
発見：キャッシュエラーコード
応答がキャッシュに保存されていると考えている場合、不正なヘッダーでリクエストを送信してみることができます。これにはステータスコード400で応答されるべきです。その後、リクエストに通常アクセスして、応答が400ステータスコードであれば、それが脆弱であることがわかります（さらにはDoSを実行することもできます）。
さらにオプションを見つけることができます：
Cache Poisoning to DoSただし、時々これらの種類のステータスコードはキャッシュされないため、このテストは信頼できない可能性があります。
発見：未キー入力を特定し評価する
Param Minerを使用して、ページの応答を変更する可能性のあるパラメータやヘッダーをブルートフォースすることができます。たとえば、ページがX-Forwarded-Forヘッダーを使用してクライアントにスクリプトをそこから読み込むように指示している場合：
バックエンドサーバーから有害な応答を引き出す
パラメータ/ヘッダーが特定されたら、それがどのようにサニタイズされているか、どこでそれが反映されているか、またはヘッダーからの応答に影響を与えているかを確認します。何らかの方法で悪用できますか（XSSを実行する、またはあなたが制御するJSコードを読み込む？DoSを実行する？...）
応答をキャッシュさせる
悪用できるページを特定し、使用するパラメータ/ヘッダーとどのように悪用するかが分かったら、そのページをキャッシュさせる必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。
応答のヘッダー**X-Cacheは非常に役立つ可能性があります。リクエストがキャッシュされていない場合は値がmissになり、キャッシュされている場合は値がhitになります。
ヘッダーCache-Control**も、リソースがキャッシュされているかどうか、次にリソースが再キャッシュされるのはいつかを知るために興味深いです：Cache-Control: public, max-age=1800
もう一つの興味深いヘッダーは**Varyです。このヘッダーは、通常はキーがない場合でも、キャッシュキーの一部として扱われる追加のヘッダーを示す**ためにしばしば使用されます。したがって、ターゲットとしている被害者のUser-Agentを知っている場合、特定のUser-Agentを使用しているユーザーのためにキャッシュを汚染することができます。
キャッシュに関連するもう一つのヘッダーは**Age**です。これは、オブジェクトがプロキシキャッシュに存在している秒数を定義します。
リクエストをキャッシュする際は、使用するヘッダーに注意してください。いくつかのヘッダーは予期せずにキーとして使用される可能性があり、被害者はその同じヘッダーを使用する必要があります。常に異なるブラウザでキャッシュポイズニングをテストして、機能しているか確認してください。
悪用の例
最も簡単な例
X-Forwarded-Forのようなヘッダーが、サニタイズされずに応答に反映されています。
基本的なXSSペイロードを送信し、キャッシュを汚染することで、ページにアクセスするすべての人がXSSされることになります：
Note that this will poison a request to /en?region=uk not to /en
Cache poisoning to DoS
Cache Poisoning to DoSUsing web cache poisoning to exploit cookie-handling vulnerabilities
クッキーはページのレスポンスに反映されることもあります。これを悪用してXSSを引き起こすことができれば、悪意のあるキャッシュレスポンスを読み込む複数のクライアントでXSSを利用できる可能性があります。
注意してください。脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリーニングします。
デリミタ、正規化、ドットを使用して不一致を生成する
確認してください：
Cache Poisoning via URL discrepanciesAPIキーを盗むためのパストラバーサルによるキャッシュポイズニング
このレポートは https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 のようなURLでOpenAI APIキーを盗むことが可能だった理由を説明しています。/share/* に一致するものはすべてキャッシュされ、リクエストがウェブサーバーに到達したときにCloudflareがURLを正規化しなかったためです。
これは以下でもより詳しく説明されています：
Cache Poisoning via URL discrepancies複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する
時には、キャッシュを悪用するために複数のキーなし入力を悪用する必要があります。例えば、X-Forwarded-Hostをあなたが制御するドメインに設定し、X-Forwarded-Schemeをhttpに設定すると、オープンリダイレクトを見つけることができるかもしれません。もしサーバーがすべてのHTTPリクエストをHTTPSに転送し、リダイレクトのドメイン名としてヘッダーX-Forwarded-Schemeを使用している場合、リダイレクトによってページが指し示す場所を制御できます。
限定された Vary ヘッダーを利用した攻撃
Vary ヘッダーを利用した攻撃もし X-Host ヘッダーが JSリソースを読み込むためのドメイン名 として使用されているが、レスポンスの Vary ヘッダーが User-Agent を示している場合、被害者の User-Agent を抽出し、そのユーザーエージェントを使用してキャッシュを汚染する方法を見つける必要があります。
Fat Get
URLとボディの両方にリクエストを含むGETリクエストを送信します。ウェブサーバーがボディのものを使用するが、キャッシュサーバーがURLのものをキャッシュする場合、そのURLにアクセスする誰もが実際にはボディからのパラメータを使用します。James KettleがGithubウェブサイトで見つけた脆弱性のように：
There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get
パラメータクロッキング
例えば、パラメータをrubyサーバーで**&の代わりに;**文字を使用して分離することが可能です。これを利用して、キーのないパラメータ値をキーのあるものの中に入れ込み、悪用することができます。
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
HTTPリクエストスムージングを悪用したHTTPキャッシュポイズニングの悪用
HTTPリクエストスムージングを悪用したキャッシュポイズニング攻撃の実行方法について学びましょう。
ウェブキャッシュポイズニングの自動テスト
Web Cache Vulnerability Scannerを使用して、ウェブキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。
使用例: wcvs -u example.com
脆弱な例
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ミドルウェア（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エラーをキャッシュすることです。不正な文字（例:\）を含むヘッダーを送信すると、キャッシュ可能な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_は、_.css_ファイルに期待されるtext/css MIMEタイプの代わりにtext/htmlコンテンツタイプを持ちます。
HTTPリクエストスムージングを悪用したキャッシュデセプション攻撃の実行方法について学びましょう。
自動ツール
toxicache: URLのリスト内でウェブキャッシュポイズニングの脆弱性を見つけ、複数の注入技術をテストするためのGolangスキャナー。
参考文献
Trickestを使用して、世界で最も高度なコミュニティツールによって駆動されるワークフローを簡単に構築し、自動化します。 今すぐアクセスを取得：
