Minimieren Sie die Risiken, die mit der unbeabsichtigten Freigabe von Geräten und Servern im internen Netzwerk eines Kunden für das Internet verbunden sind.
Schadhafte Websites, die Anfragen an Geräte und Server senden, die in einem privaten Netzwerk gehostet werden, sind schon lange eine Bedrohung. Angreifer können beispielsweise die Konfiguration eines WLAN-Routers ändern, um Man-in-the-Middle zu ermöglichen. CORS-RFC1918 ist ein Vorschlag, solche Anfragen standardmäßig im Browser zu blockieren und interne Geräte zum Aktivieren von Anfragen aus dem öffentlichen Internet zu zwingen.
Um zu verstehen, wie sich diese Änderung auf das Web auswirkt, sucht das Chrome-Team nach Feedback von Entwicklern, die Server für private Netzwerke erstellen.
Was ist falsch am Status quo?
Viele Webserver werden in einem privaten Netzwerk ausgeführt. Dazu gehören unter anderem WLAN-Router, Drucker, Intranet-Websites, Unternehmensdienste und IoT-Geräte (Internet of Things). Sie befinden sich zwar in einer sichereren Umgebung als die öffentlich zugänglichen, aber diese Server können von Angreifern missbraucht werden, die eine Webseite als Proxy verwenden. So können schädliche Websites beispielsweise eine URL einbetten, die beim einfachen Aufrufen durch das Opfer (in einem JavaScript-fähigen Browser) versucht, die DNS-Servereinstellungen auf dem Breitbandrouter des Opfers zu ändern. Diese Art von Angriff wird als Drive-by-Pharming bezeichnet und ereignete sich 2014. Mehr als 300.000 angreifbare WLAN-Router wurden ausgenutzt,indem ihre DNS-Einstellungen geändert wurden und Angreifer Nutzer auf schädliche Server weiterleiten konnten.
CORS-RFC1918
Um die Gefahr ähnlicher Angriffe zu verringern, führt die Web-Community CORS-RFC1918 ein – Cross Origin Resource Sharing (CORS), das speziell für private Netzwerke in RFC1918 definiert ist.
Browser, die CORS implementieren, prüfen bei Zielressourcen, ob das Laden von einer anderen Quelle aus zulässig ist. Je nach Komplexität geschieht dies entweder mit zusätzlichen Inline-Headern, die den Zugriff beschreiben, oder mit einem Mechanismus namens Preflight-Anfragen. Weitere Informationen finden Sie unter Cross-Origin Resource Sharing.
Bei CORS-RFC1918 blockiert der Browser standardmäßig das Laden von Ressourcen über das private Netzwerk, mit Ausnahme derjenigen, die vom Server explizit mit CORS und über HTTPS zugelassen sind. Die Website, die Anfragen an diese Ressourcen sendet, muss CORS-Header senden und der Server muss explizit angeben, dass er die ursprungsübergreifende Anfrage akzeptiert, indem er mit entsprechenden CORS-Headern antwortet. Die genauen CORS-Header befinden sich noch in der Entwicklungsphase.
Entwickler solcher Geräte oder Server müssen zwei Dinge tun:
- Achten Sie darauf, dass die Website, die Anfragen an ein privates Netzwerk sendet, über HTTPS bereitgestellt wird.
- Richten Sie die Serverunterstützung für CORS-RFC1918 ein und antworten Sie mit den erwarteten HTTP-Headern.
Welche Arten von Anfragen sind betroffen?
Zu den betroffenen Anfragen gehören:
- Anfragen vom öffentlichen Netzwerk an ein privates Netzwerk
- Anfragen von einem privaten Netzwerk an ein lokales Netzwerk
- Anfragen vom öffentlichen Netzwerk an ein lokales Netzwerk
Privates Netzwerk: Ein Ziel, das in IPv4 auf den privaten Adressbereich gemäß Abschnitt 3 von RFC1918 aufgelöst wird, eine IPv4-adressierte IPv6-Adresse, bei der die adressierte IPv4-Adresse selbst privat ist, oder eine IPv6-Adresse außerhalb der Subnetze ::1/128, 2000::/3 und ff00::/8.
Ein lokales Netzwerk: Ein Ziel, das in den Bereich „Loopback“ (127.0.0.0/8) aufgelöst wird, der in Abschnitt 3.2.1.3 von RFC1122 für IPv4 definiert ist, in den Bereich „Link-Local“ (169.254.0.0/16) aufgelöst wird, der in RFC3927 für IPv4 definiert ist, in das Präfix „Unique Local Address“ (fc00::/7) aufgelöst wird, das in Abschnitt 3 von RFC4193 für IPv6 definiert ist, oder in das Präfix „Link-Local“ (fe80::/10) aufgelöst wird, das in Abschnitt 2.5.6 von RFC4291 für IPv6 definiert ist.
Öffentliches Netzwerk Alle anderen.
Pläne von Chrome zur Aktivierung von CORS-RFC1918
CORS-RFC1918 wird in Chrome in zwei Schritten eingeführt:
Schritt 1: Anfragen an Ressourcen des privaten Netzwerks sind nur von HTTPS-Webseiten zulässig
In Chrome 87 wird ein Flag hinzugefügt, das vorschreibt, dass öffentliche Websites, die Anfragen an private Netzwerkressourcen senden, HTTPS verwenden müssen. Sie können sie unter about://flags#block-insecure-private-network-requests aktivieren. Wenn dieses Flag aktiviert ist, werden alle Anfragen an eine private Netzwerkressource von einer HTTP-Website blockiert.
Ab Chrome 88 werden CORS-RFC1918-Fehler in der Console als CORS-Richtlinienfehler gemeldet.
Aktivieren Sie im Bereich Netzwerk der Chrome DevTools das Kästchen Blockierte Anfragen, um sich nur blockierte Anfragen anzusehen:
In Chrome 87 werden CORS-RFC1918-Fehler stattdessen nur in der Entwicklertools-Konsole als ERR_INSECURE_PRIVATE_NETWORK_REQUEST gemeldet.
Sie können es selbst mit dieser Testwebsite ausprobieren.
Schritt 2: Preflight-Anfragen mit einem speziellen Header senden
Wenn in Zukunft eine öffentliche Website versucht, Ressourcen aus einem privaten oder lokalen Netzwerk abzurufen, sendet Chrome vor der eigentlichen Anfrage eine Preflight-Anfrage.
Die Anfrage enthält neben anderen CORS-Anfrageheadern einen Access-Control-Request-Private-Network: true-Header. Diese Header identifizieren unter anderem den Ursprung der Anfrage, was eine detaillierte Zugriffssteuerung ermöglicht. Der Server kann mit einem Access-Control-Allow-Private-Network:
true-Header antworten, um ausdrücklich anzugeben, dass er Zugriff auf die Ressource gewährt.
Feedback erwünscht
Wenn Sie eine Website in einem privaten Netzwerk hosten, für das Anfragen von öffentlichen Netzwerken erwartet werden, interessiert sich das Chrome-Team für Ihr Feedback und Ihre Anwendungsfälle. Sie haben zwei Möglichkeiten, uns zu helfen:
- Rufen Sie
about://flags#block-insecure-private-network-requestsauf, aktivieren Sie die Markierung und prüfen Sie, ob Ihre Website wie erwartet Anfragen an die private Netzwerkressource sendet. - Wenn Probleme auftreten oder Sie Feedback haben, können Sie ein Problem unter crbug.com melden und die Komponente auf
Blink>SecurityFeature>CORS>RFC1918setzen.
Beispiel für Feedback
Unser WLAN-Router stellt eine Verwaltungswebsite für dasselbe private Netzwerk bereit, jedoch über HTTP. Wenn für Websites, in die die Verwaltungswebsite eingebettet ist, HTTPS erforderlich ist, handelt es sich um gemischte Inhalte. Sollten wir HTTPS auf der Verwaltungswebsite in einem geschlossenen Netzwerk aktivieren?
Genau diese Art von Feedback ist für Chrome interessant. Bitte melden Sie das Problem mit Ihrem konkreten Anwendungsfall unter crbug.com. Wir freuen uns auf Ihre Nachricht.
Hero-Image von Stephen Philips auf Unsplash