ウェブ デベロッパー向けのサイト分離

Mathias Bynens

パソコン版 Chrome 67 では、サイト分離という新機能がデフォルトで有効になっています。この の記事では、サイト分離の概要、サイト分離が必要な理由、ウェブ デベロッパーがサイト分離を行うべき理由について説明しています。 注意してください。

サイト分離とは

インターネットは、猫の動画の視聴や暗号通貨ウォレットの管理などに使用されます。 しかし、fluffycats.example に貴重な暗号通貨を知られることは望ましくありません。幸い 同一オリジンにより、ウェブサイトは一般にブラウザ内で互いのデータにアクセスできない ポリシー。それでも、悪意のあるウェブサイトがこのポリシーを回避して他のウェブサイトを攻撃しようとする可能性はあります。 同一オリジン ポリシーを適用しているブラウザのコードにセキュリティ バグが見つかることがあります。「 Chrome チームは、このようなバグをできる限り迅速に修正することを目指しています。

サイト分離は Chrome のセキュリティ機能であり、サイトを保護するための追加の防御策を提供します。 成功する可能性が低くなります。異なるウェブサイトのページが常に 各プロセスがサンドボックス内で実行され、プロセスの実行内容が制限されます。 また、このプロセスが他のサイトから特定の種類の機密データを受信できないようにします。たとえば、 サイト分離を使用すると、悪意のあるウェブサイトで投機的 他のサイトからデータを盗むために Spectre などのサイドチャネル攻撃を仕掛けます。Chrome チームが 追加の違反措置を実施すると、攻撃者のページでページが破損する可能性がある場合でも、 独自のプロセスで行います。

サイト分離を効果的に実現すると、信頼できないウェブサイトによる情報へのアクセスや情報の窃取が効果的に行われる 制限しますさまざまな種類のデータに対する保護を強化します。 セキュリティ バグを

サイト分離について詳しくは、Google セキュリティ ブログの記事をご覧ください。

クロスオリジン読み取りブロック

すべてのクロスサイト ページを別々のプロセスに配置した場合でも、ページから合法的に クロスサイト サブリソース（画像や JavaScript など）が含まれます。悪意のあるウェブページでは、 <img> 要素を使用して、銀行口座などの機密データを含む JSON ファイルを読み込みます。

<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->

サイト分離がなければ、JSON ファイルの内容がレンダラのメモリに到達します。 すると、レンダラは有効な画像形式ではないことを認識し、レンダリングしません。 作成します。しかしその後、攻撃者は Spectre のような脆弱性を悪用して、 分割されます

攻撃者は、<img> を使用する代わりに、<script> を使用して機密データを commit することもあります。 memory:

<script src="https://your-bank.example/balance.json"></script>

クロスオリジン読み取りブロック（CORB）は、 MIME タイプに基づいて、balance.json がレンダラ プロセスのメモリのメモリに入ることを防ぎます。

CORB の仕組みを詳しく見ていきましょう。ウェブサイトからサーバーにリクエストできるリソースには、次の 2 種類があります。

  1. HTML、XML、JSON ドキュメントなどのデータリソース
  2. 画像、JavaScript、CSS、フォントなどのメディア リソース

ウェブサイトは、独自の生成元や、他の生成元からデータリソースを受信できます。 次のような制限の緩い CORS ヘッダー Access-Control-Allow-Origin: *。一方、メディア リソースは任意のリソースから含めることができます。 CORS ヘッダーがなくても生成できます。

CORB により、レンダラ プロセスがクロスオリジン データリソース（HTML、XML、 JSON など）です。

  • リソースに X-Content-Type-Options: nosniff ヘッダーがある
  • CORS はリソースへのアクセスを明示的に許可しない

クロスオリジン データリソースに X-Content-Type-Options: nosniff ヘッダーが設定されていない場合、 CORB はレスポンスの本文をスニッフィングして、それが HTML、XML、JSON のいずれであるかを判断します。これは、 たとえば、一部のウェブサーバーが正しく設定されておらず、画像を text/html として提供しているためです。

CORB ポリシーによってブロックされたデータリソースは、プロセスに空として表示されますが、 リクエストは引き続きバックグラウンドで行われますその結果、悪意のあるウェブページが クロスサイト・データをそのプロセスに取り込み、窃取します。

最適なセキュリティを確保し、CORB のメリットを得るため、次のことをおすすめします。

  • レスポンスに正しい Content-Type ヘッダーを付けてください。（たとえば、HTML リソースは text/html、次の JSON リソースを含む JSON MIME タイプと XML リソースを XML MIME タイプ）。
  • X-Content-Type-Options: nosniff ヘッダーを使用してスニッフィングをオプトアウトします。このヘッダーがないと Chrome はコンテンツ分析をすばやく行い、タイプが正しいことを確認しようとしますが、今回は レスポンスを許可して、JavaScript ファイルや 正直に正しいことをした方がいいよ。

詳しくは、 ウェブ デベロッパー向け CORB の記事 または CORB の詳細な説明をご覧ください。

ウェブ デベロッパーがサイト分離に注意を払うべき理由

ほとんどの場合、サイト分離は直接的ではないバックグラウンドのブラウザ機能です。 ウェブ デベロッパーに公開されています。たとえば、新しいウェブ公開 API はありません。一般的にウェブ サイト分離の有無にかかわらず、ページでの違いを区別できないようにする必要があります。

ただし、このルールにはいくつかの例外があります。サイト分離を有効にする場合、いくつかの微妙な作業が 悪影響を及ぼす可能性があります。Google は サイト分離に関する既知の問題のリスト 特に重要なものについて以下で説明します

