Cache-Control ヘッダーを忘れたり、誤って使用したりすると、ウェブサイトのセキュリティやユーザーのプライバシーに悪影響を及ぼす可能性があります。
デフォルトでは、リソースは常に任意のタイプのキャッシュによってキャッシュに保存できます。Cache-Control ヘッダーを使用しないか、誤用すると、ウェブサイトのセキュリティやユーザーのプライバシーに悪影響が及ぶ可能性があります。
パーソナライズされた回答を非公開にするには、次のいずれかの方法をおすすめします。
- リソースをキャッシュに保存しないようにします。
Cache-Control: privateを設定します。 - 適切なセカンダリ キャッシュキーを設定します。Cookie によってレスポンスが異なる場合（Cookie が認証情報を保存している場合に発生する可能性があります）は、
Vary: Cookieを設定します。
以下では、このことが重要な理由と、以下の点について説明します。
- 気づかないうちに発生するセキュリティとプライバシーの問題
- さまざまなタイプの HTTP キャッシュとよくある誤解
- 価値の高いウェブサイトに推奨される対応
キャッシュに関連するセキュリティとプライバシーのリスク
Spectre の脆弱性によるリソースの漏洩
Spectre の脆弱性により、ページが OS プロセスのメモリを読み取ることができます。つまり、攻撃者はクロスオリジン データに不正にアクセスできる可能性があります。その結果、最新のウェブブラウザでは、クロスオリジン分離のあるページにのみ、SharedArrayBuffer や高解像度タイマーなどの一部の機能の使用が制限されています。
最新のウェブブラウザは クロスオリジンの埋め込みポリシー（COEP）を適用します。これにより、クロスオリジン リソースが次のいずれかになります。
- Cookie なしでリクエストされた公開リソース
- CORS または CORP ヘッダーを介してクロスオリジン共有が明示的に許可されているリソース
COEP の設定では、攻撃者が Spectre を悪用することを防ぐことはできません。ただし、クロスオリジン リソースが攻撃者にとって価値がないものになる（ブラウザによって公開リソースとして読み込まれる場合）か、攻撃者と共有されなくなる（CORP: cross-origin と共有される場合）ようにします。
HTTP キャッシュが Spectre に与える影響
Cache-Control ヘッダーが正しく設定されていない場合、攻撃者が攻撃を実行する可能性があります。次に例を示します。
- 認証情報付きリソースがキャッシュに保存されます。
- 攻撃者は、クロスオリジン分離ページを読み込みます。
- 攻撃者はリソースを再度リクエストします。
COEP:credentiallessはブラウザによって設定されるため、リソースは Cookie なしで取得されます。ただし、キャッシュによって認証情報付きのレスポンスが返される場合があります。- 攻撃者は、Spectre 攻撃を使用してパーソナライズされたリソースを読み取ることができます。
ウェブブラウザの HTTP キャッシュでは、実際にはこのような攻撃が発生しませんが、ブラウザの直接制御の外部に追加のキャッシュが存在します。これにより、攻撃が成功する可能性があります。
HTTP キャッシュに関するよくある誤解
1. リソースはブラウザによってのみキャッシュに保存される
多くの場合、キャッシュには複数のレイヤがあります。キャッシュには、単一のユーザー専用のものもあれば、複数のユーザー専用のものもあります。一部はサーバーによって、一部はユーザーによって、一部は仲介業者によって制御されます。
- ブラウザのキャッシュ。これらのキャッシュは、単一のユーザーが所有し、そのユーザー専用にウェブブラウザに実装されます。同じレスポンスを複数回取得しないようにすることで、パフォーマンスが向上します。
- ローカル プロキシ。これはユーザーがインストールしたものである可能性がありますが、会社、組織、インターネット プロバイダなどの仲介業者によって管理されている場合もあります。ローカル プロキシは、多くの場合、複数のユーザーの単一レスポンスをキャッシュに保存します。これは「公開」キャッシュを構成します。ローカル プロキシには複数のロールがあります。
- オリジン サーバー キャッシュ / CDN。これはサーバーによって制御されます。送信元サーバー キャッシュの目的は、複数のユーザーに対して同じレスポンスをキャッシュに保存することで、送信元サーバー上の負荷を軽減することです。CDN の目標は同様ですが、世界中に分散され、レイテンシを低減するために最も近いユーザーに割り当てられます。
2. SSL により、中間業者が HTTPS リソースをキャッシュに保存できない
多くのユーザーは、アクセス目的（従量制接続の共有など）、ウイルス検査、データ損失防止（DLP）目的で、ローカルで構成されたプロキシを定期的に使用しています。中間キャッシュが TLS インターセプトを実行している。
中間キャッシュは、多くの場合、会社の従業員のワークステーションにインストールされます。ウェブブラウザが、ローカル プロキシの証明書を信頼するように構成されている。
最終的には、一部の HTTPS リソースがこれらのローカル プロキシによってキャッシュに保存される場合があります。
HTTP キャッシュの仕組み
- リソースはデフォルトで暗黙的にキャッシュに保存できます。
- プライマリ キャッシュキーは、URL とメソッドで構成されます。（URL、メソッド）
- セカンダリ キャッシュキーは、
Varyヘッダーに含まれるヘッダーです。Vary: Cookieは、レスポンスがCookieに依存していることを示します。 Cache-Controlヘッダーを使用すると、よりきめ細かい制御が可能になります。
ウェブサイトに推奨されるアクションを実施する
トラフィックの多いウェブサイトや個人識別情報を取り扱うウェブサイトなど、価値の高いウェブサイトを運営しているデベロッパーは、セキュリティ強化に今すぐ取り組む必要があります。
最大のリスクは、リソースへのアクセスが Cookie によって異なる場合に発生します。予防措置が講じられなかった場合、中間キャッシュは、Cookie を使用してリクエストされたレスポンスを、Cookie を使用していないリクエストに対して返すことがあります。
次のいずれかを行うことをおすすめします。
- リソースをキャッシュに保存しないようにします。
Cache-Control: privateを設定します。 - 適切なセカンダリ キャッシュキーを設定します。Cookie によってレスポンスが異なる場合（Cookie が認証情報を保存している場合に発生する可能性があります）は、
Vary: Cookieを設定します。
特に、デフォルトの動作を変更します。Cache-Control または Vary を常に定義します。
その他の考慮事項
HTTP キャッシュを使用する同様の攻撃は他にもありますが、それらはクロスオリジン分離とは異なるメカニズムに依存しています。たとえば、Jake Archibald は CORS で勝つ方法で、いくつかの攻撃について説明しています。
これらの攻撃は、リソース レスポンスが認証情報付きでリクエストされたかどうかに応じて HTTP キャッシュを分割する一部のウェブブラウザによって軽減されます。2022 年現在、Firefox はキャッシュを分割しますが、Chrome と Safari は分割しません。Chrome は今後、キャッシュを分割する可能性があります。これらの攻撃は、トップレベルのオリジンごとに分割するとは異なるものであり、補完的なものであることを理解してください。
ウェブブラウザでこの問題を軽減できたとしても、ローカル プロキシ キャッシュには問題が残ります。そのため、上記の推奨事項に沿っていただくことをおすすめします。
ヘッダー写真: Unsplash の Ben Pattinson 氏。