Diese Seite wurde von der Cloud Translation API übersetzt.

Privater Netzwerkzugriff: Einführung von Preflights

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Updates

7. Juli 2022: Der aktuelle Status wurde aktualisiert und die Definition des IP-Adressbereichs wurde hinzugefügt.
27. April 2022: Ankündigung des Zeitplans aktualisiert
7. März 2022: Rollback wurde angekündigt, nachdem Probleme in Chrome 98.

Einführung

Der direkte Zugriff auf private Netzwerk-Endpunkte über öffentliche Netzwerke in Chrome wird eingestellt Websites als Teil des Privater Netzwerkzugriff (Private Network Access, PNA) Spezifikation zu ändern.

Vor jeder privaten Netzwerkanfrage für eine Unterressource wird von Chrome eine CORS-Preflight-Anfrage gesendet, für eine ausdrückliche Genehmigung vom Zielserver. Diese Preflight-Anfrage einen neuen Header, Access-Control-Request-Private-Network: true und den muss die Antwort einen entsprechenden Header enthalten. Access-Control-Allow-Private-Network: true.

Ziel ist es, Nutzer vor Cross-Site Request Forgery (CSRF)-Angriffen zu schützen. für Router und andere Geräte in privaten Netzwerken. Von diesen Angriffen sind bereits Hunderttausende von Nutzern betroffen. mit der Angreifer sie auf bösartige Server umleiten können.

Einführungsplan

Chrome führt diese Änderung in zwei Phasen ein, damit Websites ausreichend Zeit haben, sich darauf aufmerksam zu machen. und entsprechende Anpassungen vornehmen.

In Chrome 104:
- Chrome-Tests durch Senden von Preflight-Anfragen vor einem privaten Netzwerk Unterressourcenanfragen.
- Bei Preflight-Fehlern werden nur Warnungen in den Entwicklertools angezeigt. die die Anfragen an private Netzwerke beeinflusst haben.
- Chrome sammelt Kompatibilitätsdaten und wendet sich an die am stärksten betroffenen Websites.
- Wir gehen davon aus, dass sie weitgehend mit bestehenden Websites kompatibel ist.
Warnung: Um die Auswirkungen auf Websites zu begrenzen, die noch keine Preflight-Anfragen unterstützen, ist in Chrome 104 auf 200 Millisekunden beschränkt. Die Einschränkung gilt nur im Warnungsmodus angewendet. Das spezielle Zeitlimit wird entfernt nach Aktivieren des Erzwingenmodus durch Auswahl von "Ergebnis des privaten Netzwerks berücksichtigen" Zugriff auf Preflight-Anfragen auf „Aktiviert“ in chrome://flags und das Standardlimit beträgt 5 Sekunden.
Frühestens in Chrome 113:
- Dies beginnt nur dann, wenn und wenn die Kompatibilitätsdaten darauf hinweisen, dass der dass die Änderungen sicher genug sind, und wir haben uns bei Bedarf direkt an dich gewendet.
- Chrome erzwingt, dass Preflight-Anfragen erfolgreich sein müssen, da andernfalls Fehler auftreten der Anfragen.
- Ein Test zur Einstellung beginnt um damit Websites, die von dieser Phase betroffen sind, Zeitverlängerung. Der Testzeitraum dauert mindestens 6 Monate.

Was ist der private Netzwerkzugriff (Private Network Access, PNA)?

Privater Netzwerkzugriff (früher CORS-RFC1918) schränkt die Fähigkeit von Websites ein, Anfragen an Server auf privatem Netzwerken.

Chrome hat bereits einen Teil der Spezifikation implementiert: Ab Chrome 96 wurde nur Kontexte ermöglichen, Anfragen an private Netzwerke zu senden. Weitere Informationen finden Sie in der im letzten Blogpost.

Die Spezifikation erweitert außerdem das Cross-Origin Resource Sharing (CORS) -Protokolls ein, sodass Websites jetzt explizit eine Erteilung von Servern anfordern müssen in privaten Netzwerken, bevor man willkürliche Anfragen senden darf.

