Updates
23. März 2023: Der Zeitplan wurde aktualisiert und wird erst ab Chrome 117 eingestellt.
19. Januar 2023: Der Zeitplan wurde aktualisiert. Die Einstellung erfolgt erst mit Chrome 114.
12. August 2022: Der Zeitplan wurde aktualisiert. Die Einstellung erfolgt erst mit Chrome 109.
10. Februar 2022: Der Artikel Zugriff auf private Netzwerke: Einführung von Preflights wurde aktualisiert.
25. August 2021: Aktualisierte Zeitleiste und Einführung eines Testzeitraums für die Einstellung.
Chrome stellt im Rahmen der Spezifikation für den privaten Netzwerkzugriff den Zugriff auf private Netzwerkendpunkte von nicht sicheren Websites ein. Ziel ist es, Nutzer vor CSRF-Angriffen (Cross-Site Request Forgery) zu schützen, die auf Router und andere Geräte in privaten Netzwerken ausgerichtet sind. Diese Angriffe haben Hunderttausende von Nutzern getroffen, sodass Angreifer sie auf schädliche Server weiterleiten konnten.
In Chrome werden die folgenden Änderungen eingeführt:
- Ab Chrome 94 werden Anfragen an private Netzwerke von unsicheren öffentlichen Websites blockiert.
- Einführung eines Testzeitraums für die Einstellung, der in Chrome endet
- Entwickler können damit eine Zeitverlängerung für ausgewählte Ursprünge beantragen, die während des Tests zur Einstellung nicht betroffen sind.
- Einführung einer Chrome-Richtlinie, mit der die Einstellung bei verwalteten Chrome-Bereitstellungen dauerhaft umgangen werden kann. Verfügbar in Chrome 92.
Wenn Sie mehr Zeit benötigen, um die Auswirkungen der Einstellung zu minimieren, registrieren Sie sich für den Testzeitraum.
Wenn Sie die administrative Kontrolle über Ihre Nutzer haben, können Sie die Funktion mithilfe von Chrome-Richtlinien wieder aktivieren.
Mit einer der folgenden Strategien können Sie die Auswirkungen der neuen Einschränkungen abmildern:
- Aktualisieren Sie Ihre Website auf HTTPS und bei Bedarf auch den Zielserver.
- Website auf HTTPS umstellen und WebTransport verwenden
- Die Einbettungsbeziehung umkehren
Zeitachse
- November 2020: Wir haben um Feedback zu den bevorstehenden Änderungen gebeten.
- März 2021: Nach der Auswertung des Feedbacks und der Kontaktaufnahme mit den Nutzern werden anstehende Änderungen angekündigt. Die Spezifikation wird von CORS-RFC1918 in „Zugriff auf private Netzwerke“ umbenannt.
- April 2021: Chrome 90 wird in der stabilen Version veröffentlicht und es werden Warnungen zur Einstellung angezeigt.
- Juni 2021: Chrome 92 wird in der Betaphase eingeführt. Anfragen an private Netzwerke aus unsicheren Kontexten sind dann nicht mehr zulässig. Aufgrund von Feedback von Entwicklern, die mehr Zeit für die Umstellung benötigen, wird die Einstellung auf Chrome 93 verschoben. Außerdem wird es eine Testphase für die Einstellung geben.
- Juli 2021: Nach weiterem Feedback von Entwicklern werden die Einstellung und die zugehörige Testversion auf Chrome 94 verschoben. Auch private Websites sind von der Einstellung nicht mehr betroffen.
- August 2021: Chrome 94 wird als Betaversion eingeführt. Webentwickler können sich jetzt für den Testzeitraum zur Einstellung registrieren.
- September 2021: Chrome 94 wird als stabile Version eingeführt. Webentwickler müssen sich für den Test zur Einstellung registriert und Testtokens in der Produktion bereitgestellt haben.
- Dezember 2022: Umfrage zum Ursprungstest gesendet und Feedback erhalten. Die Testphase für die Einstellung wird bis Chrome 113 verlängert.
- März 2023: Der Test zur Einstellung wird auf Chrome 116 verlängert und endet in Chrome 117. Ein berechtigungsbasierter alternativer Mechanismus ist in der Entwicklung und soll in Chrome 114 eingeführt werden.
- Mai 2023 (vorläufig): Der berechtigungsbasierte Mechanismus wird in Chrome 114 eingeführt. Websites können damit den Test zur Einstellung beenden.
- September 2023: Chrome 117 wird in der stabilen Version eingeführt. Damit endet der Testzeitraum für die Einstellung. Chrome blockiert alle privaten Netzwerkanfragen aus öffentlichen, nicht sicheren Kontexten.
Was ist der private Netzwerkzugriff?
Der Zugriff auf private Netzwerke (früher CORS-RFC1918) schränkt die Möglichkeit von Websites ein, Anfragen an Server in privaten Netzwerken zu senden. Solche Anfragen sind nur aus sicheren Kontexten zulässig. Durch die Spezifikation wird auch das CORS-Protokoll (Cross-Origin Resource Sharing) erweitert, sodass Websites nun explizit eine Erteilung von Servern in privaten Netzwerken anfordern müssen, bevor sie beliebige Anfragen senden dürfen.
Anfragen für private Netzwerke sind Anfragen, deren IP-Adresse des Zielservers privater ist als die, von der der Anfrageinitiator abgerufen wurde. Das kann beispielsweise eine Anfrage von einer öffentlichen Website (https://example.com) an eine private Website (http://router.local) oder eine Anfrage von einer privaten Website an den lokalen Host sein.
Weitere Informationen finden Sie unter Feedback gewünscht: CORS für private Netzwerke (RFC1918).
Was ist ein Test zur Einstellung?
Tests zur Einstellung (früher als umgekehrte Ursprungstests bezeichnet) sind eine Form von Ursprungstests, die die Einstellung von Webfunktionen erleichtern. Mit Deaktivierungstests kann Chrome bestimmte Webfunktionen einstellen und verhindern, dass Websites neue Abhängigkeiten von ihnen aufbauen. Gleichzeitig erhalten derzeit abhängige Websites mehr Zeit für die Migration.
Während eines Tests zur Einstellung sind die eingestellten Funktionen standardmäßig nicht für alle Websites verfügbar. Entwickler, die die betroffenen Funktionen weiterhin verwenden müssen, müssen sich für den Testzeitraum zur Einstellung registrieren und Tokens für bestimmte Web-Quellen abrufen. Anschließend müssen sie ihre Websites so ändern, dass diese Tokens in HTTP-Headern oder Meta-Tags bereitgestellt werden (außer in diesem Fall). Wenn eine Website gültige Tokens mit dem entsprechenden Ursprung sendet, erlaubt Chrome die Verwendung der eingestellten Funktion für eine begrenzte Zeit.
Weitere Informationen finden Sie unter Erste Schritte mit den Ursprungstests von Chrome und im Webentwicklerleitfaden zu Ursprungstests.
Änderungen in Chrome
Chrome 94
Ab Chrome 94 ist es öffentlichen, nicht sicheren Kontexten (im Allgemeinen Websites, die nicht über HTTPS oder von einer privaten IP-Adresse aus bereitgestellt werden) nicht mehr gestattet, Anfragen an das private Netzwerk zu senden. Dies war zuvor für Chrome 92 geplant, daher wird in den Einstellungsbenachrichtigungen möglicherweise noch der frühere Meilenstein erwähnt.
Zu dieser Einstellung gehört ein Test zur Einstellung. Webentwickler, deren Websites die eingestellte Funktion nutzen, können sie bis Chrome 116 weiter nutzen, indem sie sich für Tokens registrieren. Unten finden Sie eine Anleitung dazu, wie Sie sich registrieren und die Testversion auf Ihrer Website aktivieren.
Mit zwei Chrome-Richtlinien lässt sich die Einstellung entweder vollständig oder für bestimmte Ursprünge auf unbestimmte Zeit deaktivieren. So können bei verwalteten Chrome-Installationen, z. B. in Unternehmensumgebungen, Fehler vermieden werden.
Chrome 117
Der Testzeitraum für die Einstellung endet. Alle Websites müssen von der eingestellten Funktion migriert werden oder die Richtlinien der Nutzer müssen so konfiguriert werden, dass die Funktion weiterhin aktiviert ist.
Empfohlene Maßnahmen für Entwickler
Der erste Schritt für betroffene Websites besteht höchstwahrscheinlich darin, etwas Zeit zu gewinnen, bis eine geeignete Lösung implementiert werden kann: entweder durch die Registrierung für den Testzeitraum für die Einstellung oder durch die Verwendung von Richtlinien. Die empfohlenen Maßnahmen variieren dann je nach den Umständen der jeweiligen betroffenen Website.
Für den Testzeitraum zur Einstellung registrieren
- Klicken Sie für den Ursprungstest „Privater Netzwerkzugriff aus nicht sicheren Kontexten“ auf Registrieren, um ein Testtoken für den teilnehmenden Ursprung zu erhalten.
- Fügen Sie dem Antwortheader die
Origin-Trial: $tokenfür die Quelle hinzu. Dieser Antwortheader muss nur für Hauptressourcen und Navigationsantworten festgelegt werden, wenn das resultierende Dokument die eingestellte Funktion verwendet. Es ist zwar nutzlos, aber harmlos, diesen Header an Subressourcenantworten anzuhängen.
Da dieser Test aktiviert oder deaktiviert werden muss, bevor ein Dokument Anfragen stellen darf, kann er nicht über ein <meta>-Tag aktiviert werden. Solche Tags werden erst aus dem Antworttext geparst, nachdem möglicherweise Unterressourcenanforderungen gesendet wurden. Das stellt eine Herausforderung für Websites dar, bei denen die Antwortheader nicht verwaltet werden können, z. B. für statische github.io-Websites, die von einem Drittanbieter gehostet werden.
Weitere Informationen finden Sie im Webentwicklerleitfaden zu Ursprungstests.
Richtlinien aktivieren
Wenn Sie Administratorzugriff auf Ihre Nutzer haben, können Sie die eingestellte Funktion mit einer der folgenden Richtlinien wieder aktivieren:
Weitere Informationen zum Verwalten von Richtlinien für Ihre Nutzer finden Sie in diesem Hilfeartikel.
Auf localhost zugreifen
Wenn Ihre Website Anfragen an localhost senden muss, müssen Sie nur Ihre Website auf HTTPS umstellen.
Anfragen, die auf http://localhost (oder http://127.*.*.*, http://[::1]) ausgerichtet sind, werden durch gemischte Inhalte nicht blockiert, auch wenn sie aus sicheren Kontexten stammen.
Die WebKit-Engine und die darauf basierenden Browser (insbesondere Safari) weichen hier von der W3C-Spezifikation für gemischte Inhalte ab und verbieten diese Anfragen als gemischte Inhalte. Sie implementieren auch keinen privaten Netzwerkzugriff. Daher möchten Websites möglicherweise Clients, die solche Browser verwenden, zu einer HTTP-Klartext-Version der Website weiterleiten, die von solchen Browsern weiterhin berechtigt wäre, Anfragen an localhost zu senden.
Zugriff auf private IP-Adressen
Wenn Ihre Website Anfragen an einen Zielserver mit einer privaten IP-Adresse senden muss, funktioniert es nicht, die Initiator-Website einfach auf HTTPS umzustellen. Durch gemischte Inhalte können sichere Kontexte keine Anfragen über HTTP im Klartext senden. Daher kann die neu gesicherte Website die Anfragen weiterhin nicht stellen. Es gibt mehrere Möglichkeiten, dieses Problem zu beheben:
- Stellen Sie beide Enden auf HTTPS um.
- Verwende WebTransport, um eine sichere Verbindung zum Zielserver herzustellen.
- Kehre die Beziehung der Einbettung um.
Beide Enden auf HTTPS umstellen
Für diese Lösung ist die Kontrolle über die DNS-Auflösung der Nutzer erforderlich, z. B. in Intranet-Kontexten oder wenn Nutzer die Adressen ihrer Namensserver von einem DHCP-Server abrufen, der sich in Ihrer Kontrolle befindet. Außerdem benötigen Sie einen Domainnamen in der Public Domain.
Das Hauptproblem beim Bereitstellen privater Websites über HTTPS besteht darin, dass Zertifizierungsstellen der Public-Key-Infrastruktur (PKI CA) nur TLS-Zertifikate für Websites mit öffentlichen Domainnamen ausstellen. So können Sie dieses Problem umgehen:
- Registrieren Sie einen öffentlichen Domainnamen (z. B.
intranet.example) und veröffentlichen Sie DNS-Einträge, die diesen Domainnamen auf einen öffentlichen Server Ihrer Wahl verweisen. - Holen Sie ein TLS-Zertifikat für
intranet.example. - Konfigurieren Sie das DNS in Ihrem privaten Netzwerk so, dass
intranet.exampleauf die private IP-Adresse des Zielservers aufgelöst wird. - Konfigurieren Sie Ihren privaten Server für die Verwendung des TLS-Zertifikats für
intranet.example. So können Ihre Nutzer auf den privaten Server unterhttps://intranet.examplezugreifen.
Sie können dann die Website, die die Anfragen initiiert, auf HTTPS umstellen und die Anfragen wie gewohnt weitergeben.
Diese Lösung ist zukunftssicher und reduziert das Vertrauen in Ihr Netzwerk, da die Ende-zu-Ende-Verschlüsselung in Ihrem privaten Netzwerk erweitert wird.
WebTransport
Für diese Lösung ist keine Kontrolle über die DNS-Auflösung Ihrer Nutzer erforderlich. Der Zielserver muss dafür einen minimalen WebTransport-Server ausführen (HTTP/3-Server mit einigen Änderungen).
Sie können das Fehlen eines gültigen TLS-Zertifikats, das von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde, umgehen, indem Sie WebTransport und seinen Zertifizierungs-Pinning-Mechanismus verwenden. So können sichere Verbindungen zu privaten Geräten hergestellt werden, die beispielsweise ein selbstsigniertes Zertifikat haben. WebTransport-Verbindungen ermöglichen eine bidirektionale Datenübertragung, jedoch keine Abrufanfragen. Sie können diesen Ansatz mit einem Service Worker kombinieren, um HTTP-Anfragen aus Sicht Ihrer Webanwendung transparent über die Verbindung weiterzuleiten. Auf der Serverseite kann eine entsprechende Übersetzungsschicht die WebTransport-Nachrichten in HTTP-Anfragen umwandeln.
Uns ist bewusst, dass dies eine Menge Arbeit bedeutet, aber es sollte deutlich einfacher sein als die Entwicklung auf Basis von WebRTC. Wir hoffen auch, dass ein Teil der erforderlichen Investitionen in wiederverwendbare Bibliotheken implementiert wird. Außerdem ist es besonders wichtig, zu berücksichtigen, dass Nutzer in nicht sicheren Kontexten wahrscheinlich den Zugriff auf immer mehr Webplattformfunktionen verlieren, da die Plattform im Laufe der Zeit immer stärker zur Nutzung von HTTPS ermutigt. Unabhängig vom privaten Netzwerkzugriff wäre dies auf jeden Fall eine sinnvolle Investition.
Wir gehen davon aus, dass WebTransport über HTTP/3 in Chrome 96 eingeführt wird (ein Ursprungstest hat bereits begonnen). Es werden Schutzmaßnahmen gegen die Weitergabe von Schlüsseln und andere Sicherheitspraktiken mit minderwertigen Standards implementiert, darunter:
- Eine kurze maximale Ablaufzeit für angepinnte Zertifikate.
- Ein browserspezifischer Mechanismus zum Widerrufen bestimmter Schlüssel, die missbraucht wurden.
Die Einschränkung für sicheren Kontext wird erst nach mindestens zwei Meilensteinen nach der vollständigen Einführung von WebTransport eingeführt. Der Testzeitraum für die Einstellung wird bei Bedarf verlängert.
Reverse Embedding
Diese Lösung erfordert keine administrative Kontrolle über das Netzwerk und kann verwendet werden, wenn der Zielserver nicht leistungsstark genug ist, um HTTPS auszuführen.
Anstatt private Unterressourcen von einer öffentlichen Webanwendung abzurufen, kann ein Skelett der App vom privaten Server bereitgestellt werden, der dann alle Unterressourcen (z. B. Scripts oder Bilder) von einem öffentlichen Server wie einem CDN abholt. Die daraus resultierende Webanwendung kann dann Anfragen an den privaten Server senden, da diese als „gleicher Ursprung“ betrachtet werden. Sie kann sogar Anfragen an andere Server mit privaten IP-Adressen (aber nicht an localhost) senden. Dies kann sich jedoch langfristig ändern.
Wenn Sie nur ein Skelett auf dem privaten Server hosten, können Sie die Webanwendung aktualisieren, indem Sie neue Ressourcen auf den öffentlichen Server pushen, genau wie Sie eine öffentliche Webanwendung aktualisieren würden. Andererseits ist die resultierende Webanwendung kein sicherer Kontext und hat daher keinen Zugriff auf einige der leistungsfähigeren Funktionen des Webs.
Zukunftspläne
Die Beschränkung von Anfragen an private Netzwerke auf sichere Kontexte ist nur der erste Schritt bei der Einführung des privaten Netzwerkzugriffs. In den kommenden Monaten wird der Rest der Spezifikation in Chrome implementiert. Wir halten dich über Updates auf dem Laufenden.
Zugriff auf localhost von privaten Websites einschränken
Die Änderungen in Chrome 94 wirken sich nur auf öffentliche Websites aus, die auf private IP-Adressen oder den lokalen Host zugreifen. Die Spezifikation für den Zugriff auf private Netzwerke klassifiziert auch Anfragen von privaten Websites an localhost als problematisch. Auch diese werden in Chrome irgendwann eingestellt. Dies stellt jedoch eine etwas andere Reihe von Herausforderungen dar, da viele private Websites keine Domainnamen haben, was die Verwendung von Tokens für den Test zur Einstellung erschwert.
CORS-Preflight-Anfragen
Der zweite Teil des privaten Netzwerkzugriffs besteht darin, private Netzwerkanfragen, die aus sicheren Kontexten stammen, mit CORS-Preflight-Anfragen zu steuern. Der Zielserver wird aufgefordert, dem Initiator eine explizite Genehmigung zu erteilen, auch wenn die Anfrage aus einem sicheren Kontext initiiert wurde. Die Anfrage wird nur gesendet, wenn die Bewilligung erfolgreich war.
Kurz gesagt ist eine CORS-Preflight-Anfrage eine HTTP-OPTIONS-Anfrage mit einigen Access-Control-Request-*-Headern, die die Art der nachfolgenden Anfrage angeben. Der Server kann dann entscheiden, ob er einen detaillierten Zugriff gewähren möchte, indem er 200 OK mit Access-Control-Allow-*-Headern antwortet.
Weitere Informationen hierzu finden Sie in der Spezifikation.
Navigationsabrufe einschränken
Chrome führt Unterressourcen-Anfragen an private Netzwerke ein und blockiert sie schließlich. Das gilt nicht für Navigationen zu privaten Netzwerken, die auch bei CSRF-Angriffen verwendet werden können.
Die Spezifikation für den privaten Netzwerkzugriff unterscheidet nicht zwischen den beiden Arten von Abrufen, die letztendlich denselben Einschränkungen unterliegen.
Titelbild von Markus Spiske auf Unsplash