Feedback gewünscht: CORS für private Netzwerke (RFC1918)

Minimieren Sie die Risiken, die mit einer unbeabsichtigten Offenlegung von Geräten und Servern im internen Netzwerk eines Kunden im Allgemeinen verbunden sind.

Eiji Kitamura

Hinweis:CORS-RFC1918 wurde der Übersichtlichkeit halber in „Privater Netzwerkzugriff“ umbenannt. Im Blog developer.chrome.com gibt es ein Update zu diesem Beitrag.

Schädliche Websites, die Anfragen an Geräte und Server in einem privaten Netzwerk senden, sind schon lange eine Bedrohung. Angreifer können beispielsweise die Konfiguration eines WLAN-Routers ändern, um Man-in-the-Middle-Angriffe zu ermöglichen. CORS-RFC1918 ist ein Vorschlag, solche Anfragen standardmäßig im Browser zu blockieren und festzulegen, dass interne Geräte Anfragen aus dem öffentlichen Internet genehmigen müssen.

Um zu verstehen, wie sich diese Änderung auf das Web auswirkt, bittet das Chrome-Team um Feedback von Entwicklern, die Server für private Netzwerke bauen.

Was stimmt nicht mit dem Status quo?

Viele Webserver werden in einem privaten Netzwerk ausgeführt – WLAN-Router, Drucker, Intranetwebsites, Unternehmensdienste und Geräte für das Internet der Dinge (IoT). Sie scheinen sich in einer sichereren Umgebung zu befinden als die öffentlich zugänglichen, aber diese Server können von Angreifern missbraucht werden, die eine Webseite als Proxy verwenden. Schädliche Websites können beispielsweise eine URL einbetten, die versucht, die DNS-Servereinstellungen auf dem privaten Breitbandrouter des Opfers zu ändern, wenn sie nur vom Opfer in einem JavaScript-fähigen Browser aufgerufen wird. Diese Art von Angriff wird als „Drive-By Pharming“ bezeichnet und hat 2014 stattgefunden. Mehr als 300.000 anfällige WLAN-Router wurden ausgenutzt, indem ihre DNS-Einstellungen geändert wurden und Angreifern ermöglichten, Nutzer auf schädliche Server umzuleiten.

CORS-RFC1918

Um die Gefahr ähnlicher Angriffe abzuschwächen, führt die Web-Community CORS-RFC1918 – Cross-Origin Resource Sharing (CORS) ein, das auf private Netzwerke gemäß RFC1918 spezialisiert ist.

Browser, die CORS implementieren, prüfen mit den Zielressourcen, ob sie von einem anderen Ursprung geladen werden können. Dazu werden entweder zusätzliche Header inline, die den Zugriff beschreiben, oder ein Mechanismus namens Preflight-Anfragen verwendet, je nach Komplexität. Weitere Informationen finden Sie unter Cross-Origin Resource Sharing.

Mit 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 wurden. Die Website, die Anfragen an diese Ressourcen stellt, muss CORS-Header senden. 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 werden gebeten, zwei Dinge zu tun:

• Sorgen Sie dafür, 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 erwarteten HTTP-Headern.

Welche Arten von Anfragen sind betroffen?

Betroffene Anfragen:

• 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

Ein privates Netzwerk Ein Ziel, das in den privaten Adressbereich aufgelöst wird, der in Abschnitt 3 von RFC1918 in IPv4 definiert ist, eine IPv4-zugeordnete IPv6-Adresse, bei der die zugeordnete IPv4-Adresse selbst privat ist, oder eine IPv6-Adresse außerhalb der Subnetze ::1/128, 2000::/3 und ff00::/8.

Ein lokales Netzwerk 127.0.0.0/8RFC1122169.254.0.0/16RFC3927fc00::/7RFC4193fe80::/10RFC4291

Ein öffentliches Netzwerk Alle anderen.

Beziehung zwischen öffentlichen, privaten, lokalen Netzwerken in CORS-RFC1918.

Pläne von Chrome zur Aktivierung von CORS-RFC1918

Chrome führt CORS-RFC1918 in zwei Schritten ein:

Schritt 1: Anfragen an private Netzwerkressourcen sind nur über HTTPS-Webseiten zulässig

In Chrome 87 wird ein Flag hinzugefügt, das dafür sorgt, dass öffentliche Websites, die Anfragen an private Netzwerkressourcen senden, HTTPS verwenden. 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 Konsole als CORS-Richtlinienfehler gemeldet.

CORS-RFC1918-Fehler werden in der Console als CORS-Richtlinienfehler gemeldet.

Im Bereich Netzwerk der Chrome-Entwicklertools können Sie das Kästchen Blockierte Anfragen aktivieren, um sich auf blockierte Anfragen zu konzentrieren:

CORS-RFC1918-Fehler werden auch als CORS-Fehler im Bereich Netzwerk gemeldet.

In Chrome 87 werden CORS-RFC1918-Fehler in der Entwicklertools-Konsole stattdessen nur als ERR_INSECURE_PRIVATE_NETWORK_REQUEST gemeldet.

Auf dieser Testwebsite können Sie die Funktion selbst 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 zusätzlich zu anderen CORS-Anfrageheadern einen Access-Control-Request-Private-Network: true-Header. Diese Header identifizieren unter anderem den Ursprung, von dem die Anfrage stammt, und ermöglicht so eine differenzierte Zugriffssteuerung. Der Server kann mit einem Access-Control-Allow-Private-Network: true-Header antworten, um explizit anzugeben, dass er Zugriff auf die Ressource gewährt.

Hinweis:Diese Überschriften befinden sich noch in der Entwicklung und können sich in Zukunft ändern. Derzeit sind keine Maßnahmen erforderlich.

Feedback erwünscht

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. Es gibt zwei Dinge, die Sie tun können, um zu helfen:

• Rufen Sie about://flags#block-insecure-private-network-requests auf, aktivieren Sie das Flag und prüfen Sie, ob Ihre Website Anfragen wie erwartet an die private Netzwerkressource sendet.
• Wenn Probleme auftreten oder du Feedback hast, kannst du unter crbug.com ein Problem melden und die Komponente auf Blink>SecurityFeature>CORS>RFC1918 setzen.

Beispiel für Feedback

Unser WLAN-Router dient einer Administrator-Website für dasselbe private Netzwerk, jedoch über HTTP. Wenn HTTPS für Websites erforderlich ist, auf denen die Administratorwebsite eingebettet ist, werden gemischte Inhalte verwendet. Sollten wir HTTPS auf der Administrator-Website in einem geschlossenen Netzwerk aktivieren?

Genau diese Art von Feedback sucht Chrome. Bitte melden Sie ein Problem mit Ihrem konkreten Anwendungsfall unter crbug.com. Chrome würde sich freuen, von Ihnen zu hören.

Hero-Image von Stephen Philips auf Unsplash