Vorschlag zur Einschränkung von Websites, die auf das lokale Netzwerk der Nutzer zugreifen

 (github.com/explainers-by-googlers)
1 Punkte von GN⁺ 2025-06-05 | 1 Kommentare | Auf WhatsApp teilen
  • Das Chrome-Sicherheitsteam schlägt ein neues Berechtigungsmodell für den „Zugriff auf das lokale Netzwerk“ vor, um das Problem des Zugriffs von Websites auf lokale Netzwerke zu lösen
  • Derzeit können öffentliche Websites unter Umständen ohne Erlaubnis auf lokale Netzwerkgeräte der Nutzer wie Drucker zugreifen oder Angriffe versuchen; dieser Vorschlag zielt darauf ab, Anfragen an das lokale Netzwerk ohne Zustimmung der Nutzer zu blockieren
  • Anders als beim bestehenden Private Network Access (PNA) funktioniert dies auf Basis der Zustimmung zu Nutzerberechtigungen statt über Preflight, stärkt damit die Kontrolle der Nutzer und kann durch Updates der Websites ohne Änderungen an den Geräten umgesetzt werden
  • Konkret zeigt der Browser, wenn öffentliche Websites Fetch-Anfragen an lokale IPs, .local-Domains usw. stellen, eine ausdrückliche Zustimmungsabfrage an, falls keine Berechtigung vorliegt
  • Diese Richtlinie stärkt Sicherheit und Privatsphäre und stellt zugleich sicher, dass legitime Anwendungsfälle wie die Einrichtung von IoT-Geräten bei Zustimmung der Nutzer normal funktionieren

Überblick und Ziel des Vorschlags

  • Das Chrome Secure Web and Network Team hat einen ersten Entwurf für ein Berechtigungsmodell zum Zugriff öffentlicher Websites auf lokale Netzwerke ohne Zustimmung veröffentlicht
  • Bislang konnten besuchte Websites CSRF oder andere Angriffe auf lokale Netzwerkgeräte der Nutzer wie Drucker oder Router versuchen
  • Künftig soll der Browser Anfragen blockieren, die Grenzen zwischen Adressräumen wie öffentlicher IP → lokaler IP überschreiten, und sie nur nach ausdrücklicher Zustimmung der Nutzer pro Website erlauben

Hintergrund und Unterschiede

  • Das bisherige Private Network Access (PNA) basierte auf Preflight (Vorab-Anfrage/-Antwort), wodurch auch Änderungen an Geräten nötig waren und die Einführung schwierig war
  • Der jetzige Vorschlag lässt sich allein über Zustimmung zu Nutzerberechtigungen umsetzen; da nur Websites leicht angepasst werden müssen, ist die praktische Einführung und Verbreitung einfacher

Ziele und Nicht-Ziele

  • Ziele
    • Missbrauch anfälliger Geräte und Server durch Drive-by-Angriffe über das Web verhindern
    • Kommunikation zwischen öffentlichen Websites und lokalen Geräten nur dann erlauben, wenn Nutzer dies wollen und erlauben
  • Nicht-Ziele
    • Sinnvolle bestehende Nutzungsszenarien wie die Konfiguration oder Steuerung lokaler Geräte pauschal zu blockieren
    • HTTPS-Probleme in lokalen Netzwerken oder komplexe Zertifikatsausstellung sind nicht Teil dieses Vorschlags

Anwendungsfälle

  • Fall 1: Wenn ein normaler Nutzer es nicht möchte und example.com Anfragen an 192.168.0.1 usw. sendet, fragt der Browser nach einer Erlaubnis; bei Ablehnung wird die Anfrage blockiert
  • Fall 2: Offizielle webbasierte Konfigurationsseiten von Geräteherstellern für IoT-Geräte, Router usw. dürfen nach erstmaliger Zustimmung der Nutzer kommunizieren