フルページ レイアウトが同期しなくなった

サイト分離によって、ページ全体を覆うレイアウトの同期が保証されなくなります。これは、 ページが複数のプロセスに分散される場合があります。次のような場合にページに影響する可能性があります。 レイアウトの変更は直ちにページ上のすべてのフレームに反映されます。

例として、他のウェブサイトと通信する fluffykittens.example という名前のウェブサイトについて考えてみましょう。 social-widget.example でホストされているソーシャル ウィジェット:

<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
  const iframe = document.querySelector('iframe');
  iframe.width = 456;
  iframe.contentWindow.postMessage(
    // The message to send:
    'Meow!',
    // The target origin:
    'https://social-widget.example'
  );
</script>

最初は、ソーシャル ウィジェットの <iframe> の幅は 123 ピクセルです。それでは FluffyKittens の 幅を 456 ピクセルに変更し（レイアウトをトリガー）、ソーシャル ウィジェットにメッセージを送信します。 これには次のコードが含まれます。

<!-- https://social-widget.example/ -->
<script>
  self.onmessage = () => {
    console.log(document.documentElement.clientWidth);
  };
</script>

ソーシャル ウィジェットが postMessage API を介してメッセージを受信すると、常に そのルートの <html> 要素。

ログに記録される幅の値Chrome でサイト分離を有効にする前は、正解は「456」でした。アクセス document.documentElement.clientWidth によりレイアウトが強制される（Chrome より前は同期されていた） サイト分離が有効になっていることを確認しますただし、サイト分離を有効にすると、クロスオリジン ソーシャル ウィジェットで 再レイアウトが別のプロセスで非同期に行われるようになりました。そのため、この答えは 123（古い width 値）。

ページでクロスオリジン <iframe> のサイズが変更され、それに postMessage を送信すると、 サイト分離では、受信フレームがメッセージを受信するときに新しいサイズをまだ認識していない可能性があります。さらに表示 レイアウトの変更がすぐにすべてのページに反映されると、 フレームを追加します。

この特定の例では、より堅牢なソリューションとして、親フレームに width を設定し、 resize イベントをリッスンして、<iframe> の変化を検出します。

アンロード ハンドラのタイムアウトが頻繁に発生することがある

フレームが移動または閉じると、古いドキュメントと、そこに埋め込まれているすべてのサブフレーム ドキュメント unload ハンドラを実行します。新しいナビゲーションが同じレンダラ プロセスで発生する場合（ 同一オリジン ナビゲーションの場合）は、古いドキュメントとそのサブフレームの unload ハンドラを 新しいナビゲーションの commit を許可するまでに、任意の長時間を費やす必要があります。

addEventListener('unload', () => {
  doSomethingThatMightTakeALongTime();
});

この状況では、すべてのフレームの unload ハンドラの信頼性が非常に高くなります。

ただし、サイト分離を行わなくても、一部のメインフレーム ナビゲーションはクロスプロセスになるため、 アンロード ハンドラの動作。たとえば、次のように入力して old.example から new.example に移動すると、 アドレスバーの URL を入力すると、new.example ナビゲーションは新しいプロセスで発生します。アンロード old.example とそのサブフレームのハンドラは、バックグラウンドで old.example プロセスで実行されます。 new.example ページが表示され、古いアンロード ハンドラが渡されない場合、そのハンドラは終了します。 終了させることもできますアンロード ハンドラはタイムアウト前に完了しない可能性があるため、 アンロード動作の信頼性が低下します。

サイト分離を使用すると、すべてのクロスサイト ナビゲーションがクロスプロセスになるため、 異なるサイト間でプロセスが共有されることはありません。そのため、上記の状況は 多くのケースがあり、<iframe> のアンロード ハンドラは多くの場合、バックグラウンド動作とタイムアウト動作を持ちます。 使用できます。

サイト分離によって生じるもう一つの違いは、アンロード ハンドラの新しい並列順序です。 アンロード ハンドラは、厳密なトップダウンの順序でフレームにわたって実行されます。ただし、 分離、アンロード ハンドラは異なるプロセス間で並行して実行されます。

これらは、サイト分離を有効にすることによる基本的な結果です。Chrome チームは 可能であれば、一般的なユースケースでのアンロード ハンドラの信頼性を向上させる。また、 のバグを認識しており、サブフレーム アンロード ハンドラでまだ特定の機能を利用できず、 問題の解決に取り組んでいます

アンロード ハンドラの重要なケースとして、セッション終了 ping の送信があります。これは通常、次のようにして行われます。 次のようになります。

addEventListener('pagehide', () => {
  const image = new Image();
  img.src = '/end-of-session';
});

この変更を考慮した、より強力なアプローチとして、navigator.sendBeacon を使用する方法があります。 次の方法を使用します。

addEventListener('pagehide', () => {
  navigator.sendBeacon('/end-of-session');
});

リクエストをより詳細に制御する必要がある場合は、Fetch API の keepalive オプションを使用できます。

addEventListener('pagehide', () => {
  fetch('/end-of-session', {keepalive: true});
});

まとめ

サイト分離により、信頼できないウェブサイトがウェブサイトの情報にアクセスしたり、情報を盗んだりすることが 各サイトを独自のプロセスに分離することで、他のウェブサイトのアカウントを作成できます。その一環として、CORB は センシティブ データのリソースがレンダラ プロセスから排除されるようにします。上記の推奨事項は、 最大限に活用しましょう

ありがとう Alex Moshchuk 氏 Charlie Reis 氏 Jason Miller 氏 Nasko Oskov 氏 Philip Walton 氏 Shubhie Panicker、 トーマス・スタイナー にご協力いただきありがとうございます。