Updates
- 7. Juli 2022: Der aktuelle Status wurde aktualisiert und die Definition des IP-Adressbereichs wurde hinzugefügt.
- 27. April 2022: Aktualisierte Zeitachse.
- 7. März 2022: Aufgrund von Problemen in Chrome 98 wurde ein Rollback angekündigt.
Einleitung
Im Rahmen der Spezifikation Privater Netzwerkzugriff (PNA) wird der direkte Zugriff von öffentlichen Websites auf private Netzwerkendpunkte von Chrome eingestellt.
Chrome sendet vor jeder privaten Netzwerkanfrage für eine Unterressource eine CORS-Preflight-Anfrage, die eine ausdrückliche Berechtigung vom Zielserver anfordert. Diese Preflight-Anfrage enthält den neuen Header Access-Control-Request-Private-Network: true
und die Antwort darauf muss den entsprechenden Header Access-Control-Allow-Private-Network: true
enthalten.
Das Ziel besteht darin, Nutzer vor Cross-Site Request Forgery-Angriffen (CSRF) zu schützen, die auf Router und andere Geräte in privaten Netzwerken abzielen. Von diesen Angriffen waren Hunderttausende Nutzer betroffen, sodass Angreifer sie an schädliche Server weiterleiten konnten.
Einführungsplan
Chrome wird diese Änderung in zwei Phasen einführen, damit Websites Zeit haben, die Änderung zu erkennen und sich entsprechend anzupassen.
In Chrome 104:
- Für Tests in Chrome werden Preflight-Anfragen vor Anfragen von privaten Netzwerkunterressourcen gesendet.
- Bei Preflight-Fehlern werden in den Entwicklertools nur Warnungen angezeigt. Die privaten Netzwerkanfragen werden dadurch nicht beeinflusst.
- 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 sein wird.
Frühestens in Chrome 113:
- Die Überprüfung beginnt nur dann, wenn aus den Kompatibilitätsdaten hervorgeht, dass die Änderung sicher genug ist und wir uns bei Bedarf direkt kontaktiert haben.
- Chrome erzwingt, dass Preflight-Anfragen erfolgreich sein müssen. Andernfalls schlägt die Anfrage fehl.
- Zur selben Zeit wird ein Test zur Einstellung gestartet, damit Websites, die von dieser Phase betroffen sind, eine Fristverlängerung beantragen können. Der Testzeitraum dauert mindestens 6 Monate.
Was ist ein privater Netzwerkzugriff (PNA)?
Durch den privaten Netzwerkzugriff (früher CORS-RFC1918) wird die Möglichkeit von Websites eingeschränkt, Anfragen an Server in privaten Netzwerken zu senden.
Chrome hat bereits einen Teil der Spezifikation implementiert: Ab Chrome 96 dürfen private Netzwerkanfragen nur noch über sichere Kontexte gesendet werden. Weitere Informationen finden Sie in unserem vorherigen Blogpost.
Die Spezifikation erweitert auch das CORS-Protokoll (Cross-Origin Resource Sharing), sodass Websites jetzt explizit eine Genehmigung von Servern in privaten Netzwerken anfordern müssen, bevor sie beliebige Anfragen senden dürfen.
Wie klassifiziert PNA IP-Adressen und identifiziert ein privates Netzwerk?
Die IP-Adressen werden in drei IP-Adressbereiche klassifiziert:
– public
– private
– local
Der lokale IP-Adressbereich enthält IP-Adressen, bei denen es sich entweder um IPv4-Loopback-Adressen (127.0.0.0/8
) handelt, die in Abschnitt 3.2.1.3 von RFC1122 definiert sind, oder um 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 innerhalb des aktuellen Netzwerks eine Bedeutung haben, darunter 10.0.0.0/8
, 172.16.0.0/12
und 192.168.0.0/16
in RFC1918, Link-Local-Adressen 169.254.0.0/16
in RFC3927 definiert, eindeutige lokale IPv6-Unicast-Adressen fc00::/7
in RFC4193, Link-Local-IPv6-IPv6-Adressen {13/4-IPv6 selbst, Link-Local-IPv6-IPv15-Adressen {13/4-IPv15 selbst.fe80::/10
RFC4291
Der öffentliche IP-Adressbereich enthält alle anderen Adressen, die zuvor nicht erwähnt wurden.
Eine lokale IP-Adresse gilt als privater als eine private IP-Adresse, die als privater als eine öffentliche IP-Adresse gilt.
![Anfragen sind privat, wenn ein stärker verfügbares Netzwerk eine Anfrage an ein weniger verfügbares Netzwerk sendet.](https://developer.chrome.com/static/blog/private-network-access-preflight/image/requests-are-private-a-m-009fa2902388e.jpg?authuser=6&hl=de)
Weitere Informationen finden Sie unter Feedback erwünscht: CORS für private Netzwerke (RFC1918).
Preflight-Anfragen
Hintergrund
Preflight-Anfragen sind ein durch den Standard Cross-Origin Resource Sharing (CORS) eingeführter Mechanismus, mit dem eine Berechtigung von einer Zielwebsite angefordert wird, bevor eine HTTP-Anfrage mit Nebenwirkungen gesendet wird. Dadurch wird sichergestellt, dass der Zielserver das CORS-Protokoll versteht und das Risiko von CSRF-Angriffen erheblich reduziert wird.
Die Berechtigungsanfrage wird als OPTIONS
-HTTP-Anfrage mit bestimmten CORS-Anfrageheadern gesendet, die die anstehende HTTP-Anfrage beschreiben. Die Antwort muss bestimmte CORS-Antwortheader enthalten, die der anstehenden Anfrage explizit zustimmen.
Neuerungen beim privaten Netzwerkzugriff
Für Preflight-Anfragen wurde ein neues Paar aus Anfrage- und Antwortheadern eingeführt:
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 dem Modus. Sie werden vor Anfragen im cors
-Modus sowie no-cors
und allen anderen Modi gesendet. Dies liegt daran, dass alle privaten Netzwerkanfragen für CSRF-Angriffe verwendet werden können, unabhängig vom Anfragemodus und davon, ob dem Initiator die Antwortinhalte zur Verfügung gestellt werden.
Preflight-Anfragen für PNA werden auch für Anfragen vom selben Ursprung gesendet, wenn die Ziel-IP-Adresse privater als der Initiator ist. Dies unterscheidet sich von regulären CORS-Anfragen, bei denen Preflight-Anfragen nur für ursprungsübergreifende Anfragen bestimmt sind. Preflight-Anfragen für Same-Origin-Anfragen schützen vor DNS-Rebinding-Angriffen.
Beispiele
Das beobachtbare Verhalten hängt vom Anfragemodus ab.
CORS-Modus ohne CORS
Angenommen, https://foo.example/index.html
bettet <img src="https://bar.example/cat.gif" alt="dancing cat"/>
ein 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 mit Folgendem 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 sich bar.example
in 192.168.1.1
auflöst.
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 mit Folgendem 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
Darauf kann der Server gemäß den üblichen CORS-Regeln reagieren:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
Prüfen, ob Ihre Website betroffen ist
Wenn in Chrome 104 eine private Netzwerkanfrage erkannt wird, wird davor eine Preflight-Anfrage gesendet. Wenn diese Preflight-Anfrage fehlschlägt, wird trotzdem die letzte Anfrage gesendet, im Problembereich der Entwicklertools wird jedoch eine Warnung angezeigt.
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 ausgelöst hätte, werden im Netzwerkbereich möglicherweise zwei Preflights angezeigt, wobei der erste immer fehlgeschlagen ist. Dies ist ein bekannter Fehler, den Sie ignorieren können.
Wenn Sie prüfen möchten, was passiert, wenn ein Preflight-Erfolg erzwungen wurde, können Sie ab Chrome 98 das folgende Befehlszeilenargument übergeben:
--enable-features=PrivateNetworkAccessRespectPreflightResults
Fehlgeschlagene Preflight-Anfragen führen zu einem fehlgeschlagenen Abruf. So können Sie testen, ob Ihre Website nach der zweiten Phase unseres Einführungsplans funktionieren würde. Fehler können auf die gleiche Weise wie Warnungen über die oben erwähnten Entwicklertools diagnostiziert werden.
Was zu tun ist, wenn Ihre Website betroffen ist
Wenn diese Änderung in Chrome 104 eingeführt wird, wird davon auszugehen, dass keine Website beeinträchtigt wird. Wir empfehlen Ihnen jedoch dringend, die betroffenen Anfragepfade zu aktualisieren, damit Ihre Website weiterhin wie erwartet funktioniert.
Ihnen stehen zwei Lösungen zur Verfügung:
- Preflight-Anfragen serverseitig verarbeiten
- PNA-Prüfungen mit Unternehmensrichtlinien deaktivieren
Preflight-Anfragen serverseitig verarbeiten
Aktualisieren Sie den Zielserver aller betroffenen Abrufe, um PNA-Preflight-Anfragen zu verarbeiten. Implementieren Sie zuerst die Unterstützung für CORS-Standard-Preflight-Anfragen auf betroffenen Routen. Danach werden die zwei neuen Antwortheader unterstützt.
Wenn Ihr Server eine Preflight-Anfrage erhält (eine OPTIONS
-Anfrage mit CORS-Headern), sollte er prüfen, ob ein Access-Control-Request-Private-Network: true
-Header vorhanden ist. Wenn dieser Header in der Anfrage vorhanden ist, sollte der Server den Origin
-Header und den Anfragepfad zusammen mit anderen relevanten Informationen (z. B. Access-Control-Request-Headers
) prüfen, um sicherzustellen, dass die Anfrage sicher zugelassen werden kann.
Normalerweise sollten Sie den Zugriff auf einen einzelnen Ursprung unter Ihrer Kontrolle zulassen.
Sobald Ihr Server die Anfrage zulässt, sollte er 204 No Content
(oder 200 OK
) mit den erforderlichen CORS-Headern und dem neuen PNA-Header antworten. Diese Header enthalten Access-Control-Allow-Origin
und Access-Control-Allow-Private-Network: true
sowie nach Bedarf weitere.
Konkrete Szenarien finden Sie in den Beispielen.
Überprüfungen des privaten Netzwerkzugriffs mithilfe von Unternehmensrichtlinien deaktivieren
Wenn Sie die administrative Kontrolle über Ihre Nutzer haben, können Sie Prüfungen für den privaten Netzwerkzugriff mit einer der folgenden Richtlinien deaktivieren:
Weitere Informationen finden Sie im Hilfeartikel Ausführliche Informationen zur Chrome-Richtlinienverwaltung.
Feedback geben
Wenn Sie eine Website in einem privaten Netzwerk hosten, das Anfragen von öffentlichen Netzwerken erwartet, interessiert sich das Chrome-Team für Ihr Feedback und Ihre Anwendungsfälle.
Informiere uns, indem du unter crbug.com ein Problem mit Chromium meldest und die Komponente auf Blink>SecurityFeature>CORS>PrivateNetworkAccess
setzt.
Nächste Schritte
Als Nächstes erweitert Chrome die Überprüfung des privaten Netzwerkzugriffs auf Web Worker: dedizierte Worker, freigegebene Worker und Service Worker. Wir versuchen, in Chrome 107 voraussichtlich Warnungen anzuzeigen.
Anschließend erweitert Chrome die Prüfungen für den privaten Netzwerkzugriff auf Navigationen, einschließlich iFrames und Pop-ups. Wir arbeiten derzeit daran, dass in Chrome 108 künftig Warnungen angezeigt werden.
In beiden Fällen werden wir mit einer ähnlichen schrittweisen Einführung vorsichtig fortfahren, um Webentwicklern Zeit zu geben, das Kompatibilitätsrisiko anzupassen und zu schätzen.
Danksagungen
Titelbild von Mark Olsen auf Unsplash