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: 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.
Warnung:Um die Auswirkungen auf Websites zu begrenzen, die noch keine Preflights unterstützen, wird das Zeitlimit in Chrome 104 auf 200 Millisekunden beschränkt. Die Einschränkung wird nur im Warnungsmodus angewendet. Das spezielle Zeitlimit wird entfernt, nachdem der erzwungene Modus durch die Einstellung „Ergebnis von Preflights zum privaten Netzwerkzugriff berücksichtigen“ in chrome://flags auf „Aktiviert“ gesetzt wurde. Das Standardlimit beträgt 5 Sekunden.
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.

Wichtiger Begriff:Private Netzwerkanfragen sind Anfragen, deren Zielserver-IP-Adresse privater ist als die, von der der Anfrageinitiator abgerufen wurde. Zum 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 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::/10RFC4291

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. — Beziehung zwischen öffentlichen, privaten, lokalen Netzwerken im privaten Netzwerkzugriff (CORS-RFC1918)

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.

Sequenzdiagramm, das CORS-Preflight darstellt. Eine OPTIONS-HTTP-Anfrage wird an das Ziel gesendet, die ein 200 OK zurückgibt. Dann wird der CORS-Anfrageheader mit einem CORS-Antwortheader gesendet.

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 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 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.

Hinweis: Wenn die Anfrage an ein privates Netzwerk im Modus cors gestellt wird, müssen CORS-Header zusätzlich zur Preflight-Antwort für die endgültige Antwort festgelegt 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

Warnung:Der Server kann Access-Control-Allow-Origin: * festlegen. Dies ist jedoch gefährlich und wird nicht empfohlen. Private Netzwerkressourcen sollten nur selten für alle Ursprünge zugänglich sein. Überlegen Sie sich also genau, welche Risiken 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 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.

Warnung zu einer fehlgeschlagenen Preflight-Anfrage im Bereich „Probleme“ der Entwicklertools. Dies besagt: Stellen Sie sicher, dass private Netzwerkanfragen nur an Ressourcen gesendet werden, die dies zulassen. Geben Sie außerdem Details zur jeweiligen Anfrage und eine Liste der betroffenen Ressourcen an.

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

Eine fehlgeschlagene Preflight-Anfrage im Bereich „Netzwerk“ der Entwicklertools für localhost gibt den Status 501.

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.

Eine gefälschte fehlgeschlagene Preflight-Anfrage vor einem erfolgreichen Preflight im Bereich „Netzwerk“ der Entwicklertools.

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