Konkretes Design

  • Trennung der Adressräume:
    • Die IP-Netzwerkschicht wird in drei Ebenen eingeteilt: loopback (nur das eigene System), local (innerhalb des lokalen Netzwerks) und public (für alle erreichbar)
    • Dazu gehören verschiedene Kriterien zur Erkennung lokaler Netzwerke wie .local-Domains, private IPs nach RFC1918/4193 und Link-Local-Namen nach RFC6762
  • Anfragen an lokale Netzwerke: Für public→local, public→loopback, local→loopback usw. wird beim Zugriff aus höher öffentlichen Adressräumen in interne Netzwerke eine Berechtigung verlangt
    • Als Anfrage an das lokale Netzwerk gelten Zugriffe vom öffentlichen Netzwerk auf lokale oder Loopback-Netzwerke sowie Zugriffe vom lokalen Netzwerk auf Loopback
    • Ausnahmen: local→local, loopback→beliebige Adressen usw. unterliegen nicht dieser Einschränkung
  • Berechtigungs-Prompt:
    • Wenn eine Website Anfragen an das lokale Netzwerk stellt und keine Berechtigung hat, zeigt der Browser einen Prompt an, der die Nutzer nach Erlaubnis fragt
    • Bei Ablehnung wird die Anfrage blockiert, bei Zustimmung ausgeführt
  • Integration in die Fetch API: Bei Fetch-Aufrufen kann mit Optionen wie targetAddressSpace: "local" eine explizite Kennzeichnung erfolgen
    • Die Fetch-Spezifikation definiert nur die reine Verbindung ohne DNS-Auflösung; daher wird bei neuen Verbindungen entschieden, ob es sich um eine Anfrage an das lokale Netzwerk handelt
    • Anfragen an lokale Netzwerke sind nur in sicheren Kontexten erlaubt; ohne Berechtigung erscheint ein Prompt, mit Berechtigung wird die Anfrage zugelassen
    • Durch den zusätzlichen Parameter targetAddressSpace in den Optionen von fetch() können Entwickler den Ziel-Adressraum explizit angeben
    • Wenn die tatsächlich aufgebaute Verbindung nicht zum in den Optionen angegebenen Adressraum passt, schlägt die Anfrage fehl, um Umgehungen von Mixed Content zu verhindern
  • Dieselbe Richtlinie gilt auch für HTML, WebRTC, ServiceWorker usw.
    • HTML-Dokumente/Worker erhalten einen Adressraumwert, um den auf der Herkunft basierenden Raum zu verfolgen
    • Wenn der ICE Agent in WebRTC Kandidaten hinzufügt, wird für lokale/Loopback-Adressen ein Berechtigungs-Prompt verwendet
    • Berechtigungen sind mit der Permissions API verknüpft, sodass Websites den aktuellen Berechtigungsstatus abfragen können
    • Standardmäßig ist der Zugriff auf das lokale Netzwerk nur im übergeordneten Dokument erlaubt; bei Bedarf kann die Berechtigung per Delegation über Permissions Policy an untergeordnete Frames weitergegeben werden
  • Probleme mit Mixed Content (HTTP/HTTPS):
    • Es werden Szenarien behandelt wie Zugriffsversuche aus unsicheren Kontexten auf lokale Netzwerke, das Laden HTTP-basierter Unterressourcen und die Anwendung von Mixed-Content-Blockierung
    • Bei privaten IP-Literalen, .local-Domains und Anfragen mit angegebenem targetAddressSpace werden Schritte zur Mixed-Content-Aufwertung und -Blockierung übersprungen; bei nachfolgenden Verbindungen wird jedoch blockiert, wenn die Origin keine Berechtigung hat
  • Beispiele für das Verhalten
    • Bei unerwartetem Zugriff auf das lokale Netzwerk können Nutzer die Berechtigung verweigern und damit unautorisierte Anfragen blockieren
    • Bei einer vom Hersteller betriebenen Gerätesteuerungsseite kann der Aufruf mit einer passenden Eigenschaft (z. B. targetAddressSpace="local") bei Zustimmung der Nutzer weiterhin wie bisher funktionieren

