Ursprungsübergreifende Ressourcen ohne CORP-Header mit COEP: ohne Anmeldedaten laden

Ursprungsübergreifende Ressourcen, die von Drittanbietern bereitgestellt werden, enthalten häufig keine angemessenen CORP-Header. Wenn sie ohne Anmeldedaten angefordert werden können, können Sie die ursprungsübergreifende Isolierung jetzt aktivieren, indem Sie sie entsprechend kennzeichnen.

Eiji Kitamura

Der neue Wert der Cross-Origin Embedder-Richtlinie (COEP) wurde eingeführt credentialless, mit der der Browser ursprungsübergreifende Ressourcen laden kann, die die Cross-Origin Resource Policy (CORP) nicht verwenden, indem Sie eine Anfrage ohne Anmeldedaten wie Cookies. So können Entwickler ursprungsübergreifende leichter zu isolieren.

Warum die ursprungsübergreifende Isolierung erforderlich ist

Einige Web-APIs erhöhen das Risiko von Side-Channel-Angriffen wie Spectre Bis dieses Risiko zu mindern, bieten Browser eine Opt-in-basierte isolierte Umgebung namens ursprungsübergreifende Isolation an. Mit einer ursprungsübergreifenden kann die Webseite privilegierte Funktionen nutzen, z. B. SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und präzise Timer mit besserer Auflösung während der Ursprung von anderen isoliert wird, sofern diese nicht aktiviert sind.

Die Webseite muss zwei HTTP-Header senden, um die ursprungsübergreifende Isolierung zu aktivieren:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Bei einem ursprungsübergreifend isolierten Status müssen alle ursprungsübergreifenden Ressourcen bereitgestellt werden oder legen Sie einen Cross-Origin-Resource-Policy-Header fest, der geladen werden soll.

Herausforderungen bei der Aktivierung der ursprungsübergreifenden Isolierung

Die ursprungsübergreifende Isolierung verbessert die Sicherheit von Webseiten und ermöglicht, leistungsstarke Funktionen zu ermöglichen, schwierig sein. Eine der größten Herausforderungen besteht darin, CORS oder CORP für alle ursprungsübergreifenden Ressourcen. Ressourcen ohne diese Header werden vom Browser nicht auf eine ursprungsübergreifend isolierte Seite.

Diese ursprungsübergreifenden Ressourcen werden in der Regel von Drittanbietern bereitgestellt, ist es nicht einfach, die erforderlichen Überschriften hinzuzufügen.

Aber was ist, wenn wir wissen, dass die Ressource sicher genug ist, um geladen zu werden? Die einzige Gefährdete Ressourcen werden mit Anmeldedaten angefordert, potenziell vertrauliche Informationen enthalten, die der Angreifer nicht gehören. Das bedeutet, dass Ressourcen, die ohne Anmeldedaten angefordert werden können, öffentlich sind. und kann geladen werden.

credentialless zur Rettung

Hier kommt COEP: credentialless ins Spiel. credentialless ist ein neuer Wert für den Cross-Origin-Embedder-Policy-Header. Ähnlich wie bei require-corp kann es aktivieren Sie die ursprungsübergreifende Isolierung, aber es ist kein CORP:cross-origin erforderlich. -Header für ursprungsübergreifende Anfragen ohne COS. Diese werden stattdessen ohne Anmeldedaten (z. B. Cookies).

Alternativ können Sie die ursprungsübergreifende Isolierung mit dem folgenden beiden Überschriften:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Das bedeutet, dass der angeforderte ursprungsübergreifende Server nicht mit einem sensible Ressource ist und der Anforderer immer davon ausgehen kann, öffentlich zugängliche Informationen enthält.

Dies gilt auch für die Plan der schrittweisenden Einstellung von Drittanbieter-Cookies.

Demo

In dieser Demo können Sie verschiedene Header-Optionen ausprobieren: https://cross-origin-isolation.glitch.me

FAQ

Kann ich eine Anfrage mit Anmeldedaten in einer credentialless-Umgebung senden?

Absolut, allerdings auf Kosten der Änderung des Anfragemodus, sodass eine CORS-Prüfung erforderlich ist. auf die Antwort. Für HTML-Tags wie <audio>, <img>, <link>, <script>: und <video>, hängen Sie einfach crossorigin="use-credentials" explizit an, zum Senden von Anfragen mit Anmeldedaten an den Browser.

Beispiel: Auch wenn ein Dokument auf https://www.example.com Cross-Origin-Embedder-Policy: credentialless-Header, <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> macht Folgendes: Anfrage mit Anmeldedaten senden.

Für die fetch() API kann request.mode = 'cors' verwendet werden.

Laut COEP: credentialless ist COEP: require-corp noch nützlich für meine Website?

Bei COEP: require-corp müssen Sie den Anfragemodus nicht manuell auf CORS, wenn Cookies für einige ursprungsübergreifende Unterressourcen benötigt werden.

Kann ich in einer credentialless-Umgebung auch ursprungsübergreifende iFrames ohne spezielle Header laden?

Nein. Für das Laden ursprungsübergreifender iFrames in einer credentialless-Umgebung sind weiterhin dieselben Bedingungen wie für require-corp erforderlich. iFrame-Dokumente müssen mit zwei Headern bereitgestellt werden:

  • Cross-Origin-Embedder-Policy: credentialless oder require-corp
  • Cross-Origin-Resource-Policy: cross-origin

Die gute Nachricht ist, dass derzeit derzeit diskutiert wird, wie ursprungsübergreifende iFrames ohne diese Header geladen werden können, indem iFrames crossorigin="anonymous" angegeben werden. Dadurch können ursprungsübergreifende iFrames ohne Header geladen werden, Anmeldedaten.

Wird diese Funktion auch in anderen Browsern verfügbar sein?

Nächste Schritte

Es gibt zwei weitere Updates, um andere Herausforderungen ursprungsübergreifende Isolierung:

Personen, die sich aufgrund des folgenden Grundes für den Chrome-Ursprungstest zur Erweiterung der „SharedArrayBuffer“-Änderung registriert haben: für die oben genannten Hindernisse fragt sich vielleicht, wann es beendet wird. Ursprünglich haben wir angekündigt, dass sie in Chrome 96 beendet wird. Wir haben uns jedoch auf Chrome 106 verschieben.

Ressourcen

Foto von Martin Adams am Unsplash