mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
231 lines
21 KiB
Markdown
231 lines
21 KiB
Markdown
# キャッシュポイズニングとキャッシュデセプション
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
## 違い
|
||
|
||
> **ウェブキャッシュポイズニングとウェブキャッシュデセプションの違いは何ですか？**
|
||
>
|
||
> - **ウェブキャッシュポイズニング**では、攻撃者がアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツが他のアプリケーションユーザーに提供されます。
|
||
> - **ウェブキャッシュデセプション**では、攻撃者がアプリケーションに他のユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者がそのコンテンツをキャッシュから取得します。
|
||
|
||
## キャッシュポイズニング
|
||
|
||
キャッシュポイズニングは、クライアント側のキャッシュを操作して、クライアントが予期しない、部分的、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の程度は、影響を受けるページの人気に依存し、汚染された応答はキャッシュ汚染の期間中にそのページを訪れるユーザーにのみ提供されます。
|
||
|
||
キャッシュポイズニング攻撃の実行にはいくつかのステップがあります：
|
||
|
||
1. **キーのない入力の特定**：これらは、リクエストがキャッシュされるために必要ではないパラメータですが、サーバーが返す応答を変更する可能性があります。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。
|
||
2. **キーのない入力の悪用**：キーのない入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーの応答を変更するためにこれらのパラメータをどのように誤用するかを考えることです。
|
||
3. **汚染された応答がキャッシュされることを確認**：最終ステップは、操作された応答がキャッシュに保存されることを確認することです。これにより、キャッシュが汚染されている間に影響を受けるページにアクセスするユーザーは、汚染された応答を受け取ります。
|
||
|
||
### 発見：HTTPヘッダーを確認
|
||
|
||
通常、**キャッシュに保存された**応答には、**それを示すヘッダーが存在します**。どのヘッダーに注意を払うべきかは、この投稿で確認できます：[**HTTPキャッシュヘッダー**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。
|
||
|
||
### 発見：キャッシュエラーコード
|
||
|
||
応答がキャッシュに保存されていると考えている場合、**不正なヘッダーでリクエストを送信**してみることができます。これには、**ステータスコード400**で応答されるべきです。その後、リクエストに通常アクセスして、**応答が400ステータスコードであれば**、それが脆弱であることがわかります（さらにはDoS攻撃を実行することも可能です）。
|
||
|
||
さらにオプションを見つけることができます：
|
||
|
||
{{#ref}}
|
||
cache-poisoning-to-dos.md
|
||
{{#endref}}
|
||
|
||
ただし、**これらの種類のステータスコードがキャッシュされないこともある**ため、このテストは信頼できない可能性があります。
|
||
|
||
### 発見：キーのない入力を特定し評価する
|
||
|
||
[**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`
|
||
|
||
もう一つの興味深いヘッダーは**`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."><script>alert(1)</script>"
|
||
```
|
||
_Note that this will poison a request to `/en?region=uk` not to `/en`_
|
||
|
||
### Cache poisoning to DoS
|
||
|
||
{{#ref}}
|
||
cache-poisoning-to-dos.md
|
||
{{#endref}}
|
||
|
||
### 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"
|
||
```
|
||
注意してください。脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリアします。
|
||
|
||
### デリミタ、正規化、ドットを使用して不一致を生成する <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||
|
||
確認してください：
|
||
|
||
{{#ref}}
|
||
cache-poisoning-via-url-discrepancies.md
|
||
{{#endref}}
|
||
|
||
### 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を正規化することはなく、リクエストがウェブサーバーに到達したときに行われました。
|
||
|
||
これは以下でもより詳しく説明されています：
|
||
|
||
{{#ref}}
|
||
cache-poisoning-via-url-discrepancies.md
|
||
{{#endref}}
|
||
|
||
### 複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する <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`に設定すると、**オープンリダイレクト**を見つけることができるかもしれません。**もし**サーバーがすべての**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リクエストスマグリングを悪用して攻撃する
|
||
|
||
[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning)の実施方法についてここで学びます。
|
||
|
||
### Web Cache Poisoningの自動テスト
|
||
|
||
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、Webキャッシュポイズニングの自動テストを行うことができます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。
|
||
|
||
使用例: `wcvs -u example.com`
|
||
|
||
## 脆弱な例
|
||
|
||
### 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`**拡張子**を見てレスポンスを保存します。しかし、**アプリケーション**が_swww.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`コンテンツタイプを持ちます。
|
||
|
||
[Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception)の実施方法についてここで学びます。
|
||
|
||
## 自動ツール
|
||
|
||
- [**toxicache**](https://github.com/xhzeem/toxicache): URLのリスト内でWebキャッシュポイズニングの脆弱性を見つけ、複数の注入技術をテストするための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/)
|
||
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|