Alternativen und Diskussion

  • PNA-Ansatz:
    • Das bisherige PNA erforderte CORS-Preflight, war in der Praxis aber nur schwer anzuwenden und auszurollen
    • Für einige Bereiche wurde eine Kombination aus Berechtigungs-Prompt und Ausnahmen bei Mixed Content vorgeschlagen
    • Wegen DNS-Problemen und fehlender Unterstützung in Gerätespezifikationen bestehen praktische Grenzen
  • Alle Anfragen an lokale Netzwerke blockieren: einfach, aber wegen zerstörter Anwendungsfälle und höherer Umgehungskosten nicht realistisch
  • Status quo beibehalten: Da Betriebssysteme beginnen, lokale Netzwerkberechtigungen pro App zu verwalten, wird die Notwendigkeit einer Verwaltung auf Browser-Ebene betont
  • Alternativen bei Mixed Content:
    • Diskutiert werden Sicherheitsbewertung und Implementierungsaufwand von Methoden wie „nur sichere Unterressourcen im lokalen Netzwerk erlauben“
    • Auch die Deklaration des Adressraums per Response-Header/Meta-Tag oder zusätzliche HTML-Elementattribute werden als Alternativen diskutiert

Weitere Punkte

  • Es wird diskutiert, HTML-Subresources (iframe, img usw.) ebenfalls mit Adressraum-Attributen zu versehen
  • Forschungsergebnisse zu Problemen wie übermäßiger Weitergabe von Berechtigungen (Transitivität) bei Gewährung von Rechten werden berücksichtigt
  • Beim Wechsel des Main Frames könnte der Zugriff auf lokale Netzwerke eingeschränkt oder eine Warn-Zwischenseite angezeigt werden
  • Auch ein Ansatz, alle Cross-Origin-Anfragen an lokale/Loopback-Adressen breit als Anfragen an lokale Netzwerke zu behandeln, wird erwogen
  • Untersucht werden feingranulare Berechtigungen pro Netzwerk sowie die Frage, ob bei Wechsel in ein anderes Netzwerk (an einen anderen Ort) erneut zugestimmt werden muss

Sicherheits- und Datenschutzaspekte

  • Websites mit Berechtigung könnten erweiterte Möglichkeiten erhalten, Geräte im gesamten Netzwerk der Nutzer zu erkennen und anzusprechen
  • Nutzer müssen beim Akzeptieren des Prompts die Tragweite klar verstehen; im Vergleich zum Preflight-basierten Ansatz ist direkte Kontrolle möglich
  • Ohne vorherige Berechtigung sind keinerlei Anfragen an lokale Netzwerke möglich, was den Schutz der Privatsphäre stärkt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-05
