【ITニュース解説】“Day 29: The Web Cache Deception Heist — How I Stole Private Data Without Breaking a Single…

インターネットの仕組みを支える技術の一つに「キャッシュ」がある。Webサイトは、ユーザーがWebブラウザで特定のURLを入力すると、そのリクエストがインターネットを通じてWebサーバーに送られ、サーバーは要求された情報をWebブラウザに返送することで表示される。この一連の流れは通常、一瞬で終わるように設計されているが、毎回サーバーが同じ情報を生成して返送していると、サーバーの負荷が大きくなり、ユーザーの待ち時間も長くなる可能性がある。

そこで登場するのがキャッシュの仕組みである。キャッシュとは、一度取得した情報を一時的に保存しておき、次に同じ情報が要求された際に、サーバーに問い合わせることなく保存しておいた情報をすぐに提供する技術のことだ。これにより、Webサイトの表示速度が向上し、サーバーの負荷も軽減される。キャッシュは、Webブラウザの内部に保存されるブラウザキャッシュ、ISP（インターネットサービスプロバイダ）などが設置するプロキシキャッシュ、そしてWebサイトのコンテンツを高速配信するためのCDN（コンテンツデリバリーネットワーク）キャッシュなど、さまざまな場所で利用されている。今回の話題で重要になるのは、複数のユーザーで共有されるCDNなどの共有キャッシュの存在だ。

Web Cache Deception（ウェブキャッシュデセプション）は、このキャッシュの仕組み、特に共有キャッシュの動作とWebサーバーの応答の「解釈の違い」を悪用して、本来ならアクセスできないはずのプライベートな情報を盗み出す攻撃手法である。この攻撃は、既存のWebサイトのセキュリティ設定の不備や、Webサーバーとキャッシュサーバー間の通信プロトコルの解釈のずれを利用するため、従来のセキュリティ対策だけでは見過ごされやすい側面がある。

具体的に、この攻撃は次のような流れで進行する。まず、攻撃者は標的とするWebサイト内で、ログインしたユーザーのみがアクセスできる機密性の高い情報を含むページ、例えば「ユーザー設定」や「プロフィール」ページなどを見つける。そして、そのページのURLの末尾に、実際にはWebサーバー上に存在しない、かつ静的なファイル拡張子を持つファイル名を追加した、特別なURLを作成する。例えば、https://example.com/user/settings というページがあった場合、攻撃者はこれに存在しない画像ファイル名を追加して https://example.com/user/settings/nonexistent.png のようなURLを作成する。

次に、攻撃者はこの改ざんされたURLを、悪意のあるリンクとして、ログイン中の被害者ユーザーにクリックさせるよう誘導する。これは、フィッシングメールや悪意のあるWebサイトを通じて行われることが多い。被害者がこのリンクをクリックすると、被害者のWebブラウザから https://example.com/user/settings/nonexistent.png へのリクエストが発信される。

このリクエストは、途中の共有キャッシュサーバーを経由して、Webサイトのオリジンサーバーへと到達する。ここで攻撃が成立するかどうかの重要なポイントがある。オリジンサーバーは nonexistent.png というファイルは存在しないことを認識するが、多くのWebサーバーは、存在しないファイルへのリクエストであっても、その親ディレクトリにあたるパス（この例では /user/settings/）が存在し、かつユーザーがログインしている場合には、そのディレクトリに対応するページコンテンツ（HTML形式のユーザー設定ページ）を返してしまうことがあるのだ。このとき、サーバーは通常の 200 OK という成功のステータスコードを返す場合が多い。本来であれば、存在しないリソースへのリクエストに対しては 404 Not Found のようなエラーを返すのが望ましい。

Webサーバーから返された、被害者の機密情報を含むHTMLコンテンツは、共有キャッシュサーバーに到達する。キャッシュサーバーは、受け取ったコンテンツを、当初のリクエストURLである https://example.com/user/settings/nonexistent.png に紐付けてキャッシュに保存する。ここでキャッシュサーバーは、リクエストされたURLの末尾が .png であったことから、このコンテンツを画像ファイルのような「静的コンテンツ」として認識し、キャッシュ可能であると判断してしまうことがある。特に、Webサーバーがレスポンスヘッダに Cache-Control: public のような、誰でもキャッシュできることを示す指示を含めていた場合、この判断はより強固なものとなる。

キャッシュが完了すると、いよいよ攻撃者は機密データを窃取する段階に移る。攻撃者は、自分自身のWebブラウザから、被害者と同じURLである https://example.com/user/settings/nonexistent.png にアクセスする。すると、共有キャッシュサーバーは、すでにそのURLに紐付けられたコンテンツ（被害者の機密情報を含むHTMLページ）をキャッシュしているため、オリジンサーバーに問い合わせることなく、キャッシュされたコンテンツを攻撃者のブラウザに返してしまうのだ。これにより、攻撃者は被害者がログイン中にしか見られないはずの、名前、メールアドレス、設定情報などの機密データを、あたかも静的ファイルを取得するかのように簡単に手に入れることができてしまう。

この攻撃が成立する根本的な原因は、Webサーバーが存在しないファイルパスに対するリクエストに対して、不適切なコンテンツを返してしまう挙動と、キャッシュサーバーがリクエストされたURLの拡張子と、実際に返されたコンテンツのタイプ（HTMLか画像かなど）との不一致を十分に検証せず、キャッシュを生成してしまうことにある。また、ログインユーザー向けの機密コンテンツに対して Cache-Control: private ではなく public など、不適切なキャッシュ指示が設定されている場合も、脆弱性を悪化させる要因となる。

このWeb Cache Deception攻撃から身を守るための対策はいくつかある。最も重要なのは、Webサーバーの設定を見直し、存在しない静的ファイルパスへのリクエストに対しては、必ず 404 Not Found エラーを返すようにすることである。これにより、不適切なコンテンツがキャッシュされるのを防ぐことができる。また、機密情報を含む動的なコンテンツには、Cache-Control: no-store, no-cache, private といったHTTPヘッダを適切に設定し、共有キャッシュに保存されないように明確に指示することも不可欠だ。さらに、CDNやプロキシキャッシュサービスを利用している場合は、それらの設定でURLの拡張子と実際のコンテンツタイプが一致しない場合にキャッシュしない、といった詳細なルールを設定することも有効である。これらの対策を組み合わせることで、Web Cache Deceptionによるプライベートデータ窃取のリスクを大幅に低減できる。