ウェブ プラットフォームは、セキュリティの土台となる境界線としてオリジンに依存しています。また、ブラウザは、あるオリジンから別のオリジンへの明示的なデータの漏洩をうまく防いでいます。しかし、Spectreのような攻撃から、明示的でないデータ漏洩への対策が必要になることがわかります。このような攻撃では、サイドチャネルが悪用され、攻撃者のコードを実行するプロセスに入ったあらゆるデータが攻撃者に読み取られることが実証されています。現在、こういった攻撃の実現性はかなり高く、ユーザーにとってのリスクは現実のものとなっています。
機密データが意図せずに攻撃者のプロセスに入り込まないようにしなくてはなりません。ブラウザは、この責任の大部分を背負っています。Chromium の Site Isolation（サイト分離）は、アクセスしたサイトを OS レベルで専用のプロセスに隔離します。Cross-Origin Read Blocking = CORB（クロスオリジン読み込みブロック）は、そのままでは保護されないクロスオリジンリソースの一部が攻撃者に読み込まれることを防ぎます。攻撃者の帯域幅を大幅に増やす API（SharedArrayBufferなど）は、クロスオリジン分離コンテキストにロックされます。しかし、この最後のメカニズムは、ブラウザが単独では行えない作業を指しています。
ウェブ デベロッパーはアプリケーションを熟知しており、各ページやリソースの漏洩によるリスクを情報に基づいて判断できます。ユーザーのデータが漏洩することを防ぐため、ウェブ デベロッパーはホストしているリソースを評価し、適切にリソースを分離するようブラウザに指示するという対策をとる必要があります。概念レベルでは、この対策は次の要素で構成されます。
- 受信したヘッダーを調べ、一方で Originヘッダー、もう一方で Sec-Fetch-で始まる各ヘッダーに注目し、リクエストに応答するべきかどうかを判断します。
- 攻撃者がリソースをサブリソースとして読み込む機能を制限します。これをするには、Cross-Origin Resource Policy として same-originを設定します（必要な場合のみ、same-siteまたは cross-originにします）。
- 攻撃者がリソースをドキュメントとしてフレームに含めることができるかを制限します。これをするには、X-Frame-Options: SAMEORIGINを使ってフレーム化保護にオプトインするか、さらに細かい制御が可能な CSP の frame-ancestorsディレクティブを使います。たとえば、frame-ancestors 'self' https://trusted.embedderとします。
- 攻撃者がアプリケーションのウィンドウを参照する機能を制限します。これをするには、Cross-Origin Opener Policy を設定します。制限が強い same-origin値をデフォルトとし、必要な場合のみ same-origin-allow-popupsまたは unsafe-noneにするのが最適です。
- MIME-type confusion 攻撃を防ぎ、Cross-Origin Read Blocking（クロスオリジン読み込みブロック）などの消極的防御の確実性を高めます。これをするには、正しい Content-Typeヘッダーを設定し、X-Content-Type-Options: nosniffとなっていることをグローバルで確認します。
以上のさまざまな防御策を合わせれば、サイト分離が利用できるかどうかにかかわらず、すべてのブラウザでユーザーのデータに対してある程度の保護をプロセスレベルで提供できます。
これらの防御策の適用に関する詳しい情報は、Spectre 後のウェブ開発をご覧ください。以上で説明したセキュリティ プリミティブがどのようにサイト上のリソースに適用されるかについて、詳しく説明する実例も含まれています。
ここで示したのは、明示的でないデータ漏洩からオリジンを守るために、すぐにでも実施できる有用な手順です。今後は、ウェブの各種デフォルトを安全なものに移行し、デベロッパーが何もしなくてもこういった攻撃からユーザーを守れるようにしたいと考えています。
Reviewed by Eiji Kitamura - Developer Relations Team