mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
53 lines
6.5 KiB
Markdown
53 lines
6.5 KiB
Markdown
# URLの不一致によるキャッシュポイズニング
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
これは、キャッシュプロキシとウェブサーバー間の不一致を悪用してキャッシュポイズニング攻撃を実行するために提案された技術の概要です **キャッシュポイズニング攻撃を実行するための技術の概要です。**
|
||
|
||
> [!NOTE]
|
||
> この攻撃の目的は、**キャッシュサーバーに静的リソースが読み込まれていると誤認させること**です。これにより、キャッシュサーバーはパスの一部をキャッシュキーとして保存しながらキャッシュしますが、ウェブサーバーは別のパスを解決して応答します。ウェブサーバーは、ユーザーに関する機密情報や、XSSのような悪意のあるペイロード、または攻撃者のウェブサイトからJSファイルを読み込むためのリダイレクトを含む動的ページを読み込む実際のパスを解決します。
|
||
|
||
## デリミタ
|
||
|
||
**URLデリミタ**はフレームワークやサーバーによって異なり、リクエストのルーティングや応答の処理に影響を与えます。一般的なオリジンデリミタには以下があります：
|
||
|
||
- **セミコロン**: Springでマトリックス変数に使用されます（例: `/hello;var=a/world;var1=b;var2=c` → `/hello/world`）。
|
||
- **ドット**: Ruby on Railsで応答形式を指定します（例: `/MyAccount.css` → `/MyAccount`）。
|
||
- **ヌルバイト**: OpenLiteSpeedでパスを切り詰めます（例: `/MyAccount%00aaa` → `/MyAccount`）。
|
||
- **ニューラインバイト**: NginxでURLコンポーネントを分離します（例: `/users/MyAccount%0aaaa` → `/account/MyAccount`）。
|
||
|
||
このプロセスに従って他の特定のデリミタが見つかるかもしれません：
|
||
|
||
- **ステップ1**: キャッシュ不可のリクエストを特定し、それを使用して潜在的なデリミタを含むURLがどのように処理されるかを監視します。
|
||
- **ステップ2**: パスにランダムなサフィックスを追加し、サーバーの応答を比較して、文字がデリミタとして機能するかどうかを判断します。
|
||
- **ステップ3**: ランダムなサフィックスの前に潜在的なデリミタを導入し、応答が変わるかどうかを確認して、デリミタの使用を示します。
|
||
|
||
## 正規化とエンコーディング
|
||
|
||
- **目的**: キャッシュサーバーとオリジンサーバーの両方のURLパーサーは、エンドポイントマッピングとキャッシュキーのためにパスを抽出するためにURLを正規化します。
|
||
- **プロセス**: パスデリミタを特定し、文字をデコードしてドットセグメントを削除することによってパスを抽出し、正規化します。
|
||
|
||
### **エンコーディング**
|
||
|
||
異なるHTTPサーバーやプロキシ（Nginx、Node、CloudFrontなど）は、デリミタを異なる方法でデコードするため、CDNやオリジンサーバー間で不一致が生じる可能性があります。例えば、ウェブサーバーがこの変換を行う場合 `/myAccount%3Fparam` → `/myAccount?param` ですが、キャッシュサーバーがキーとしてパス `/myAccount%3Fparam` を保持している場合、不一致が生じます。 
|
||
|
||
これらの不一致を確認する方法は、パスをエンコーディングなしで読み込んだ後、異なる文字をURLエンコーディングしてリクエストを送信し、エンコードされたパスの応答がキャッシュされた応答から来たかどうかを確認することです。
|
||
|
||
### ドットセグメント
|
||
|
||
ドットが関与するパスの正規化は、キャッシュポイズニング攻撃にとって非常に興味深いものです。例えば、`/static/../home/index` や `/aaa..\home/index` の場合、一部のキャッシュサーバーはこれらのパスをそれ自体をキーとしてキャッシュしますが、他のサーバーはパスを解決し `/home/index` をキャッシュキーとして使用するかもしれません。\
|
||
以前と同様に、これらのリクエストを送信し、応答がキャッシュから取得されたかどうかを確認することで、`/home/index` に対する応答がこれらのパスがリクエストされたときに送信された応答であるかどうかを特定するのに役立ちます。
|
||
|
||
## 静的リソース
|
||
|
||
いくつかのキャッシュサーバーは、応答が静的として識別される場合、常に応答をキャッシュします。これは以下の理由によるかもしれません：
|
||
|
||
- **拡張子**: Cloudflareは、以下の拡張子を持つファイルを常にキャッシュします: 7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx
|
||
- デリミタと静的拡張子を使用して動的応答をキャッシュに強制することが可能で、例えば `/home$image.png` へのリクエストは `/home$image.png` をキャッシュし、オリジンサーバーは `/home` で応答します。
|
||
- **よく知られた静的ディレクトリ**: 以下のディレクトリには静的ファイルが含まれているため、その応答はキャッシュされるべきです: /static, /assets, /wp-content, /media, /templates, /public, /shared
|
||
- デリミタ、静的ディレクトリ、ドットを使用して動的応答をキャッシュに強制することが可能で、例えば `/home/..%2fstatic/something` は `/static/something` をキャッシュし、応答は `/home` になります。
|
||
- **静的ディレクトリ + ドット**: `/static/..%2Fhome` へのリクエストや `/static/..%5Chome` へのリクエストはそのままキャッシュされるかもしれませんが、応答は `/home` かもしれません。
|
||
- **静的ファイル**: `/robots.txt`、`/favicon.ico`、および `/index.html` のような特定のファイルは常にキャッシュされます。これらは `/home/..%2Frobots.txt` のように悪用される可能性があり、キャッシュは `/robots.txt` を保存し、オリジンサーバーは `/home` に応答します。
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|