2025年5月16日

NECサイバーセキュリティ技術統括部セキュリティ技術センターの中島です。
本記事では、Webセキュリティのオンライントレーニングサイトである“PortSwigger Web Security Academy” [1]のWeb Cache Deceptionに関するLabから1問、Write-upを紹介します。注意：本ブログの情報を用いた活動は、必ず自らの責任によって行ってください。本ブログの内容を使用したことによって発生する不利益等について、筆者および関係者はいかなる責任も負いません。

目次

Web Security Academyとは

“Web Security Academy”はPortSwigger社が公開しているオンラインのWeb Securityトレーニングサイトです。脆弱性に関する説明や教科書的位置づけの「Learning Material」と、脆弱性を含んだ演習環境である「Lab」が用意されており、無料で学ぶことができます。また、Labを通して、PortSwigger社が提供しているローカルプロキシツールであるBurpSuite [2]の使い方も実践的に学ぶことができます。

2025年5月6日現在では、31のトピックと269のラボが提供されています。
新しいコンテンツが公開された際には、公式のTwitter（@WebSecAcademy）[3]で紹介されるのでフォローしておくと良いかと思います。

Web Cache Deceptionとは

Labの解説に入る前に、Web Cache Deceptionについて簡単に触れておきます。
Web Cache Deceptionとは、本来キャッシュすべきではない機密情報がキャッシュサーバーに保存されるよう攻撃者に誘導されてしまう脆弱性です。この脆弱性は、キャッシュサーバーとオリジンサーバーの間でリクエストを処理する際の方法に不一致があることにより発生します。
2024年には、ChatGPTにおけるWeb Cache Deceptionの脆弱性が報告されました [4]。この事例では、パストラバーサルを組み合わせることでキャッシュルールのスコープをバイパスすることが可能な脆弱性でした。これにより、ユーザーの認証トークンが漏えいする可能性がありました。
Web Cache Deceptionについては、Web Security Academyのトピックに詳しくまとまっていますので、ご確認ください [5]。

Lab: Exploiting origin server normalization for web cache deception

本記事では、「Web Cache Deception」より「Exploiting origin server normalization for web cache deception」[6]というLabを紹介します。

本ラボはWeb Cache Deceptionの脆弱性を利用し、ユーザーCarlosに紐づくAPIキーを取得することでクリアとなります。
問題文ではユーザー`wiener`のクレデンシャル情報が提供されています。

まず、Labへのアクセスボタンを押すと、LabのURLが提供されます。与えられたURLにアクセスすると、ブログサイトであることが分かりました。

続いて、wienerアカウントを用いてログインページからログインを行います。

ログイン後、アカウントページにAPIキーが表示されることが確認できます。

`/my-account`にアクセスする際の通信をBurpで確認します。

`/my-account`内で参照されている静的リソースは`/resources`配下にあり、`X-Cache`ヘッダーから、これらがキャッシュ対象であり、また、このヘッダーの値が`hit`であるため、キャッシュされた情報が返ってきていることが分かります。

ここで、CarlosのAPIキーを取得するためには、Carlosが`/my-account`にアクセスした際のレスポンスをキャッシュサーバーに保存させ、そのキャッシュにアクセスする必要があります。この前提のもと、以下のような方針を立てます。

まずはパスの区切り文字を調査します。クエリ文字`?`を挿入したパスのみが、APIキーを含むレスポンスを返すことを確認しました。

続いて、`/resources/..%2fmy-account`にアクセスすると、APIキーが含まれたレスポンスが返されます。`X-Cache`ヘッダーの値は`miss`であり、まだ情報がキャッシュサーバーに保存されていないことが確認できます。

このURLに再度アクセスすると、`X-Cache`ヘッダーの値が`hit`となり、キャッシュサーバーに保存された情報が返されたことが確認できます。

上記のように、オリジンサーバーは`/resources/..%2fmy-account`を正規化して`/my-account`として処理している一方、キャッシュサーバーではこのパスを別の静的なリソースとみなしてキャッシュしていることがわかります。
URLパスの解釈がオリジンサーバーとキャッシュサーバーで異なることが分かったので、Carlos（bot）に踏ませるためのエクスプロイトを以下のように作成します。

作成したエクスプロイトを攻撃者サーバーの罠ページとして用意します。

「Deliver exploit to victim」をクリックすると、Carlos（bot）が用意した攻撃者のURLにアクセスし、レスポンスがキャッシュサーバーに保存されます。

Carlos（bot）に踏ませたURLにアクセスし、キャッシュされたレスポンスを確認します。

レスポンスに含まれるCarlosのAPIキーを送信すると、Labをクリアした旨が表示されます。

なお、本脆弱性の対策としては、動的コンテンツに対して`Cache-Control: no-store, private`を設定し、コンテンツがキャッシュされないよう明示することが有効です。

おわりに

本記事では、PortSwigger Web Security AcademyよりWeb Cache Deception に関するLab１問を紹介いたしました。実環境においてもキャッシュ設定のミスが思わぬ情報漏えいにつながることがあります。興味を持った方は、ぜひ他のラボにもチャレンジしてみてください。

参考文献

執筆者の他の記事を読む