HTTP キャッシュを更新してセキュリティとプライバシーを強化

Cache-Control ヘッダーを忘れたり、誤って使用すると、ウェブサイトのセキュリティとユーザーのプライバシーに悪影響を及ぼす可能性があります。

Arthur Sonzogni
Arthur Sonzogni

デフォルトでは、リソースはどのタイプのキャッシュでも常にキャッシュに保存されます。Cache-Control ヘッダーを使用しない、または不正使用すると、ウェブサイトのセキュリティとユーザーのプライバシーに悪影響を及ぼす可能性があります。

パーソナライズされた回答を非公開にする場合は、次のいずれかを行うことをおすすめします。

  • 中継者がリソースをキャッシュに保存できないようにします。Cache-Control: private を設定します。
  • 適切なセカンダリ キャッシュキーを設定します。Cookie によってレスポンスが異なる場合（Cookie が認証情報を保存する際に発生する可能性がある）は、Vary: Cookie を設定します。

ここでは、これが重要である理由と、次の点について説明します。

  1. 気づかない可能性があるセキュリティとプライバシーの問題
  2. さまざまな種類の HTTP キャッシュとよくある誤解
  3. 価値の高いウェブサイトに推奨される対応

Spectre の脆弱性によるリソースのリーク

Spectre の脆弱性により、ページが OS プロセスのメモリを読み取るおそれがあります。つまり、攻撃者がクロスオリジン データへの不正アクセスを行うおそれがあります。そのため、最新のウェブブラウザでは、SharedArrayBuffer や高解像度タイマーなど、一部の機能の使用をクロスオリジン分離が設定されたページに制限しています。

最新のウェブブラウザでは、Cross-Origin Embedder Policy（COEP）が適用されます。これにより、クロスオリジン リソースが次のいずれかになります。

  • 公開リソース（Cookie なしでリクエスト）
  • CORS または CORP ヘッダーを介してクロスオリジンの共有が明示的に許可されているリソース

COEP の設定によって、攻撃者による Spectre の悪用を防ぐことはできません。ただし、クロスオリジン リソースが攻撃者にとって価値を持たない（公開リソースとしてブラウザによって読み込まれる場合）、または攻撃者との共有が許可されない（CORP: cross-origin との共有の場合）ことが保証されます。

HTTP キャッシュは Spectre にどのように影響しますか？

Cache-Control ヘッダーが適切に設定されていないと、攻撃者が攻撃を実行するおそれがあります。次に例を示します。

  1. 認証情報がキャッシュに保存された。
  2. 攻撃者がクロスオリジンの分離されたページを読み込みます。
  3. 攻撃者がリソースを再度リクエストします。
  4. COEP:credentialless はブラウザによって設定されるため、リソースは Cookie なしで取得されます。ただし、代わりにキャッシュから認証情報付きのレスポンスが返されることがあります。
  5. その後、攻撃者は Spectre 攻撃を使用してパーソナライズされたリソースを読み取ることができます。

ウェブブラウザの HTTP キャッシュでは、実際にはこの種の攻撃は実行できませんが、追加のキャッシュはブラウザ側で制御できないところにあります。これが攻撃の成功につながる可能性があります。

HTTP キャッシュに関するよくある誤解

1. リソースはブラウザによってのみキャッシュに保存される