Hacker-News-Kommentare

  • Beim ersten Lesen mochte ich diese Funktion sofort; allein die Vorstellung, dass Websites beliebige HTTP-Anfragen an lokale IPs (oder überhaupt irgendwelche IPs) schicken können, ist ein absurd großes Risiko. Selbst wenn dadurch einige Enterprise-Apps oder Integrationen kaputtgehen, wäre mir das egal. Unternehmen können die Funktion per Management-Tools wieder aktivieren, und normale Nutzer können sie selbst einschalten. Ein Popup wie „Diese Website versucht, lokale Geräte zu steuern – Zulassen/Ablehnen“ wäre völlig ausreichend.

    • Hier wird aber eine missverständliche Sichtweise aufgezeigt: Geräte im lokalen Netzwerk sind dank CORS vor beliebigen Websites geschützt. Das ist nicht perfekt, aber ziemlich wirksam. Das Problem ist, dass CORS ausschließlich auf der Zustimmung des Zielservers beruht. Der Server muss per bestimmtem Header erlauben, dass die betreffende Website zugreifen darf. Dieser Vorschlag will das verschärfen, sodass selbst dann, wenn Server und Website beide kommunizieren wollen, eine ausdrückliche Zustimmung des Nutzers nötig ist. Früher hielt man die Einigung zwischen Server und Website für ausreichend, aber Fälle wie bei Facebook, wo Websites heimlich auf Apps auf dem Smartphone zugreifen, haben dieses Prinzip gebrochen. Anders gesagt: Inzwischen können Website und lokaler Netzwerkserver gemeinsam gegen die Interessen des Nutzers arbeiten.

    • Zur Aussage „Normale Nutzer können im Popup einfach Zulassen/Ablehnen auswählen“: MacOS fragt solche Berechtigungen derzeit pro App ab, aber die meisten Nutzer klicken ohne groß nachzudenken auf „Zulassen“. Es ist fraglich, ob deutlich mehr Vorsicht entstünde, wenn man das pro Website macht.

    • Ich verstehe nicht, warum Websites überhaupt Zugriff auf das lokale Netzwerk brauchen sollten. Das schafft nur ein völlig neues Sicherheitsbedrohungsmodell. Ich frage mich, ob es überhaupt Fälle gibt, in denen es dafür keine bessere Lösung gibt.

  • Ich wünschte, Apple, Microsoft und Google würden bei USB und Bluetooth ähnlich vorgehen. In letzter Zeit verlangt fast jede App, die ich installiere, Bluetooth-Zugriff, und das ist extrem lästig. Ich hätte gern, dass Apps die Bluetooth-Geräte-IDs, auf die sie zugreifen können, im Manifest angeben und das OS den Zugriff dann nur auf diese Geräte beschränkt. Zum Beispiel sollte die Bose-App nur Bose-Geräte sehen können. Ich habe schon erlebt, dass ich eine App abgelehnt habe, weil ich nicht nachvollziehen konnte, welche Berechtigung sie überhaupt anfordert. Wie bei Kamera oder GPS wären registrierte Geräte-IDs plus Nutzer-Prompt sinnvoll. Bei Bose könnte man etwa den Präfix bose.xxx registrieren und im Manifest nur Zugriff auf bose.* anfordern, und das OS würde genau diese Regel erlauben. Ein ähnliches ID-Schema ließe sich auch auf USB und Geräte im lokalen Netzwerk anwenden. Ich würde mir wünschen, dass das OS Apps daran hindert, Netzwerk, USB und Bluetooth frei zu durchsuchen.

    • Ich hoffe, dass irgendwann zumindest Apple Apps eine Option für „gefälscht erlaubte“ Berechtigungen gibt. Wenn eine App zum Beispiel unbedingt meine Kontaktliste braucht, könnte man ihr eine zufällige Liste zeigen, die nicht von einer echten zu unterscheiden ist. Etwas Ähnliches auch für GPS. Ich habe auch gehört, dass man bei WhatsApp ohne Freigabe der Kontakte keine Kontaktnamen vergeben kann.

    • Ich bevorzuge ein fein granulareres Modell wie bei GitHub-Integrationen von Drittanbietern: „ABC möchte auf meine Repositories zugreifen. Welche Repositories möchtest du freigeben?“

  • Meiner Ansicht nach hat Internet Explorer solche Probleme früher mit seinem Zonen-System gelöst. Details dazu stehen in der MS-Dokumentation.

    • Ironischerweise nutzte Chrome unter Windows teilweise ebenfalls das Zonen-Sicherheitsmodell von IE, aber dazu gab es kaum offizielle Dokumentation.

    • Dass es keine moderne Alternative dazu gibt, ist ziemlich absurd. Zugriff auf das lokale Netzwerk sollte wie Kamera oder Mikrofon nur als spezielle Berechtigung erlaubt sein.

  • Es ist kaum zu glauben, dass Webbrowser dieses Verhalten standardmäßig erlaubt haben. Wenn eine öffentliche Website heimlich auf mein gesamtes Dateisystem zugreifen könnte, wäre das ein furchtbares Sicherheitsloch. Bei Diensten im lokalen Netzwerk kann man dagegen einfach per XHR darauf zugreifen, und die Sicherheit wird nur den Server-Einstellungen überlassen. Als Entwickler kann man auf dem eigenen Entwicklungsrechner zum Testen interne Web-Apps laufen lassen, oft mit sehr lockeren oder ganz ohne Sicherheitseinstellungen, und facebook.com oder google.com könnten direkt darauf zugreifen. Auch zu Hause verlassen sich viele auf die Router-Firewall und betreiben Dienste ohne Authentifizierung. Ob wirklich alle CORS korrekt konfiguriert haben, wage ich stark zu bezweifeln.

    • Ich bezweifle ernsthaft, dass alle CORS richtig eingerichtet haben. In der Praxis dürfte der Anteil eher nahe 0 % liegen.

  • Es besteht die Hoffnung, dass dieser Vorschlag dabei helfen könnte, Metas Praxis zu unterbinden, über das eigene SDK per localhost-basiertem Trick Kennungen zwischen nativen Apps und Websites auszutauschen, besonders unter Android. Mehr dazu hier.

  • Dass Websites überhaupt eine Berechtigung für den Zugriff auf das lokale Netzwerk erhalten, ist viel zu grob und unnötig weitreichend. Die meisten Sites, die tatsächlich eine Berechtigung brauchen, müssen nur auf genau einen lokalen Server zugreifen. Alles Lokale pauschal zu erlauben, verstößt gegen das Prinzip der minimalen Rechte. Die meisten Nutzer wissen nicht einmal, was auf localhost oder im Netzwerk läuft, und können die Risiken daher kaum einschätzen.

    • Die meisten Menschen wissen nicht, dass überhaupt etwas auf localhost oder im Netzwerk läuft. Wenn der Browser also etwa eine Meldung für http://localhost:3146 oder http://localhost:8089 anzeigt, verstehen sie vermutlich nicht einmal, was das bedeutet. Eine intuitivere Nachricht wie „Diese Website versucht, auf Ressourcen im lokalen Netzwerk zuzugreifen“ wäre aus meiner Sicht besser als technische Fachbegriffe.

    • Wenn man das richtig umsetzen will, braucht man im Grunde Zugriff auf Browser-Ebene in Richtung Firewall. Eine API, mit der sich etwa CIDR, Ports und Ähnliches fein steuern lassen, wäre wünschenswert. Browser-Erweiterungen könnten dann ebenfalls so eine Firewall-API nutzen, oder die Standard-UI könnte klar zwischen einzelnen Maschinen wie dem Router, dem LAN, dem VPN oder dem privaten Netzwerk unter Windows unterscheiden und jeweils gezielt Zugriffsanfragen stellen.

  • Seit dem Verschwinden von NPAPI-Plugins bleibt vielen öffentlichen Websites für die Integration mit lokaler Software praktisch nur noch, auf localhost einen HTTP-Server laufen zu lassen. Wenn man selbst diese Nutzbarkeit noch komplizierter macht, wird das extrem unbequem. Browser-Hersteller hätten nach NPAPI Ersatztechnologien bereitstellen sollen, aber dafür ist es jetzt wohl zu spät.

    • Die meiste Software registriert stattdessen auf OS-Ebene Protokoll-Handler, sodass eine Website zum Beispiel einen Link wie zoommtg:// übergibt und der Browser ihn an Zoom oder eine andere App weiterreicht. Lokale Nutzung wie bei Jupyter Notebook ohne Cross-Origin-Anfragen wäre davon nicht betroffen. Auch ein Redirect auf eine localhost-URL nach einem OAuth2-Login dürfte unproblematisch sein, weil es nur eine einfache Weiterleitung ist.

    • Wenn diese Methode der Kommunikation mit lokalen Apps über einen HTTP-Server ganz verschwinden würde, wäre das eher noch besser. Sie war eine ständige Quelle von Sicherheitslücken.

    • Technologien wie Mozilla Native messaging existieren bereits. Man muss zwar eine Erweiterung installieren, aber verglichen mit NPAPI ist das ein fairerer Ansatz.

    • Wenn lokale Software stattdessen per „Pull“-Modell arbeitet, also die App regelmäßig selbst externe Anfragen stellt, braucht man gar keinen Server mehr zu starten. Nebenbei würde das auch verhindern, dass Websites wahllos das lokale Netzwerk anderer Leute scannen.

  • In JavaScript verhindert CORS bei fetch- oder POST-Anfragen ohne CORS-Optionen nur das Lesen der Antwort; die Anfrage selbst wird vom Browser trotzdem gesendet. Wenn eine lokale App den Server dazu bringt, per Proxy CORS-Header hinzuzufügen, kann jede Site per JS fetch/XMLHttpRequest darauf zugreifen. Erweiterungen können Header verändern und damit CORS umgehen. Solche Umgehungen per Header-Manipulation sind viel zu einfach, während CSP (Content Security Policy) in der Praxis sehr schwer oder fast gar nicht zu umgehen ist. Die Facebook-App betreibt schon jetzt ihren eigenen CORS-Proxy-Server und nutzt genau so eine Struktur. Es gibt außerdem WebSocket, sodass selbst ein Chrome-Flag zum Blockieren von localhost-Zugriffen nutzlos wäre. localhost vollständig zu sperren würde eher schaden, weil viele Nutzer lokale Server für self-hosted Lesezeichen, Notizen, Passwort-Manager und Ähnliches verwenden. Solche Fälle zu blockieren wäre unangemessen.

  • Es gibt Bedenken wegen IPv6. Ich frage mich, ob man überhaupt erkennen kann, ob eine IPv6-Adresse teilweise lokal ist. Wenn nicht, dürfte dieser Vorschlag in IPv6-only-Netzen problematisch sein. Ich hatte so ein Problem schon einmal in einer IoT-App: Weil sich schwer erkennen ließ, ob eine IPv6-Adresse lokal ist, habe ich schließlich alle IPv6-Fälle auf lokales IPv4 umgeleitet. Selbst IPv6-Link-Local-Adressen waren praktisch bedeutungslos, weil normale Apps sie kaum sinnvoll nutzen können. Ob man .local-Domains als lokale Server anerkennt, ist ebenfalls schwierig, da verschiedene Betriebssysteme sie unterschiedlich interpretieren. Beispiel: Auf Raspberry Pi OS wird some_address per mDNS aufgelöst, aber someaddress.local nicht; unter Ubuntu 24.04 funktioniert someaddress.local, aber someaddress nicht; someaddress.local. funktioniert ebenfalls nicht. Und zusätzlich ist frustrierend, dass man für lokale Netzwerkadressen keine privaten Zertifikate verwenden kann. Das Problem „HTTPS-Einschränkung für lokale Adressen“ muss unbedingt ebenfalls gelöst werden.

    • Auch bei IPv6 gibt es weiterhin das Konzept „routbar“, sodass man site-local logisch auf Ebene der Routing-Tabelle definieren kann. Bei altem IPv4 lag das Site-Konzept im zweiten Oktett und VLANs im dritten, bei IPv6 gibt es noch mehr Optionen. Jedes IPv6-Gerät hat eine Link-Local-Adresse, also für das lokale VLAN. .local ist ein Begriff aus Apple-, DNS- und allgemein Namens-zu-Adress-Mapping-Kontexten und hat mit IP-Adressen nicht direkt zu tun. HTTPS-Zertifikate im lokalen Netzwerk sind über Lets Encrypt mit DNS-01-Validierung, CNAMEs und Ähnlichem durchaus möglich. Es ist ziemlich umständlich, aber es gibt kostenlose Wege, und Tools wie acme.sh sind empfehlenswert. Die Konzepte rund um IPv4, IPv6, DNS, mDNS und Bonjour müssten klarer voneinander getrennt werden. Wenn ich daran denke, dass selbst Paketmitschnitte früher kostenpflichtig waren, ist die Lage heute deutlich besser.

    • Es wird präzisiert, dass man am Endpunkt nicht feststellen kann, ob eine IPv6-Adresse „lokal“ ist. Das liegt gerade am Grundprinzip von IPv6, nämlich globalem Routing. Auch Google habe im Artikel offenbar zunächst über die Bedeutung von „local“ diskutiert und dann unterwegs auf eine Definition von „private“ gewechselt, was die Verwirrung nur verstärkt habe. Über HTTP-Erweiterungen eine nicht standardisierte, CIDR-basierte Sicherheitsgrenze einzuführen, sei ein absurder Ansatz. Apps sollten ihr Sicherheitsmodell so entwerfen, als wären sie öffentliche Dienste. .local ist zwar Teil der mDNS-Spezifikation, wird in der Praxis aber fast immer ignoriert.

  • Ich hoffe wirklich, dass so etwas bald umgesetzt wird, besonders eine Möglichkeit, von HTTPS-Domains auf lokale HTTP-Sites zuzugreifen. Gerade für Smart Home sowie Medien- und Entertainment-Anwendungen gibt es viele spannende Einsatzfälle.