Warum Sie für leistungsstarke Funktionen eine ursprungsübergreifende Isolierung benötigen

Eiji Kitamura
Domenic Denicola
Domenic Denicola
X GitHub

Veröffentlicht am 4. Mai 2020

Im Artikel Website mit COOP und COEP ursprungsübergreifend isolieren haben wir erklärt, wie Sie den Status „ursprungsübergreifend isoliert“ mit COOP und COEP erreichen. Dieser Begleitartikel erklärt, warum die ursprungsübergreifende Isolierung erforderlich ist, um leistungsstarke Funktionen im Browser zu aktivieren.

Glossar

In diesem Dokument werden viele ähnlich benannte und abgekürzte Begriffe verwendet. Zur Verdeutlichung haben wir ein kleines Glossar zusammengestellt:

Hintergrund

Das Web basiert auf der Richtlinie für denselben Ursprung. Diese Sicherheitsfunktion beschränkt, wie Dokumente und Skripts mit Ressourcen aus einem anderen Ursprung interagieren können. Dieses Prinzip schränkt die Möglichkeiten ein, wie Websites auf ursprungsübergreifende Ressourcen zugreifen können. Beispielsweise kann ein Dokument von https://a.example nicht auf Daten zugreifen, die unter https://b.example gehostet werden.

Es gab jedoch einige historische Ausnahmen von der Richtlinie für denselben Ursprung. Jede Website kann:

  • ursprungsübergreifende iFrames einbetten
  • ursprungsübergreifende Ressourcen wie Bilder oder Skripts einfügen
  • ursprungsübergreifende Dialogfenster mit einem DOM-Verweis öffnen

Als die Web-Community die Vorteile einer strengen Richtlinie für denselben Ursprung erkannte, basierte das Web bereits auf diesen Ausnahmen.

Die sicherheitsrelevanten Nebenwirkungen einer so lockeren Richtlinie für denselben Ursprung wurden auf zwei Arten behoben:

  • Das CORS-Protokoll (Cross-Origin Resource Sharing) sorgt dafür, dass der Server die Freigabe einer Ressource für einen bestimmten Ursprung zulässt.
  • Entwickler entfernen implizit den direkten Skriptzugriff auf ursprungsübergreifende Ressourcen und erhalten gleichzeitig die Abwärtskompatibilität. Solche ursprungsübergreifenden Ressourcen werden als „undurchsichtig“ bezeichnet. Aus diesem Grund schlägt die ursprungsübergreifende Pixelmanipulation mit CanvasRenderingContext2D fehl, es sei denn, CORS wird auf das Bild angewendet.

Alle diese Richtlinienentscheidungen werden innerhalb einer Browsing-Context-Gruppe getroffen.

Die Browsing-Kontextgruppe umfasst die primäre Website und Assets der eingebetteten Website.

Lange Zeit reichte diese Kombination aus, um Browser sicher zu halten. Es gab nur wenige Grenzfälle, die direkt gepatcht werden mussten (z. B. JSON-Sicherheitslücken).

Das änderte sich mit Spectre. Dadurch können alle Daten, die in dieselbe Browsing-Context-Gruppe wie Ihr Code geladen werden, potenziell gelesen werden. Durch Messen der Zeit, die bestimmte Vorgänge benötigen, können Angreifer den Inhalt der CPU-Caches und damit den Inhalt des Arbeitsspeichers des Prozesses erraten. Solche Angriffe sind mit Timern mit geringer Granularität möglich, die auf der Plattform vorhanden sind. Sie können mit Timern mit hoher Granularität beschleunigt werden, sowohl explizit (z. B. performance.now()) als auch implizit (z. B. SharedArrayBuffers).

Wenn evil.com ein ursprungsübergreifendes Bild einbettet, können die Pixeldaten des eingebetteten Bildes mit einem Spectre-Angriff gelesen werden. Dadurch werden Schutzmaßnahmen, die auf „Undurchsichtigkeit“ beruhen, unwirksam.

Evil.com ist die Hauptwebsite, die den eingebetteten iFrame und die Bilder von b.example mit Spectre angreift.

Im Idealfall werden alle ursprungsübergreifenden Anfragen vom Server überprüft, dem die Ressource gehört. Wenn keine Überprüfung durchgeführt wurde, sollten die Daten niemals in die Browsing-Context-Gruppe eines böswilligen Akteurs gelangen. So bleiben die Daten außerhalb der Reichweite möglicher Spectre-Angriffe. Wir bezeichnen dies als ursprungsübergreifend isolierten Status.

Wenn sich der eingebettete Code in einem ursprungsübergreifend isolierten Status befindet, gilt die anfragende Website als weniger gefährlich. So kann die anfragende Website SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und hochauflösende Timer mit besserer Genauigkeit verwenden, während gleichzeitig mögliche Spectre-Angriffe verhindert werden. Dieser Status verhindert auch das Ändern von document.domain.

Cross-Origin-Embedder-Richtlinie

Die Cross-Origin-Embedder-Richtlinie (COEP) verhindert, dass ein Dokument ursprungsübergreifende Ressourcen lädt, die dem Dokument nicht explizit die Berechtigung mit CORP oder CORS gewähren. Mit dieser Funktion können Sie deklarieren, dass ein Dokument solche Ressourcen nicht laden kann.

Ein Diagramm, das zeigt, welche eingebetteten Assets aufgrund von CORP-Richtlinien zulässig und nicht zulässig sind.
Die übergeordnete Website a.example, hat die COEP-Richtlinie auf require-corp festgelegt. a.example möchte 3 Assets von b.example einbetten, aber nur zwei sind erfolgreich. Die beiden erfolgreichen Einbettungen enthalten eine JavaScript-Datei mit einer ursprungsübergreifenden CORP-Richtlinie und ein Bild mit zulässigem CORS. Das dritte Asset ist ein Video mit einer CORP-Richtlinie, die erfordert, dass das Asset nur im selben Ursprung eingebettet wird. Daher wird das Video nicht in a.example geladen.

