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

Risiken im Zusammenhang mit der unbeabsichtigten Offenlegung von Geräten und Servern im internen Netzwerk eines Kunden im Internet minimieren.

Eiji Kitamura

Schadsoftware-Websites, die Anfragen an Geräte und Server in einem privaten Netzwerk senden, stellen schon lange eine Bedrohung dar. 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 zu verlangen, dass interne Geräte Anfragen aus dem öffentlichen Internet zulassen.

Um die Auswirkungen dieser Änderung auf das Web-Ökosystem besser nachvollziehen zu können, bittet das Chrome-Team Entwickler, die Server für private Netzwerke erstellen, um Feedback.

Was stimmt mit dem Status quo nicht?

Viele Webserver werden in einem privaten Netzwerk ausgeführt, z. B. WLAN-Router, Drucker, Intranet-Websites, Unternehmensdienste und IoT-Geräte (Internet of Things). 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. Auf schädlichen Websites kann beispielsweise eine URL eingebettet sein, die beim 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 hat 2014 stattgefunden. Mehr als 300.000 anfällige WLAN-Router wurden manipuliert,indem ihre DNS-Einstellungen geändert wurden. So konnten Angreifer Nutzer auf schädliche Server umleiten.

CORS-RFC1918

Um die Gefahr ähnlicher Angriffe zu verringern, führt die Web-Community CORS-RFC1918 ein, eine spezielle Version von Cross-Origin Resource Sharing (CORS) für private Netzwerke, die in RFC1918 definiert sind.

Browser, die CORS implementieren, prüfen bei Zielressourcen, ob sie von einer anderen Quelle geladen werden dürfen. Dies geschieht entweder mit zusätzlichen Headern, die den Zugriff inline beschreiben, oder mit einem Mechanismus namens Preflight-Anfragen, je nach Komplexität. Weitere Informationen zu Cross-Origin Resource Sharing

Mit CORS-RFC1918 blockiert der Browser standardmäßig das Laden von Ressourcen über das private Netzwerk, mit Ausnahme von Ressourcen, die vom Server explizit über CORS und HTTPS zugelassen werden. Die Website, die Anfragen an diese Ressourcen sendet, muss CORS-Header senden. Der Server muss explizit angeben, dass er die Cross-Origin-Anfrage akzeptiert, indem er mit entsprechenden CORS-Headern antwortet. Die genauen CORS-Header sind noch in der Entwicklung.

Entwickler solcher Geräte oder Server werden aufgefordert, zwei Dinge zu tun:

Achten Sie darauf, dass die Website, die Anfragen an ein privates Netzwerk sendet, über HTTPS bereitgestellt wird.
Richte die Serverunterstützung für CORS-RFC1918 ein und antworte mit den erwarteten HTTP-Headern.

Welche Arten von Anfragen sind betroffen?

Betroffene Anfragen:

Anfragen aus dem öffentlichen Netzwerk an ein privates Netzwerk
Anfragen von einem privaten Netzwerk an ein lokales Netzwerk
Anfragen aus dem öffentlichen Netzwerk an ein lokales Netzwerk

Privates Netzwerk Ein Ziel, das in IPv4 in den privaten Adressbereich aufgelöst wird, der in Abschnitt 3 von RFC1918 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.

Lokales Netzwerk Ein Ziel, das in den in Abschnitt 3.2.1.3 von RFC1122 für IPv4 definierten „Loopback“-Bereich (127.0.0.0/8), den in RFC3927 für IPv4 definierten „Link-Local“-Bereich (169.254.0.0/16), das in Abschnitt 3 von RFC4193 für IPv6 definierte Präfix „Unique Local Address“ (fc00::/7) oder das in Abschnitt 2.5.6 von RFC4291 für IPv6 definierte Präfix „Link-Local“ (fe80::/10) aufgelöst wird.

Öffentliches Netzwerk Alle anderen

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

Pläne von Chrome zur Aktivierung von CORS-RFC1918

CORS-RFC1918 wird in Chrome in zwei Schritten eingeführt:

Schritt 1: Anfragen an Ressourcen in privaten Netzwerken sind nur von HTTPS-Webseiten aus zulässig

In Chrome 87 wurde ein Flag hinzugefügt, das vorschreibt, dass öffentliche Websites, die Anfragen an private Netzwerkressourcen senden, HTTPS verwenden müssen. Sie können die Funktion unter about://flags#block-insecure-private-network-requests aktivieren. Wenn dieses Flag aktiviert ist, werden alle Anfragen an eine Ressource in einem privaten Netzwerk 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 Konsole als CORS-Richtlinienfehler gemeldet. — CORS-RFC1918-Fehler werden in der **Konsole** 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 Netzwerkbereich gemeldet. — CORS-RFC1918-Fehler werden auch als CORS-Fehler im Bereich **Netzwerk** gemeldet.

In Chrome 87 werden CORS-RFC1918-Fehler 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 eine öffentliche Website in Zukunft 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 der Anfrage und ermöglichen so eine detaillierte 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.

Wir freuen uns über Ihr Feedback

Wenn Sie eine Website in einem privaten Netzwerk hosten, die Anfragen aus öffentlichen Netzwerken erwartet, freut sich das Chrome-Team über Ihr Feedback und Ihre Anwendungsfälle. Sie haben zwei Möglichkeiten, uns zu helfen:

Rufen Sie about://flags#block-insecure-private-network-requests auf, aktivieren Sie das Flag und prüfen Sie, ob Ihre Website wie erwartet Anfragen an die Ressource des privaten Netzwerks sendet.
Wenn Sie Probleme haben oder Feedback geben möchten, melden Sie ein Problem unter crbug.com und legen Sie die Komponente auf Blink>SecurityFeature>CORS>RFC1918 fest.

Beispielfeedback

Unser WLAN-Router stellt eine Administratorwebsite für dasselbe private Netzwerk, aber über HTTP bereit. Wenn HTTPS für Websites erforderlich ist, auf denen die Administratorwebsite eingebettet ist, handelt es sich um gemischte Inhalte. Sollten wir HTTPS auf der Admin-Website in einem geschlossenen Netzwerk aktivieren?

Genau das ist das Feedback, das Chrome benötigt. Bitte melden Sie ein Problem mit Ihrem konkreten Anwendungsfall auf crbug.com. Das Chrome-Team freut sich über Ihr Feedback.