Hier erfahren Sie, warum die ursprungsübergreifende Isolierung erforderlich ist, um leistungsstarke Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und einen hochauflösenden Timer mit höherer Präzision zu nutzen.
Einleitung
Im Artikel Website mit COOP und COEP isoliert isoliert haben wir erläutert, wie der Status „ursprungsübergreifend isoliert“ mithilfe von COOP und COEP angewendet wird. In diesem Begleitartikel wird erläutert, warum die ursprungsübergreifende Isolierung erforderlich ist, um leistungsstarke Funktionen im Browser zu aktivieren.
Hintergrund
Das Web basiert auf der Same-Origin-Policy, einer Sicherheitsfunktion, die die Interaktion von Dokumenten und Skripts mit Ressourcen eines anderen Ursprungs einschränkt. Dieses Prinzip schränkt die Möglichkeiten ein, wie Websites auf ursprungsübergreifende Ressourcen zugreifen können. Beispielsweise wird ein Dokument vom https://a.example daran gehindert, auf Daten zuzugreifen, die unter https://b.example gehostet werden.
Für die Richtlinie für denselben Ursprung gab es jedoch in der Vergangenheit einige Ausnahmen. Jede Website kann:
- Ursprungsübergreifende iFrames einbetten
- Ursprungsübergreifende Ressourcen wie Bilder oder Skripts einbinden
- Ursprungsübergreifende Pop-up-Fenster mit einer DOM-Referenz öffnen
Wenn das Web von Grund auf neu gestaltet werden könnte, gäbe es diese Ausnahmen nicht. Als die Web-Community die Hauptvorteile einer strengen Same-Origin-Policy erkannt hatte, hat sich das Web bereits auf diese Ausnahmen verlassen.
Die Sicherheitsnebeneffekte einer solchen laxen Richtlinie für denselben Ursprung wurden auf zwei Arten behoben. Eine Möglichkeit war die Einführung eines neuen Protokolls namens Cross Origin Resource Sharing (CORS), dessen Zweck darin besteht, sicherzustellen, dass der Server die Freigabe einer Ressource mit einem bestimmten Ursprung zulässt. Die andere Möglichkeit besteht darin, den direkten Skriptzugriff auf ursprungsübergreifende Ressourcen implizit zu entfernen und gleichzeitig die Abwärtskompatibilität zu wahren. Solche ursprungsübergreifenden Ressourcen werden als „opake“ Ressourcen bezeichnet. Beispielsweise schlägt die Bearbeitung der Pixel eines ursprungsübergreifenden Bildes über CanvasRenderingContext2D fehl, sofern CORS nicht auf das Bild angewendet wird.
Alle diese Richtlinienentscheidungen werden innerhalb einer Browser-Kontextgruppe getroffen.
Lange Zeit reichte die Kombination aus CORS und intransparenten Ressourcen aus, um Browser sicher zu machen. Manchmal wurden Grenzfälle (z. B. JSON-Sicherheitslücken) entdeckt, die gepatcht werden mussten. Insgesamt war aber der Grundsatz, keinen direkten Lesezugriff auf die Rohbyte ursprungsübergreifender Ressourcen zuzulassen, erfolgreich.
All das hat sich mit Spectre geändert. Damit sind alle Daten, die in dieselbe Browser-Kontextgruppe wie Ihr Code geladen werden, potenziell lesbar. Durch Messen der Zeit, die bestimmte Vorgänge in Anspruch nehmen, können Angreifer den Inhalt der CPU-Caches und somit den Inhalt des Prozessspeichers erraten. Solche zeitbasierten Angriffe sind mit Timern mit niedriger Granularität, die in der Plattform vorhanden sind, möglich, aber auch mit expliziten (z. B. performance.now()) und impliziten Timern (wie SharedArrayBuffers) beschleunigt werden. Wenn evil.com ein ursprungsübergreifendes Bild einbettet, kann der Anbieter einen Spectre-Angriff ausführen, um die Pixeldaten zu lesen. Dadurch werden Schutzmaßnahmen, die auf „Undurchsichtigkeit“ beruhen, nicht wirksam.
Idealerweise sollten alle ursprungsübergreifenden Anfragen explizit von dem Server überprüft werden, dem die Ressource gehört. Wenn die Prüfung nicht vom ressourceneigenen Server durchgeführt wird, werden die Daten niemals in die Suchkontextgruppe eines bösen Akteurs gelangen und sind daher außerhalb der Reichweite von Spectre-Angriffen, die eine Webseite ausführen könnte. Wir nennen ihn einen ursprungsübergreifenden isolierten Zustand. Genau darum geht es bei COOP+COEP.
Im ursprungsübergreifenden Status gilt die anfragende Website als weniger gefährlich. Dadurch werden leistungsstarke Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und hochauflösende Timer mit höherer Genauigkeit freigeschaltet, die andernfalls für Spectre-ähnliche Angriffe verwendet werden könnten. Außerdem wird verhindert, dass document.domain geändert wird.
Cross-Origin-Embedder-Richtlinie
Die Cross-Origin Embedder Policy (COEP) verhindert, dass ein Dokument ursprungsübergreifende Ressourcen lädt, die die Dokumentberechtigung nicht explizit gewähren (mithilfe von CORP oder CORS). Mit dieser Funktion können Sie deklarieren, dass ein Dokument diese Ressourcen nicht laden kann.
Fügen Sie den folgenden HTTP-Header an das Dokument an, um diese Richtlinie zu aktivieren:
Cross-Origin-Embedder-Policy: require-corp
Das Keyword require-corp ist der einzige akzeptierte Wert für COEP. Dadurch wird die Richtlinie erzwungen, dass das Dokument nur Ressourcen aus demselben Ursprung oder Ressourcen laden kann, die explizit von einem anderen Ursprung als ladebar gekennzeichnet sind.
Damit Ressourcen von einem anderen Ursprung geladen werden können, müssen sie entweder CORS (Cross Origin Resource Sharing) oder Cross Origin Resource Policy (CORP) unterstützen.
Cross-Origin Resource Sharing
Wenn eine ursprungsübergreifende Ressource Cross-Origin Resource Sharing (CORS) unterstützt, können Sie das Attribut crossorigin 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 Attribut crossorigin, damit die Anfrage zum Abrufen der Ressource den CORS-Modus verwendet. Außerdem wird dadurch verhindert, dass das Image geladen wird, es sei denn, es werden CORS-Header festgelegt.
In ähnlicher Weise können Sie ursprungsübergreifende Daten über die Methode fetch() abrufen, die keine besondere Verarbeitung erfordert, solange der Server mit den richtigen HTTP-Headern antwortet.
Cross-Origin-Ressourcenrichtlinie
Die Cross-Origin Resource Policy (CORP) wurde ursprünglich als Opt-in eingeführt, um Ihre Ressourcen vor dem Laden durch einen anderen Ursprung zu schützen. Im Kontext von COEP kann CORP die Richtlinie des Ressourceninhabers für das Laden einer Ressource angeben.
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 als 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 in die CORP-Spezifikation aufgenommen.
Cross-Origin-Opener-Richtlinie
Mit der Cross-Origin Opener Policy (COOP) können Sie dafür sorgen, dass ein Fenster der obersten Ebene von anderen Dokumenten isoliert wird, indem Sie sie in eine andere Browserkontextgruppe verschieben, sodass sie nicht direkt mit dem Fenster der obersten Ebene interagieren können. Wenn beispielsweise ein Dokument mit COOP ein Pop-up öffnet, lautet die window.opener-Eigenschaft null. Außerdem wird für die .closed-Eigenschaft des Verweises auf die Einleitung true zurückgegeben.
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 Browserkontextgruppe wie Dokumente desselben Ursprungs gemeinsam nutzen, die auch explizit als same-origin gekennzeichnet sind.
Cross-Origin-Opener-Policy: same-origin-allow-popups
Ein Dokument der obersten Ebene mit same-origin-allow-popups behält Verweise auf alle darin enthaltenen Pop-ups bei, in denen entweder kein COOP festgelegt oder die Isolierung durch Festlegen einer COOP von unsafe-none deaktiviert wird.
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none ist die Standardeinstellung. Sie ermöglicht das Hinzufügen des Dokuments zur Suchkontextgruppe des Öffners, es sei denn, der Öffnender hat die COOP von same-origin.
Zusammenfassung
Wenn Sie garantierten Zugriff auf leistungsstarke Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() oder Timer mit hoher Auflösung mit höherer Genauigkeit wünschen, denken Sie daran, dass Ihr Dokument sowohl COEP mit dem Wert require-corp als auch COOP mit dem Wert same-origin verwenden muss. Fehlt eines der beiden, bietet der Browser keine ausreichende Isolierung, um diese leistungsstarken Funktionen sicher zu aktivieren. Du kannst prüfen, ob self.crossOriginIsolated true zurückgibt.
Weitere Informationen zur Implementierung finden Sie unter Website mit COOP und COEP „ursprungsübergreifend isoliert“ gestalten.