restricted-properties を使用してポップアップ操作を保護する

ポップアップの操作中にクロスオリジン アイソレーションとクロスサイト リークを保護します。

Arthur Hemery
Maud Nalpas
Maud Nalpas

クロスオリジン オープナー ポリシー(COOP)の新しい値 restrict-properties を利用できるようになりました。セキュリティ上のメリットをもたらし、クロスオリジン分離を容易に導入できるとともに、支払いや認証などのユースケースで、サイトでサードパーティのポップアップを操作できるようになります。

restrict-properties のテストを開始するには、Chrome 116 以降のオリジン トライアルにご登録ください。

restrict-properties を使用するメリット

restrict-properties には、主に 2 つのユースケースがあります。

破損することなくクロスサイト漏洩を防止

デフォルトでは、どのウェブサイトでもポップアップでアプリケーションが開き、そのアプリケーションへの参照を取得できます。

悪意のあるウェブサイトがこれを悪用して、クロスサイト漏洩などの攻撃を実行する可能性があります。このリスクを軽減するには、Cross-Origin-Opener-Policy(COOP)ヘッダーを使用します。

これまで、Cross-Origin-Opener-Policy のオプションは制限されていました。次のいずれかの方法を使用できます。

  • ポップアップでのすべてのクロスオリジン インタラクションをブロックする same-origin, を設定します。
  • same-origin-allow-popups を設定します。これにより、ポップアップでサイトを開くクロスオリジン インタラクションがすべてブロックされます。
  • unsafe-none を設定します。これにより、ポップアップによるすべてのクロスオリジン インタラクションが許可されます。

そのため、ポップアップで開いたり、オープナーを操作して COOP を適用したりする必要があるウェブサイトが不可能になっていました。これにより、シングル サインオンや支払いなどの主要なユースケースが、クロスサイト漏洩から保護されませんでした。

この問題は、Cross-Origin-Opener-Policy: restrict-properties で解決できます。

restrict-properties では、フレーム カウントやその他のクロスサイト漏洩攻撃に使用できるプロパティは使用できませんが、postMessageclosed を介したウィンドウ間の基本的な通信は許可されます。

これにより、主要なユースケースを維持しながら、サイトのセキュリティを強化できます。次に例を示します。

  • ポップアップでサービスを提供する場合は、Cross-Origin-Opener-Policy: restrict-properties を設定することで、さまざまなクロスサイト漏洩攻撃から保護できます。以前は開くことができていたすべてのページは、引き続き開くことができます。
  • クロスオリジンのポップアップにアクセスする必要がある場合は、同様に Cross-Origin-Opener-Policy: restrict-properties を設定すると、サイトが iframe のカウントの対象外になります。現在と同じポップアップを 開くことができます
  • オープナーとオープナーの両者がヘッダーを設定し、ページがクロスオリジンの場合は、どちらか一方がヘッダーを設定したのと同じように動作します。同一オリジンの場合、完全アクセス権が付与されます。

サイトをクロスオリジン分離する

クロスオリジン分離が必要な理由

一部のウェブ API では、Spectre などのサイドチャネル攻撃のリスクが高まります。このリスクを軽減するため、ブラウザにはクロスオリジン分離と呼ばれる、オプトイン ベースの隔離環境が用意されています。クロスオリジン分離状態では、ウェブページは SharedArrayBufferperformance.measureUserAgentSpecificMemory()高精度タイマーなどの特権機能を解像度で使用しつつ、オプトインされていない限りオリジンを他から分離できます。

これまで、これらの API を使用するには Cross-Origin-Opener-Policy: same-origin を設定する必要がありました。ただし、これを行うと、シングル サインオンや Payments など、必要なクロスオリジン ポップアップ フローが機能しなくなります。

Cross-Origin-Opener-Policy: same-origin の代わりに Cross-Origin-Opener-Policy: restrict-properties を使用して、クロスオリジン分離を有効にできるようになりました。オープナーの関係を切断するのではなく、window.postMessage()window.closed という最小限のコミュニケーション サブセットに制限するだけです。

次の 2 つのヘッダーを使用して、クロスオリジン分離を有効にできます。

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp

or

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless

credentialless の詳細については、COEP: credentialless を使用して CORP ヘッダーなしでクロスオリジン リソースを読み込むをご覧ください。

デモ

こちらのクロスオリジン分離のデモで、さまざまなヘッダー オプションをお試しください。

オリジン トライアルをテストする

Cross-Origin-Opener-Policy: restrict-properties をテストするには、オリジン トライアルにオプトインします。

ブラウザ サポート

現在、Cross-Origin-Opener-Policy: restrict-properties は Chrome でのみサポートされています。他のブラウザも標準化の議論に積極的に参加しています。

よくある質問

ウェブサイトが同一オリジンのポップアップと通信する必要がある場合、COOP: restrict-properties を使用してクロスオリジン分離を有効にする必要がありますか?

ポップアップとメインページの両方で COOP: restrict-properties を設定しても制限は発生しません。これをポップアップのみ、またはメインページのみに設定すると、同一オリジンであっても、オープナー全体で postMessageclosed 以外のプロパティにアクセスできなくなります。

許可されているプロパティのセットは固定されていますか?

これまでのフィードバックから、ほとんどのワークフローには window.postMessagewindow.closed で十分と考えられますが、他のプロパティにも公開することを検討中です。postMessageclosed だけでは解決できないユースケースがある場合は、テストの意図のスレッドにフィードバックを残してください。

リソース