Schlüsselbegriff:Anfragen an private Netzwerke sind Anfragen, deren Zielserver-IP-Adresse Daten, die privater sind als die Daten, von denen der Initiator der Anfrage abgerufen wurde. Beispiel: eine Anfrage von einer öffentlichen Website (https://example.com) an eine private Website (http://router.local) oder eine Anfrage von einer privaten Website an localhost.

Wie klassifiziert PNA IP-Adressen und identifiziert ein privates Netzwerk

Die IP-Adressen werden in drei IP-Adressbereiche unterteilt: – public – private – local

Der lokale IP-Adressbereich enthält IP-Adressen, die entweder IPv4 Loopback-Adressen (127.0.0.0/8), die in Abschnitt 3.2.1.3 von RFC1122 definiert sind oder IPv6-Loopback-Adressen (::1/128), die in Abschnitt 2.5.3 von RFC4291 definiert sind.

Der private IP-Adressbereich enthält IP-Adressen, die nur eine Bedeutung haben innerhalb des aktuellen Netzwerks, einschließlich 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 definiert in RFC1918, in RFC3927 definierte Link-Local-Adressen 169.254.0.0/16, eindeutige lokale IPv6-Unicast-Adressen fc00::/7, definiert in RFC4193, Link-Local-IPv6-Unicast-Adressen fe80::/10, definiert in Abschnitt 2.5.6 von RFC4291 und IPv4-zugeordnete IPv6-Adressen, bei denen die zugeordnete IPv4-Adresse selbst privat ist.

Der öffentliche IP-Adressbereich enthält alle anderen Adressen, die zuvor nicht aufgeführt wurden.

Eine lokale IP-Adresse gilt als privater als eine private IP-Adresse, gilt als privater als eine öffentliche IP-Adresse.

Anfragen sind privat, wenn ein besser verfügbares Netzwerk eine Anfrage an einen
weniger verfügbarem Netzwerk. — </ph> Beziehung zwischen öffentlichen, privaten und lokalen Netzwerken im privaten Netzwerk Zugriff (CORS-RFC1918)

Weitere Informationen finden Sie unter Feedback gewünscht: CORS für private Netzwerke (RFC1918).

Preflight-Anfragen

Hintergrund

Preflight-Anfragen sind ein Mechanismus, der durch den Standard Cross-Origin Resource Sharing (CORS) eingeführt wurde. , um eine Berechtigung von einer Zielwebsite anzufordern, bevor Sie eine HTTP-Anfrage senden die Nebenwirkungen haben können. Dadurch wird sichergestellt, dass der Zielserver des CORS-Protokolls und reduziert das Risiko von CSRF-Angriffen erheblich.

Die Berechtigungsanfrage wird als OPTIONS-HTTP-Anfrage mit bestimmten CORS-Anfrageheadern gesendet in der die bevorstehende HTTP-Anfrage beschrieben wird. Die Antwort muss bestimmte CORS-Antwortheader enthalten. dem bevorstehenden Ersuchen ausdrücklich zu.

Sequenzdiagramm, das die CORS-Preflight-Funktion darstellt Ein OPTIONS-HTTP
-Anforderung an das Ziel gesendet, das eine 200 OK zurückgibt. Dann gibt das CORS
Anfrageheader wird gesendet und ein CORS-Antwortheader zurückgegeben

Neuerungen beim privaten Netzwerkzugriff

Preflight-Anfragen werden ein neues Paar aus Anfrage- und Antwortheadern hinzugefügt:

Access-Control-Request-Private-Network: true ist für alle PNA-Preflight-Anfragen festgelegt
Access-Control-Allow-Private-Network: true muss für alle PNA-Preflight-Antworten festgelegt sein

Preflight-Anfragen für PNA werden für alle privaten Netzwerkanfragen gesendet, unabhängig von der Anfragemethode und mode auf. Sie werden gesendet Anfragen im cors-Modus sowie in no-cors und allen anderen Modi vorangehen. Dieses weil alle Anfragen an private Netzwerke für CSRF-Angriffe verwendet werden können. unabhängig vom Anfragemodus und ob der Antwortinhalt die dem Initiator zur Verfügung stehen.

Hinweis:Wenn die Anfrage an ein privates Netzwerk im Modus cors erfolgt, müssen CORS-Header wird zusätzlich zur Preflight-Antwort auch für die endgültige Antwort festgelegt.

Preflight-Anfragen für PNA werden auch für Anfragen mit demselben Ursprung gesendet, wenn der Die Ziel-IP-Adresse ist privater als der Initiator. Dies unterscheidet sich von normalen CORS, wobei Preflight-Anfragen nur für ursprungsübergreifende Anfragen gelten. Vorflug Anfragen für Same-Origin-Anfragen schützen DNS-Rebinding-Angriffe:

Beispiele

Beobachtbares Verhalten hängt davon ab, Modus der Anfrage an.

Kein CORS-Modus

Sag https://foo.example/index.html Einbettungen <img src="https://bar.example/cat.gif" alt="dancing cat"/> und bar.example wird in 192.168.1.1 aufgelöst, einer privaten IP-Adresse gemäß RFC 1918.

Chrome sendet zuerst eine Preflight-Anfrage:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Damit diese Anfrage erfolgreich ist, muss der Server so antworten:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Warnung: Der Server kann Access-Control-Allow-Origin: * festlegen. Dies ist jedoch gefährlich. und entmutigt werden. Private Netzwerkressourcen sollten selten für alle zugänglich sein sollten Sie sich daher Gedanken über die Risiken machen, die mit dem Festlegen eines solchen Headers verbunden sind.

Dann sendet Chrome die eigentliche Anfrage:

HTTP/1.1 GET /cat.gif
...

Auf die der Server normal antworten kann.

CORS-Modus

Angenommen, https://foo.example/index.html führt den folgenden Code aus:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Sagen Sie noch einmal, dass bar.example in 192.168.1.1 aufgelöst wird.

Chrome sendet zuerst eine Preflight-Anfrage:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Damit diese Anfrage erfolgreich ist, muss der Server so antworten:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Dann sendet Chrome die eigentliche Anfrage:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

Auf die der Server gemäß den üblichen CORS-Regeln antworten kann:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

So erkennen Sie, ob Ihre Website betroffen ist

Wenn ab Chrome 104 eine Anfrage an ein privates Netzwerk erkannt wird, wird ein Preflight -Anforderung wird vor dieser gesendet. Wenn diese Preflight-Anfrage fehlschlägt, Anfrage wird trotzdem gesendet, in den Entwicklertools wird jedoch eine Warnung angezeigt Bereich „Probleme“.

Warnung wegen fehlgeschlagener Preflight-Anfrage im Bereich „Probleme“ in den Entwicklertools. Dies bedeutet:
Anfragen an private Netzwerke nur
an Ressourcen senden, die dies zulassen,
zusammen mit Details zur jeweiligen Anfrage und aufgeführten betroffenen Ressourcen.

Betroffene Preflight-Anfragen können auch im Netzwerkbereich aufgerufen und diagnostiziert werden:

Fehlgeschlagene Preflight-Anfrage im Netzwerkbereich der Entwicklertools für localhost
501-Status.

Wenn Ihre Anfrage einen regulären CORS-Preflight ohne Regeln für den privaten Netzwerkzugriff festgelegt sind, können zwei Preflight-Anfragen im Netzwerk-Panel, wobei das erste immer als fehlgeschlagen angezeigt wird. Dies ist ein bekannten Bug können Sie ignorieren.

Eine falsche fehlgeschlagene Preflight-Anfrage vor einer erfolgreichen Preflight-Anfrage in
in den Entwicklertools
im Bereich „Network“ (Netzwerk) ein.

Um zu überprüfen, was passiert, wenn ein Preflight-Erfolg erzwungen wird, können Sie übergeben Sie das folgende Befehlszeilenargument, ab Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Jede fehlgeschlagene Preflight-Anfrage führt zu einem fehlgeschlagenen Abruf. So können Sie um zu testen, ob Ihre Website nach dem zweiten Phase unseres Einführungsplans. Fehler können in wie Warnungen in den oben erwähnten Entwicklertools-Bereichen.

Was Sie tun können, wenn Ihre Website betroffen ist

Wenn diese Änderung in Chrome 104 eingeführt wird, ist davon auszugehen, dass sie keine Website. Wir empfehlen Ihnen jedoch dringend, die betroffenen Anfragepfade zu aktualisieren: um sicherzustellen, dass Ihre Website weiterhin wie erwartet funktioniert.

Dafür stehen Ihnen zwei Lösungen zur Verfügung:

Preflight-Anfragen serverseitig verarbeiten
PNA-Prüfungen mit Unternehmensrichtlinien deaktivieren

Preflight-Anfragen serverseitig verarbeiten

Zielserver aller betroffenen Abrufe zur Verarbeitung von PNA-Preflight aktualisieren -Anfragen. Implementieren Sie zuerst die Unterstützung für standardmäßige CORS-Preflight-Anfragen auf betroffene Routen. Fügen Sie dann die Unterstützung für die zwei neuen Antwortheader hinzu.

Wenn Ihr Server eine Preflight-Anfrage erhält (eine OPTIONS-Anfrage mit CORS) -Header), sollte der Server auf das Vorhandensein eines Access-Control-Request-Private-Network: true-Header. Wenn dieser Header in der Anfrage vorhanden ist, sollte der Server den Origin-Header und den zusammen mit allen anderen relevanten Informationen (z. B. Access-Control-Request-Headers), damit die Anfrage sicher erlaubt werden kann. Normalerweise sollten Sie den Zugriff auf einen einzelnen Ursprung unter Ihrer Kontrolle gewähren.

