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.
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.
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.
<ph type="x-smartling-placeholder">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.
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 festgelegtAccess-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.
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
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“.
Betroffene Preflight-Anfragen können auch im Netzwerkbereich aufgerufen und diagnostiziert werden:
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.
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).