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

Reading time: 8 minutes

これは、キャッシュプロキシとウェブサーバー間の不一致を悪用してキャッシュポイズニング攻撃を実行するために提案された技術の概要です abusing discrepancies between cache proxies and web servers.

デリミタ

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を正規化します。
• プロセス: パスデリミタを特定し、文字をデコードしてドットセグメントを削除することによってパスを抽出し、正規化します。

エンコーディング

Nginx、Node、CloudFrontのような異なるHTTPサーバーやプロキシは、デリミタを異なる方法でデコードするため、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 に応答することがあります。