多くの場合、キャッシュには複数のレイヤがあります。キャッシュには、1 人のユーザー専用のキャッシュもあれば、複数のユーザー専用のキャッシュもあります。サーバーによって制御されるものもあれば、ユーザーによって制御されるものもあれば、中継器によって制御されるものもあります。

  • ブラウザ キャッシュ。これらのキャッシュは 1 人のユーザーが所有し、専用で、ウェブブラウザに実装されます。同じレスポンスを複数回取得する必要がないため、パフォーマンスが向上します。
  • ローカル プロキシ。これはユーザーによってインストールされた可能性がありますが、中間者（会社、組織、インターネット プロバイダ）によって管理されることもあります。ローカル プロキシは多くの場合、複数のユーザーに対する 1 つのレスポンスをキャッシュに保存します。これは「公開」キャッシュを構成します。ローカル プロキシには複数のロールがあります。
  • 送信元サーバーのキャッシュ / CDN。これはサーバーによって制御されます。送信元サーバーのキャッシュの目的は、複数のユーザーのために同じレスポンスをキャッシュに保存することで、送信元サーバーの負荷を軽減することです。CDN の目標は似ていますが、レイテンシを短縮するために、世界中に分散し、最も近いユーザーのセットに割り当てられます。
多くの場合、ブラウザとサーバーの間には複数のキャッシュ レイヤがあります。
ブラウザとサーバーの間には、さまざまなキャッシュ レイヤが存在する場合があります。たとえば、サーバー キャッシュに続いて CDN キャッシュ、ブラウザ キャッシュが発生した場合などです。CDN とブラウザ キャッシュの間にローカル プロキシが設定されている場合もあります。

2. SSL は仲介者による HTTPS リソースのキャッシュを防ぐ

多くのユーザーは、アクセス目的（従量制接続の共有など）、ウイルス検査、データ損失防止（DLP）を目的として、ローカルに構成されたプロキシを定期的に使用します。中間キャッシュが TLS インターセプトを実行しています。

多くの場合、中間キャッシュは社員のワークステーションにインストールされます。ウェブブラウザがローカル プロキシの証明書を信頼するように設定されている。

最終的に、一部の HTTPS リソースは、これらのローカル プロキシによってキャッシュされる場合があります。

HTTP キャッシュの仕組み

  • リソースのキャッシュ保存はデフォルトで暗黙的に許可されます。
  • プライマリ キャッシュキーは、URL とメソッドで構成されます。（URL、メソッド）
  • セカンダリ キャッシュキーは、Vary ヘッダーに含まれるヘッダーです。Vary: Cookie は、レスポンスが Cookie に依存することを示します。
  • Cache-Control ヘッダーを使用すると、よりきめ細かい制御が可能になります。

トラフィックの多いウェブサイトや、個人を特定できる情報をやり取りするウェブサイトなど、価値の高いウェブサイトのデベロッパーは、今すぐセキュリティ強化のための対策を講じる必要があります。

最大のリスクは、リソースへのアクセスが Cookie によって異なる場合に生じます。予防措置が講じられていない場合は、中間キャッシュがリクエストに対して Cookie でリクエストされたレスポンスを返すことがあります。

次のいずれかの手順を行うことをおすすめします。

  • 中継者がリソースをキャッシュに保存できないようにします。Cache-Control: private を設定します。
  • 適切なセカンダリ キャッシュキーを設定します。Cookie によってレスポンスが異なる場合（Cookie が認証情報を保存する際に発生する可能性がある）は、Vary: Cookie を設定します。

特に、デフォルトの動作を変更して、常に Cache-Control または Vary を定義します。

その他の考慮事項

HTTP キャッシュを使用した同様の攻撃が他にもありますが、これらはクロスオリジン分離とは異なるメカニズムに依存しています。たとえば、Jake Archibald は CORS で勝利する方法で攻撃について説明しています。

このような攻撃は、リソース レスポンスが認証情報でリクエストされたかどうかに応じて HTTP キャッシュを分割するウェブブラウザによって緩和されます。2022 年現在、Firefox はキャッシュを分割しますが、Chrome と Safari は分割しません。 今後、Chrome でキャッシュが分割される可能性があります。これらの攻撃は異なるものであり、最上位のオリジンごとに分割することを補完するものです。

ウェブブラウザでこの問題を軽減できるとしても、ローカル プロキシ キャッシュには問題が残ります。そのため、上記の推奨事項に従うことをおすすめします。

ヘッダー写真: Ben Pattinson（Unsplash）