「Gotta cache 'em all」—Webキャッシュ攻撃の“ルール曲げ”とCDN時代の新しい落とし穴

本記事は、PortSwigger Researchが公開した研究「Gotta cache 'em all: bending the rules of web cache exploitation」（以下、元ソース）を基にまとめています。補足は、同サイト上の関連研究ページおよび関連講演（YouTube）に限って参照します。citeturn0

概要

Webキャッシュは、レスポンスを保存して再利用することで高速化や負荷軽減に寄与します。一方で、キャッシュが「どのリクエストを同一とみなし、どのレスポンスを再配布してよいか」を誤って判断すると、意図しない利用者にコンテンツが配られたり、攻撃者が混入させた内容が長く残ったりします。元ソースは、過去から観測されてきたキャッシュ悪用の流れを踏まえつつ、CDNの普及に伴って“製品や構成要素ごとの挙動差”が増えたことで、新しい攻撃面（あるいは既存手法の拡張）が生まれる点に焦点を当てています。citeturn0

特に重要なのは、オリジンサーバ、CDN/キャッシュ、プロキシ、そしてクライアントの間で、URL・パス・クエリ・ヘッダ等の解釈が完全には一致しないことがある、という現実です。攻撃は多くの場合、この「解釈のズレ」を“ルールの曲げどころ”として利用します。キャッシュの鍵（cache key）の作り方、正規化の有無、ヘッダの扱い、どの条件で保存・再利用されるか（あるいはされないか）といった細部が、実運用の中では機器・設定・ネットワーク境界ごとに分断されやすいからです。citeturn0

詳細

元ソースが示唆する中心的な観点は、「キャッシュの世界では“正しさ”が一つではない」という点です。たとえば同じ見た目のリクエストでも、ある層では同一扱い（同じキャッシュ項目にヒット）になり、別の層では別物扱い（ミスヒットや別キーとして保存）になることがあります。逆に、別物であるべきリクエストが同一扱いされれば、ユーザーごとに分離されるべき情報が混線しうる、という危険が生まれます。元ソースの問題提起は、CDNが前段に入る現代のWebでは、こうした層の追加と最適化の積み重ねが避けがたく、結果として“ズレの組み合わせ”が増える、という構図にあります。citeturn0

関連研究として挙げられている「Web Cache Entanglement」は、キャッシュ汚染（poisoning）に至る経路が単純な一発勝負ではなく、複数の挙動や経路が絡み合うことで成立し得る、という方向性の問題意識を示しています。ここで重要なのは、単一コンポーネントの仕様理解だけでは不十分になりやすく、境界ごとの“解釈・正規化・優先順位”を横断して検証しないと、想定外の結び目（entanglement）が残る可能性がある点です。citeturn1

また、PortSwigger ResearchはHTTP/2やHTTP/1.1に関する別研究も公開しており、プロトコルや実装差がセキュリティ上の複雑性を生みやすいという文脈を補強しています。キャッシュ攻撃も同様に、HTTPメッセージの扱い方・中継機器の最適化・後方互換のための挙動などが、意図せず攻撃者に都合のよい差分として現れることがあります。元ソースを読む際には、「CDN/キャッシュの仕様」だけでなく、その前後にあるHTTPスタック全体の前提差を疑う視点が有用です。citeturn2turn3

さらに、YouTube上の講演「Gotta Cache Em All: Bending the Rules of Web Cache Exploitation」では、HTTPサーバとキャッシュプロキシの間にある解釈差を悪用して、機微情報の取得につなげ得るという趣旨が述べられています。研究論文での主張を、実際の攻撃ストーリーとして理解する助けになるため、実務者にとっては“どこでズレが生じ、どのタイミングで再配布が起きるのか”をイメージしやすい補助線になります。citeturn4

防御の考え方としては、(1) キャッシュ境界での正規化とキー設計を明文化し、(2) 認証・個別化されたコンテンツが誤って共有キャッシュに載らないよう前提を揃え、(3) 実際のCDN/リバースプロキシ/アプリの組み合わせで“同一性判定”が一致しているかを検証する、という整理が現実的です。元ソースと関連研究が示す通り、攻撃は「単体の誤設定」だけでなく「部品間のズレ」からも生まれ得るため、点検対象を機器単体ではなく経路全体に広げることが要点になります。citeturn0turn1