Sichere Pop-up-Interaktionen mit Einschränkungseigenschaften

Schutz vor ursprungsübergreifender Isolierung und Websiteübergreifenden Leaks bei der Interaktion mit Pop-ups

Arthur Hemery
GitHub
Maud Nalpas

Es ist ein neuer Wert für die Cross-Origin-Opener-Richtlinie (COOP) verfügbar: restrict-properties. Er bietet Sicherheitsvorteile und erleichtert die Einführung der ursprungsübergreifenden Isolierung. Gleichzeitig kann Ihre Website mit Pop-ups von Drittanbietern für Zahlungen, Authentifizierung oder andere Anwendungsfälle interagieren.

Wenn Sie restrict-properties testen möchten, nehmen Sie am Ursprungstest teil, der in Chrome 116 beginnt.

Gründe für die Verwendung von restrict-properties

restrict-properties hat zwei Hauptanwendungsfälle:

Websiteübergreifende Leaks ohne Unterbrechungen verhindern

Standardmäßig kann jede Website Ihre Anwendung in einem Pop-up öffnen und einen Verweis darauf erhalten.

Eine schädliche Website kann dies zu ihrem Vorteil nutzen, um Angriffe wie Websiteübergreifende Leaksauszuführen. Um dieses Risiko zu minimieren, können Sie den Header Cross-Origin-Opener-Policy (COOP) verwenden.

Bisher waren Ihre Optionen für Cross-Origin-Opener-Policy begrenzt. Sie hatten folgende Möglichkeiten:

  • same-origin, festlegen, wodurch alle ursprungsübergreifenden Interaktionen mit Pop-ups blockiert werden.
  • same-origin-allow-popups festlegen, wodurch alle ursprungsübergreifenden Interaktionen blockiert werden, die Ihre Website in einem Pop-up öffnen.
  • unsafe-none festlegen, wodurch alle ursprungsübergreifenden Interaktionen mit Pop-ups zugelassen werden.

Dadurch war es für Websites, die in einem Pop-up geöffnet werden müssen und mit ihrem Opener interagieren müssen, nicht möglich, COOP zu erzwingen. Wichtige Anwendungsfälle wie Single Sign-on und Zahlungen waren nicht vor Websiteübergreifenden Leaks geschützt.

Cross-Origin-Opener-Policy: restrict-properties löst dieses Problem.

Mit restrict-properties sind Eigenschaften, die für die Frame-Zählung und andere Websiteübergreifende Leaks-Angriffe verwendet werden können, nicht verfügbar. Die grundlegende Kommunikation zwischen Fenstern über postMessage und closed ist jedoch zulässig.

Dadurch wird die Sicherheit einer Website verbessert, während wichtige Anwendungsfälle beibehalten werden. Beispiel:

  • Wenn Sie einen Dienst in einem Pop-up anbieten, schützt die Einstellung Cross-Origin-Opener-Policy: restrict-properties Sie vor einer Reihe von Websiteübergreifenden Leaks-Angriffen. Sie können weiterhin alle Seiten öffnen, die Sie zuvor öffnen konnten.
  • Wenn Sie auf ein ursprungsübergreifendes Pop-up zugreifen müssen, schützt die Einstellung Cross-Origin-Opener-Policy: restrict-properties Ihre Website auf ähnliche Weise vor der Zählung von iFrames. Sie können dieselben Pop-ups öffnen, die Sie heute öffnen können.
  • Wenn sowohl der Opener als auch der Openee den Header festlegen und die Seiten ursprungsübergreifend sind, verhält es sich ähnlich wie wenn einer von ihnen den Header festgelegt hat. Wenn sie denselben Ursprung haben, wird der vollständige Zugriff gewährt.

Ihre Website ursprungsübergreifend isolieren

Gründe für die ursprungsübergreifende Isolierung

Einige Web-APIs erhöhen das Risiko von Side-Channel-Angriffen wie Spectre. Um dieses Risiko zu minimieren, bieten Browser eine isolierte Umgebung auf Opt-in-Basis an, die als ursprungsübergreifende Isolierungbezeichnet wird. In einem ursprungsübergreifend isolierten Zustand kann die Webseite privilegierte Funktionen verwenden, darunter SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und hochpräzise Timer mit besserer Auflösung. Gleichzeitig wird der Ursprung von anderen isoliert, es sei denn, sie haben sich angemeldet.

Bisher mussten Sie Cross-Origin-Opener-Policy: same-origin festlegen, um diese APIs zu verwenden. Dadurch werden jedoch alle ursprungsübergreifenden Pop-up-Abläufe unterbrochen, die Sie möglicherweise benötigen, z. B. Single Sign-on und Zahlungen.

Statt Cross-Origin-Opener-Policy: same-origin kann jetzt Cross-Origin-Opener-Policy: restrict-properties verwendet werden, um die ursprungsübergreifende Isolierung zu aktivieren. Anstatt die Beziehung zum Opener zu unterbrechen, wird sie lediglich auf die minimale Kommunikationsuntermenge von window.postMessage() und window.closed beschränkt.

Sie können die ursprungsübergreifende Isolierung mit den folgenden beiden Headern aktivieren:

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

oder

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

Weitere Informationen zu credentialless finden Sie unter Ursprungsübergreifende Ressourcen ohne CORP-Header mit COEP: credentialless laden.

Demo

Testen Sie in dieser Demo zur ursprungsübergreifenden Isolierung verschiedene Headeroptionen.

Ursprungstest

Wenn Sie Cross-Origin-Opener-Policy: restrict-properties testen möchten, melden Sie sich für den Ursprungstest an.

Unterstützte Browser

Cross-Origin-Opener-Policy: restrict-properties wird derzeit nur in Chrome unterstützt. Andere Browser sind aktiv an der Diskussion zur Standardisierung beteiligt.

FAQ

Meine Website muss mit Pop-ups desselben Ursprungs kommunizieren. Sollte ich COOP: restrict-properties verwenden, um die ursprungsübergreifende Isolierung zu aktivieren?

Wenn Sie COOP: restrict-properties sowohl für das Pop-up als auch für Ihre Hauptseite festlegen, entstehen keine Einschränkungen. Wenn Sie es nur für das Pop-up oder nur für die Hauptseite festlegen, wird der Zugriff auf andere Eigenschaften als postMessage und closed über den Opener verhindert, auch wenn sie denselben Ursprung haben.

Ist die Menge der zulässigen Eigenschaften festgelegt?

Basierend auf dem bisherigen Feedback reichen window.postMessage und window.closed für die meisten Arbeitsabläufe aus. Wir überlegen jedoch noch, sie für andere Eigenschaften zu öffnen. Wenn Sie einen Anwendungsfall haben, der nur mit postMessage und closed nicht gelöst werden kann, geben Sie uns Feedback im Thread „Intent to Experiment“.

Ressourcen