Updates
23. März 2023: Der Zeitplan wurde aktualisiert und die Einstellung erfolgt erst ab Chrome 117.
19. Januar 2023: Der Zeitplan wurde aktualisiert und wird erst ab Chrome 114 eingestellt.
12. August 2022: Der Zeitplan wurde aktualisiert und wird erst ab Chrome 109 eingestellt.
10. Februar 2022: Unter Privater Netzwerkzugriff: Einführung von Preflights wird ein aktualisierter Artikel veröffentlicht.
25. August 2021: Aktualisierter Zeitplan und Einführung eines Einstellungstests.
Im Rahmen der Spezifikation für den privaten Netzwerkzugriff wird der Zugriff auf private Netzwerkendpunkte von nicht sicheren Websites für Chrome eingestellt. Nutzer sollen vor CSRF-Angriffen (Cross-Site Request Forgery) geschützt werden, 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.
In Chrome werden die folgenden Änderungen eingeführt:
- Anfragen an private Netzwerke von unsicheren öffentlichen Websites ab Chrome 94 blockieren.
- Wir führen einen Test zur Einstellung ein, der in Chrome endet.
- Entwickler können damit eine Fristverlängerung für ausgewählte Ursprünge beantragen, was während des Einstellungstests nicht betroffen ist.
- Einführung einer Chrome-Richtlinie, die es verwalteten Chrome-Bereitstellungen ermöglicht, die Einstellung dauerhaft zu umgehen. Verfügbar in Chrome 92.
Wenn Sie mehr Zeit benötigen, um die Auswirkungen des Einstellungsregisters für den Einstellungstest zu minimieren.
Wenn Sie die administrative Kontrolle über Ihre Nutzer haben, können Sie die Funktion mithilfe von Chrome-Richtlinien wieder aktivieren.
Verwenden Sie eine der folgenden Strategien, um die Auswirkungen der neuen Einschränkungen zu minimieren:
- Stellen Sie Ihre Website auf HTTPS und gegebenenfalls den Zielserver um.
- Aktualisieren Sie Ihre Website auf HTTPS und verwenden Sie WebTransport.
- Umkehrung der Einbettungsbeziehung:
Zeitplan
- November 2020: Bitte um Feedback zu den bevorstehenden Änderungen.
- März 2021: Nachdem das Feedback geprüft und die Kontaktaufnahme durchgeführt wurde, werden bevorstehende Änderungen bekannt gegeben. Die Spezifikation wurde von CORS-RFC1918 in „Privater Netzwerkzugriff“ umbenannt.
- April 2021: Chrome 90 wird als stabile Version eingeführt. Hier werden Warnungen zur Einstellung angezeigt.
- Juni 2021: Chrome 92 wird in der Betaversion eingeführt und unterbietet private Netzwerkanfragen aus unsicheren Kontexten. Da Entwickler sich mehr Zeit für die Anpassung wünschten, wird die Einstellung auf Chrome 93 verschoben und es wird ein Testzeitraum für die Einstellung eingeführt.
- Juli 2021: Nach weiterem Feedback von Entwicklern wurden 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 für den Test zur Einstellung anmelden.
- September 2021: Chrome 94 wird als stabile Version eingeführt. Webentwickler sollten sich für den Einstellungstest angemeldet und Testtokens für die Produktion bereitgestellt haben.
- Dezember 2022: Umfrage zu Ursprungstests gesendet und Feedback dazu erhalten. Der Testzeitraum für die Einstellung verlängert sich bis Chrome 113.
- März 2023: Der Einstellungstest wird auf Chrome 116 verlängert und endet in Chrome 117. Derzeit wird ein berechtigungsbasierter alternativer Mechanismus entwickelt, der auf den ersten Release in Chrome 114 ausgerichtet ist.
- Mai 2023 (vorläufig): Der berechtigungsbasierte Mechanismus wird in Chrome 114 eingeführt. Websites können sie verwenden, um den Einstellungstest zu beenden.
- September 2023: Chrome 117 wird als stabile Version eingeführt. Der Einstellungstest wird beendet. Chrome blockiert alle privaten Netzwerkanfragen aus öffentlichen, nicht sicheren Kontexten.
Was ist ein privater Netzwerkzugriff?
Der private Netzwerkzugriff (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. 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.
Anfragen privater Netzwerke 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.
Weitere Informationen finden Sie unter Feedback erwünscht: CORS für private Netzwerke (RFC1918).
Was ist ein Einstellungstest?
Einstellungstests (früher „Reverse-Ursprungstests“) sind eine Form von Ursprungstests, mit denen die Einstellung von Webfunktionen vereinfacht wird. Einstellungstests ermöglichen es Chrome, bestimmte Webfunktionen einzustellen und zu verhindern, dass Websites neue Abhängigkeiten von ihnen bilden. Gleichzeitig geben aktuellen abhängigen Websites zusätzliche Zeit für die Migration von ihnen.
Während eines Einstellungstests sind die verworfenen 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 Einstellungstest registrieren und Tokens für bestimmte Webursprünge 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 bereitstellt, die mit ihrem Ursprung übereinstimmen, erlaubt Chrome für eine begrenzte Zeit die Verwendung der eingestellten Funktion.
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 nicht mehr zulässig, in öffentlichen, nicht sicheren Kontexten, d. h. Websites, die nicht über HTTPS oder von einer privaten IP-Adresse bereitgestellt werden, Anfragen an das private Netzwerk zu senden. Dies war zuvor für Chrome 92 geplant, daher wird in Mitteilungen zur Einstellung möglicherweise noch der frühere Meilenstein erwähnt.
Mit dieser Einstellung wird ein Test zur Einstellung der neuen Funktion einhergehen. Webentwickler, deren Websites die eingestellte Funktion nutzen, können sie bis zu Chrome 116 weiter nutzen, indem sie sich für Tokens registrieren. Unten finden Sie eine Anleitung zur Registrierung und Aktivierung des Testzeitraums auf Ihrer Website.
Mit zwei Chrome-Richtlinien lässt sich die Einstellung entweder ganz oder an bestimmten Ursprüngen deaktivieren, und zwar auf unbestimmte Zeit. Dadurch können verwaltete Chrome-Installationen, z. B. in Unternehmenseinstellungen, reibungslos funktionieren.
Chrome 117
Der Test zur Einstellung endet. Alle Websites müssen aus der eingestellten Funktion migriert werden oder die Richtlinien ihrer Nutzer müssen konfiguriert sein, damit die Funktion weiterhin aktiviert werden kann.
Empfohlene Maßnahmen für Entwickler
Der erste Schritt für betroffene Websites dauert höchstwahrscheinlich etwas Zeit, bis eine ordnungsgemäße Lösung bereitgestellt werden kann. Dazu können Sie sich entweder für den Einstellungstest registrieren oder Richtlinien verwenden. Die empfohlene Vorgehensweise hängt von den Umständen der jeweiligen Website ab.
Für den Einstellungstest registrieren
- Klicken Sie für den Ursprungstest mit nicht sicheren Kontexten auf Registrieren, um ein Testtoken für die teilnehmende Quelle zu erhalten.
- Fügen Sie dem Antwortheader das ursprungsspezifische
Origin-Trial: $tokenhinzu. Dieser Antwortheader muss nur für Hauptressourcen- und Navigationsantworten festgelegt werden, wenn im resultierenden Dokument die verworfene Funktion verwendet wird. Es ist nutzlos (wenn auch harmlos), diesen Header an Antworten von Unterressourcen anzuhängen.
Da dieser Test aktiviert oder deaktiviert werden muss, bevor ein Dokument Anfragen senden darf, kann er nicht über ein <meta>-Tag aktiviert werden. Solche Tags werden erst dann aus dem Antworttext geparst, wenn Unterressourcenanfragen möglicherweise gesendet wurden. Dies stellt eine Herausforderung für Websites dar, die keine Kontrolle über Antwortheader haben, z. B. statische Websites auf github.io, die von einem Drittanbieter bereitgestellt werden.
Weitere Informationen finden Sie im Webentwicklerleitfaden für Ursprungstests.
Richtlinien aktivieren
Wenn Sie die administrative Kontrolle über 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 aktualisieren.
Anfragen, die auf http://localhost (oder http://127.*.*.*, http://[::1]) ausgerichtet sind, werden durch gemischte Inhalte nicht blockiert, selbst wenn sie aus sicheren Kontexten stammen.
Beachten Sie, dass die WebKit-Engine und die darauf basierenden Browser (insbesondere Safari) hier von der W3C-Spezifikation für gemischte Inhalte abweichen und diese Anfragen als gemischte Inhalte verbieten. Außerdem wird der private Netzwerkzugriff nicht implementiert. Daher möchten Websites möglicherweise Clients, die solche Browser verwenden, zu einer Klartext-HTTP-Version der Website weiterleiten, die von diesen Browsern weiterhin Anfragen an localhost senden darf.
Auf private IP-Adressen zugreifen
Wenn Ihre Website Anfragen an einen Zielserver über eine private IP-Adresse senden muss, funktioniert das einfache Upgrade der Initiator-Website auf HTTPS nicht. Gemischte Inhalte verhindern, dass sichere Kontexte Anfragen über Nur-Text-HTTP senden. Daher kann die neu gesicherte Website diese Anfragen weiterhin nicht stellen. Es gibt mehrere Möglichkeiten, dieses Problem zu lösen:
- Stellen Sie beide Enden auf HTTPS um.
- Verwenden Sie WebTransport, um eine sichere Verbindung zum Zielserver herzustellen.
- Kehrt die Einbettungsbeziehung um.
Beide Enden auf HTTPS umstellen
Diese Lösung erfordert Kontrolle über die DNS-Auflösung der Nutzer, z. B. in Intranetkontexten oder wenn Nutzer die Adressen ihrer Nameserver von einem DHCP-Server in Ihrer Kontrolle abrufen. Außerdem musst du einen urheberrechtsfreien Namen haben.
Das Hauptproblem bei der Bereitstellung privater Websites über HTTPS besteht darin, dass die Public-Key-Infrastruktur-Zertifizierungsstellen (PKI CA) TLS-Zertifikate nur für Websites mit öffentlichen Domainnamen bereitstellen. So umgehen Sie dieses Problem:
- 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. - Fordern Sie ein TLS-Zertifikat für
intranet.examplean. - Konfigurieren Sie das DNS in Ihrem privaten Netzwerk so, dass
intranet.examplezur privaten IP-Adresse des Zielservers aufgelöst wird. - Konfigurieren Sie Ihren privaten Server so, dass das TLS-Zertifikat für
intranet.exampleverwendet wird. Dadurch können Ihre Nutzer auf den privaten Server unterhttps://intranet.examplezugreifen.
Anschließend können Sie die Website, die die Anfragen über HTTPS initiiert, auf HTTPS umstellen und die Anfragen wie zuvor ausführen.
Diese Lösung ist zukunftssicher und verringert das Vertrauen, das Sie in Ihr Netzwerk setzen, und erweitert so die Nutzung der Ende-zu-Ende-Verschlüsselung in Ihrem privaten Netzwerk.
WebTransport
Diese Lösung erfordert keine Kontrolle über die DNS-Auflösung Ihrer Nutzer. Dazu muss auf dem Zielserver ein minimaler WebTransport-Server ausgeführt werden (HTTP/3-Server mit einigen Änderungen).
Sie können das Fehlen eines gültigen TLS-Zertifikats umgehen, das von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde, indem Sie WebTransport und den Mechanismus zum Zurückstellen von Zertifikaten verwenden. Dadurch können sichere Verbindungen zu privaten Geräten hergestellt werden, die beispielsweise ein selbst signiertes Zertifikat haben könnten. WebTransport-Verbindungen ermöglichen eine bidirektionale Datenübertragung, aber 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 darstellt, aber wesentlich einfacher sein sollte, als auf WebRTC aufzubauen. Wir hoffen auch, dass ein Teil der erforderlichen Investition als wiederverwendbare Bibliotheken implementiert wird. Wir sind auch der Meinung, dass es besonders lohnenswert ist, die Tatsache zu berücksichtigen, dass unsichere Kontexte wahrscheinlich den Zugriff auf immer mehr Webplattformfunktionen verlieren, da die Plattform im Laufe der Zeit immer stärker die Verwendung von HTTPS verstärkt. Unabhängig vom privaten Netzwerkzugriff ist dies in jedem Fall eine sinnvolle Investition.
Wir gehen davon aus, dass WebTransport über HTTP/3 in Chrome 96 verfügbar sein wird (ein Ursprungstest wurde gestartet) mit Abhilfemaßnahmen zum Schutz vor der Schlüsselfreigabe und anderen Sicherheitsmaßnahmen, die dem Standard entsprechen, darunter:
- Eine kurze maximale Ablaufzeit für angepinnte Zertifikate.
- Ein browserspezifischer Mechanismus zum Widerrufen bestimmter, missbräuchlicher Schlüssel.
Wir versenden die Einschränkung für sicheren Kontext erst mindestens zwei Meilensteine nach der vollständigen Einführung von WebTransport. Der Einstellungstest wird bei Bedarf verlängert.
Umgekehrte Einbettung
Diese Lösung erfordert keine administrative Kontrolle über das Netzwerk und kann verwendet werden, wenn der Zielserver nicht leistungsfähig genug ist, um HTTPS auszuführen.
Anstatt private Unterressourcen aus einer öffentlichen Webanwendung abzurufen, kann ein Grundgerüst der Anwendung vom privaten Server bereitgestellt werden. Dieser ruft dann alle seine Unterressourcen (z. B. Skripts oder Bilder) von einem öffentlichen Server wie einem CDN ab. Die resultierende Webanwendung kann dann Anfragen an den privaten Server senden, da diese als Same-Origin gelten. Er kann sogar Anfragen an andere Server mit privaten IP-Adressen (aber nicht an localhost) senden, obwohl sich dies langfristig ändern kann.
Wenn Sie nur ein Grundgerüst auf dem privaten Server hosten, können Sie die Webanwendung aktualisieren. Dazu werden neue Ressourcen auf den öffentlichen Server übertragen, genau wie eine öffentliche Webanwendung. Andererseits ist die resultierende Webanwendung kein sicherer Kontext, sodass sie keinen Zugriff auf einige der leistungsstärkeren Funktionen des Webs hat.
Pläne für die Zukunft
Die Beschränkung privater Netzwerkanfragen auf sichere Kontexte ist nur der erste Schritt beim Start des privaten Netzwerkzugriffs. Chrome arbeitet daran, in den kommenden Monaten die restlichen Spezifikationen zu implementieren. Wir halten dich über Updates auf dem Laufenden.
Zugriff auf lokale Hosts von privaten Websites einschränken
Die Änderungen in Chrome 94 betreffen nur öffentliche Websites, die auf private IP-Adressen oder den lokalen Host zugreifen. Die Spezifikation für den privaten Netzwerkzugriff klassifiziert auch Anfragen von private Websites an localhost als problematisch. Auch diese werden in Chrome eingestellt. Dies stellt jedoch eine etwas andere Herausforderung dar, da viele private Websites keine Domainnamen haben, was die Verwendung von Testtokens zur Einstellung von Produkten erschwert.
CORS-Preflight-Anfragen
Der zweite Teil des privaten Netzwerkzugriffs besteht darin, Anfragen für private Netzwerke, die aus sicheren Kontexten initiiert wurden, mit CORS-Preflight-Anfragen zu sperren. Die Idee dahinter ist, dass der Zielserver selbst dann aufgefordert wird, dem Initiator eine explizite Genehmigung zu erteilen, wenn die Anfrage aus einem sicheren Kontext initiiert wurde. Die Anfrage wird nur gesendet, wenn die Erteilung erfolgreich war.
Eine CORS-Preflight-Anfrage ist also eine HTTP-OPTIONS-Anfrage mit einigen Access-Control-Request-*-Headern, die die Art der nachfolgenden Anfrage angeben. Der Server kann dann entscheiden, ob er detaillierten Zugriff gewähren möchte, indem er 200 OK mit Access-Control-Allow-*-Headern antwortet.
Weitere Informationen hierzu finden Sie in der Spezifikation.
Abrufe von Navigationsinformationen einschränken
Chrome stellt Anfragen von Unterressourcen an private Netzwerke ein und blockiert sie. Dies hat keine Auswirkungen auf die Navigation zu privaten Netzwerken, die auch für CSRF-Angriffe 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