URLの不一致によるキャッシュポイズニング

{% hint style="success" %} AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！
**💬 DiscordグループまたはTelegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

{% endhint %}

これは、キャッシュプロキシとウェブサーバー間の不一致を悪用してキャッシュポイズニング攻撃を実行するために提案された技術の要約です。https://portswigger.net/research/gotta-cache-em-all

{% hint style="info" %} この攻撃の目的は、キャッシュサーバーに静的リソースが読み込まれていると誤認させることです。これにより、キャッシュサーバーはパスの一部をキャッシュキーとして保存し、ウェブサーバーは別のパスを解決して応答します。ウェブサーバーは、ユーザーに関する機密情報や、XSSのような悪意のあるペイロード、または攻撃者のウェブサイトからJSファイルを読み込むためのリダイレクトを含む動的ページを読み込む実際のパスを解決します。 {% endhint %}

デリミタ

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に応答します。