Sobald Ihr Server die Anfrage zugelassen hat, sollte er eine Antwort erhalten. 204 No Content (oder 200 OK) mit den erforderlichen CORS-Headern und dem neuen PNA Header. Zu diesen Headern gehören Access-Control-Allow-Origin und Access-Control-Allow-Private-Network: true und nach Bedarf weitere.

Konkrete Szenarien finden Sie in den Beispielen.

Prüfungen des privaten Netzwerkzugriffs mithilfe von Unternehmensrichtlinien deaktivieren

Wenn Sie administrative Kontrolle über Ihre Nutzer haben, können Sie "Privat" deaktivieren. Netzwerkzugriffsprüfungen mit einer der folgenden Richtlinien:

Weitere Informationen finden Sie unter Ausführliche Informationen zur Chrome-Richtlinienverwaltung.

Feedback geben

Wenn Sie eine Website in einem privaten Netzwerk hosten, das Anfragen von öffentlichen Netzwerken gibt, ist das Chrome-Team an Ihrem Feedback und Ihren Anwendungsfällen interessiert. Melde dich bei Chromium unter crbug.com und setze die Komponente auf Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Nächste Schritte

Als Nächstes weiten wir die Prüfungen des privaten Netzwerkzugriffs auf Web-Worker: dedizierten Workern, gemeinsam genutzten Workern und Service Workern. Wir versuchen, werden in Chrome 107 Warnungen angezeigt.

Dann erweitert Chrome die Prüfungen des privaten Netzwerkzugriffs auf Navigationen, einschließlich iFrames und Pop-ups. Die Einführung von Chrome 108 ist geplant. Warnungen werden angezeigt.

In beiden Fällen werden wir mit einer ähnlichen stufenweisen Einführung fortfahren, damit Webentwickler*innen Zeit haben, die Kompatibilitätsrisiken anzupassen und einzuschätzen.

Danksagungen

Titelbild von Mark Olsen auf Unsplash (Unsplash).