Wenn Sie diese Richtlinie aktivieren möchten, fügen Sie dem Dokument den folgenden HTTP-Header hinzu:

Cross-Origin-Embedder-Policy: require-corp

COEP hat einen einzelnen Wert von require-corp. Dadurch wird die Richtlinie erzwungen, dass das Dokument nur Ressourcen aus demselben Ursprung oder Ressourcen laden kann, die explizit als aus einem anderen Ursprung ladbar gekennzeichnet sind.

Damit Ressourcen aus einem anderen Ursprung geladen werden können, müssen sie entweder CORS (Cross-Origin Resource Sharing) oder CORP (Cross-Origin Resource Policy) unterstützen.

Cross-Origin Resource Sharing

Wenn eine ursprungsübergreifende Ressource Cross Origin Resource Sharing (CORS) unterstützt, können Sie das crossorigin Attribut verwenden, um sie auf Ihre Webseite zu laden, ohne von COEP blockiert zu werden.

<img src="https://third-party.example.com/image.jpg" crossorigin>

Wenn diese Bildressource beispielsweise mit CORS-Headern bereitgestellt wird, verwenden Sie das crossorigin Attribut, damit die Anfrage zum Abrufen der Ressource den CORS Modus verwendet. Dadurch wird auch verhindert, dass das Bild geladen wird, es sei denn, es werden CORS-Header festgelegt.

Ebenso können Sie ursprungsübergreifende Daten mit der fetch() Methode abrufen. Das ist kein Problem, solange der Server mit den richtigen HTTP Headern antwortet.

Cross-Origin-Resource-Richtlinie

Die Cross-Origin-Resource-Richtlinie (CORP) wurde ursprünglich als Option eingeführt, um Ihre Ressourcen vor dem Laden durch einen anderen Ursprung zu schützen. Im Zusammenhang mit COEP kann CORP die Richtlinie des Ressourceninhabers für die Person angeben, die eine Ressource laden kann.

Der Header Cross-Origin-Resource-Policy hat drei mögliche Werte:

Cross-Origin-Resource-Policy: same-site

Ressourcen, die mit same-site gekennzeichnet sind, können nur von derselben Website geladen werden.

Cross-Origin-Resource-Policy: same-origin

Ressourcen, die mit same-origin gekennzeichnet sind, können nur aus demselben Ursprung geladen werden.

Cross-Origin-Resource-Policy: cross-origin

Ressourcen, die mit cross-origin gekennzeichnet sind, können von jeder Website geladen werden. (Dieser Wert wurde zusammen mit COEP der CORP-Spezifikation hinzugefügt.)

Cross-Origin-Opener-Richtlinie

Mit der Cross-Origin-Opener-Richtlinie (COOP) können Sie ein Fenster der obersten Ebene von anderen Dokumenten isolieren, indem Sie die Dokumente in eine separate Browsing-Context-Gruppe einfügen. So können die Dokumente nicht direkt mit dem Fenster der obersten Ebene interagieren. Wenn beispielsweise ein Dokument mit COOP ein Dialogfeld öffnet, ist die Eigenschaft window.opener null. Die Eigenschaft .closed des Verweises des Öffners ist true.

a.example konnte b.example nicht in einem Dialogfeld öffnen.

Der Header Cross-Origin-Opener-Policy hat drei mögliche Werte:

Cross-Origin-Opener-Policy: same-origin

Dokumente, die mit same-origin gekennzeichnet sind, können dieselbe Browsing-Context-Gruppe mit Dokumenten desselben Ursprungs teilen, die ebenfalls explizit mit same-origin gekennzeichnet sind.

Zeichnung, die ein Fenster darstellt, das mit einem Popup mit demselben Ursprung interagieren kann, das sich in derselben Browsing Context Group befindet, aber nicht als „same-origin“ gekennzeichnet ist, während es sich noch außerhalb der Browsing Context Group befindet.

Cross-Origin-Opener-Policy: same-origin-allow-popups

Ein Dokument der obersten Ebene mit same-origin-allow-popups behält Verweise auf alle Pop‑ups bei, für die entweder keine COOP festgelegt ist oder die die Isolierung durch Festlegen einer COOP von unsafe-none deaktivieren.

COOP

Cross-Origin-Opener-Policy: unsafe-none

unsafe-none ist die Standardeinstellung und ermöglicht das Hinzufügen des Dokuments zur Browsing-Context-Gruppe des Öffners, es sei denn, der Öffner selbst hat eine COOP von same-origin.

Zusammenfassung

Wenn Sie auf Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), oder hochauflösende Timer mit besserer Genauigkeit zugreifen möchten, muss Ihr Dokument sowohl COEP mit dem Wert require-corp als auch COOP mit dem Wert same-origin verwenden. Ohne eine der beiden Richtlinien kann der Browser keine ausreichende Isolierung garantieren, um diese leistungsstarken Funktionen sicher zu aktivieren. Sie können die Situation Ihrer Seite ermitteln, indem Sie prüfen, ob self.crossOriginIsolated zurückgibt true.

Informationen zur Implementierung finden Sie im Artikel Website mit COOP und COEP ursprungsübergreifend isolieren.

Ressourcen

Zurück
Website mit COOP und COEP „ursprungsübergreifend isoliert“ machen
Weiter
Ressourcen mit Fetch Metadata vor Webangriffen schützen