Hello there, ('ω')ノ
✅ パスマッピングとは？
URLパスのマッピングとは：
サーバーが受け取ったURLを、実際に処理すべきリソース（ファイル、スクリプト、APIロジックなど）に変換する仕組み
です。
🔍 主なマッピングスタイル
① 伝統的なファイルシステム型マッピング（静的サイトなど）
http://example.com/path/in/filesystem/resource.html
example.com：サーバーのホスト/path/in/filesystem/：実際のディレクトリresource.html：サーバー上に存在する静的ファイル
この構造では、URLは実際のファイル構造と一致しています。
② RESTスタイルのURLマッピング（モダンなAPIベース）
http://example.com/path/resource/param1/param2
/path/resource/：エンドポイント（APIロジックに対応）param1,param2：パスパラメータ（引数として扱われる）
この構造では、URLはファイル構造とは無関係で、サーバー内部のルーティングロジックで処理されます。
⚠️ パスマッピングのズレが起こるパターン
| キャッシュ側の想定 | オリジン側の実際の処理 |
|---|---|
/account.js → 静的ファイル /account.js |
実際には /account に対応する動的ルートとして処理されている |
/user/data/print.png → 画像ファイル |
実際は /user/data/print APIにルーティングされている |
→ つまり、パスの解釈方法にズレがあると、機密レスポンスが静的と誤解されてキャッシュされる
💥 Web Cache Deceptionにどう使われるか？
攻撃者はこの「ズレ」を使って、次のようなURLを生成：
/account → /account.css /settings → /settings;static /order → /order.jpeg
- キャッシュ側：静的ファイルとして処理 → キャッシュ対象
- アプリ側：
.cssや;staticを無視して動的レスポンスを返す
結果：被害者の個人データが含まれたレスポンスがキャッシュに保存される
✅ まとめ
| 項目 | 内容 |
|---|---|
| 伝統的URL | 実ファイルにマップされるパス構造 |
| RESTful URL | 抽象化された論理構造、ファイル構成と無関係 |
| ズレのリスク | キャッシュは拡張子付きURLを静的と判断 → アプリは無視して動的処理 → 脆弱性発生 |
パスの見た目と実際の処理ルートが一致していない これがWeb Cache Deceptionを成立させる最大のヒントです。
Best regards, (^^ゞ
