Proposition visant à limiter les sites pouvant accéder au réseau local de l’utilisateur

 (github.com/explainers-by-googlers)
1 points par GN⁺ 2025-06-05 | 1 commentaires | Partager sur WhatsApp
  • L’équipe sécurité de Chrome propose un nouveau système d’« autorisation d’accès au réseau local » pour résoudre le problème de l’accès des sites web au réseau local
  • Aujourd’hui, des sites web publics peuvent potentiellement accéder sans autorisation ou attaquer des appareils du réseau local de l’utilisateur, comme son imprimante ; cette proposition vise donc à bloquer les requêtes vers le réseau local sans autorisation de l’utilisateur
  • Contrairement à l’actuel Private Network Access (PNA), le mécanisme fonctionnerait sur la base du consentement de l’utilisateur plutôt que d’un preflight, renforçant ainsi le contrôle de l’utilisateur, avec un déploiement possible via de simples mises à jour des sites, sans modifier les appareils
  • Concrètement, lorsqu’un site public envoie une requête fetch vers une IP locale, un domaine en .local, etc., le navigateur affiche une demande de consentement explicite à l’utilisateur si l’autorisation n’a pas été accordée
  • Cette politique doit à la fois renforcer la sécurité et la protection de la vie privée et garantir que des usages légitimes, comme la configuration d’appareils IoT, continuent de fonctionner avec l’accord de l’utilisateur

Aperçu et objectif de la proposition

  • L’équipe Chrome Secure Web and Network a publié une première ébauche d’un système d’autorisation « Local Network Access » pour résoudre le problème de l’accès non autorisé des sites publics au réseau local
  • Jusqu’à présent, un site visité pouvait tenter des CSRF et d’autres attaques contre des appareils du réseau local de l’utilisateur, comme son imprimante ou son routeur
  • La proposition consiste à faire bloquer par le navigateur les requêtes franchissant la frontière entre espaces d’adressage, par exemple IP publique → IP locale, et à ne les autoriser qu’après accord explicite de l’utilisateur pour chaque site

Contexte et différences

  • Le mécanisme existant Private Network Access (PNA) repose sur un preflight (requête/réponse préalable), ce qui imposait aussi des changements côté appareils et rendait l’adoption difficile
  • Cette nouvelle proposition peut être mise en œuvre avec le seul consentement utilisateur, et comme elle ne demande que de légères modifications côté sites, son adoption et sa diffusion sont plus réalistes

Objectifs et non-objectifs

  • Objectifs
    • Bloquer l’exploitation d’appareils et de serveurs vulnérables via des attaques web de type drive-by
    • N’autoriser la communication entre un site public et des appareils locaux que lorsque l’utilisateur la souhaite et l’a explicitement permise
  • Non-objectifs
    • Éviter de bloquer globalement les usages légitimes existants, comme la configuration ou le contrôle d’appareils locaux
    • Les problèmes de HTTPS sur réseau local et les mécanismes complexes d’émission de certificats ne font pas partie du périmètre de cette proposition

Cas d’usage

  • Cas 1 : si l’utilisateur ne le souhaite pas, lorsqu’example.com envoie une requête vers 192.168.0.1, le navigateur demande une autorisation et bloque la requête en cas de refus
  • Cas 2 : les pages officielles de configuration web fournies par les fabricants d’appareils comme des objets IoT ou des routeurs peuvent communiquer après avoir obtenu l’accord de l’utilisateur lors du premier accès

Conception détaillée

  • Séparation des espaces d’adressage :
    • La couche réseau IP est répartie en trois niveaux : loopback (réservé à la machine elle-même), local (à l’intérieur du réseau local) et public (accessible à tous)
    • Cela inclut différents critères d’identification du réseau local, comme les domaines en .local, les IP privées RFC1918/4193 et les noms link-local définis par la RFC6762
  • Requêtes vers le réseau local : les accès public→local, public→loopback ou local→loopback exigent une autorisation
    • Toute requête allant d’un réseau public vers un réseau local ou loopback, ainsi que d’un réseau local vers loopback, est considérée comme une requête vers le réseau local
    • Exceptions : local→local, loopback→n’importe quelle adresse, etc., ne sont pas concernés par ces restrictions
  • Invite d’autorisation :
    • Lorsqu’un site envoie une requête vers le réseau local sans disposer de l’autorisation nécessaire, le navigateur affiche une invite demandant à l’utilisateur s’il souhaite l’autoriser
    • En cas de refus, la requête est bloquée ; en cas d’acceptation, elle est exécutée
  • Intégration à la fetch API : lors d’un appel fetch, il devient possible d’indiquer explicitement une option comme targetAddressSpace: "local"
    • Comme la spécification Fetch ne définit que la connexion elle-même sans résolution DNS, la détection d’une requête vers le réseau local se fait au moment de l’établissement d’une nouvelle connexion
    • Les requêtes vers le réseau local ne sont autorisées que dans un contexte sécurisé ; sans autorisation, une invite est affichée, et avec autorisation, la requête est permise
    • L’ajout du paramètre targetAddressSpace dans les options de fetch() permet aux développeurs de désigner explicitement l’espace d’adressage de destination
    • Si l’adresse réellement connectée ne correspond pas à l’espace indiqué dans l’option, la requête échoue afin d’éviter les contournements du mixed content
  • Même politique pour HTML, WebRTC, ServiceWorker, etc.
    • Une valeur d’espace d’adressage est ajoutée aux documents HTML et workers pour suivre l’espace lié à l’origine
    • Lors de l’ajout de candidats dans l’ICE Agent de WebRTC, les adresses locales et loopback passent également par une invite d’autorisation
    • Les autorisations sont liées à la Permissions API, ce qui permet au site d’interroger son état actuel
    • Par défaut, seul le document de niveau supérieur peut accéder au réseau local ; si nécessaire, l’autorisation peut être déléguée à des sous-frames via une politique de délégation de Permissions Policy
  • Problème de mixed content (HTTP/HTTPS) :
    • La proposition couvre les scénarios d’accès au réseau local depuis un contexte non sécurisé, le chargement de sous-ressources HTTP et l’application du blocage du mixed content
    • Pour les IP privées littérales, les domaines en .local et les requêtes spécifiant targetAddressSpace, les étapes habituelles de mise à niveau ou de blocage du mixed content sont ignorées, puis la requête est bloquée si l’origine n’a pas l’autorisation au moment de la connexion
  • Exemples de fonctionnement
    • En cas d’accès inattendu au réseau local, l’utilisateur peut refuser l’autorisation et bloquer les requêtes non souhaitées
    • Dans le cas d’une page de contrôle d’appareil exploitée par un fabricant, un appel effectué avec la propriété appropriée, par exemple targetAddressSpace="local", peut continuer à fonctionner comme auparavant si l’utilisateur donne son accord

Alternatives et discussions

  • Approche PNA :
    • Le PNA existant exigeait un preflight CORS, mais son application et son déploiement en conditions réelles se sont révélés difficiles
    • Dans certains cas, il a aussi été proposé d’utiliser une invite d’autorisation avec des exceptions au mixed content
    • Des limites pratiques subsistent, liées notamment au DNS ou à l’absence de prise en charge de certaines spécifications sur les appareils
  • Bloquer toutes les requêtes vers le réseau local : solution simple, mais peu réaliste en raison de la casse des usages existants et du coût accru des contournements
  • Maintien du statu quo : comme les systèmes d’exploitation commencent à gérer les autorisations d’accès au réseau local application par application, la nécessité d’un contrôle au niveau du navigateur est davantage mise en avant
  • Alternatives autour du mixed content :
    • Des discussions portent sur des approches comme « n’autoriser que des sous-ressources sécurisées du réseau local », avec les questions de robustesse de l’évaluation de sécurité et de charge d’implémentation
    • D’autres pistes évoquées incluent la déclaration de l’espace d’adressage via un en-tête de réponse ou une balise meta, ou encore l’ajout d’attributs aux éléments HTML

Points supplémentaires

  • La possibilité d’ajouter une propriété d’espace d’adressage aux subresources HTML (iframe, img, etc.) est aussi discutée
  • Les résultats de recherche sur des problèmes comme la transitivité d’un partage d’autorisations trop large sont également pris en compte
  • Des restrictions d’accès au réseau local ou l’affichage d’un interstitiel d’avertissement sont envisagés lors de la navigation du frame principal
  • Une autre option étudiée consiste à considérer de manière large toutes les requêtes cross-origin vers des adresses locales ou loopback comme des requêtes vers le réseau local
  • Des travaux portent aussi sur des autorisations plus granulaires selon le réseau, ainsi que sur la nécessité d’un nouveau consentement lors d’un changement de réseau ou de lieu de connexion

Considérations de sécurité et de vie privée

  • Un site ayant obtenu l’autorisation pourrait potentiellement élargir sa capacité d’exploration et d’accès à l’ensemble des appareils du réseau de l’utilisateur
  • Lorsqu’il accepte l’invite, l’utilisateur doit comprendre clairement son intention ; par rapport à une approche fondée sur le preflight, ce système offre un contrôle plus direct
  • Sans autorisation préalable, aucune requête vers le réseau local n’est possible, ce qui renforce la protection de la vie privée

À lire aussi

1 commentaires

 
GN⁺ 2025-06-05
Commentaire Hacker News

  • À première vue, j’ai trouvé cette fonctionnalité séduisante : l’idée même qu’un site web puisse envoyer des requêtes HTTP vers des IP locales — ou n’importe quelles IP — de manière arbitraire me paraît être un risque totalement absurde. Même si cela casse certaines applications d’entreprise ou intégrations, cela m’est égal : les entreprises pourront réactiver cette fonction via leurs outils d’administration, et les utilisateurs ordinaires pourront l’activer eux-mêmes. Selon cet avis, il suffirait d’afficher une fenêtre du type : « Ce site tente de contrôler un appareil local — autoriser/refuser ».

    • Un autre point de vue estime qu’il y a une confusion : les appareils du réseau local sont déjà protégés contre les sites arbitraires grâce à CORS. Ce n’est pas parfait, mais c’est jugé assez efficace. Le vrai problème, c’est que CORS repose uniquement sur le consentement du serveur cible : le serveur doit autoriser l’accès de ce site web via des en-têtes spécifiques. Cette proposition vise à renforcer cela en exigeant un consentement explicite de l’utilisateur, même si le serveur et le site souhaitent tous deux communiquer. Autrefois, l’accord entre serveur et site semblait suffire, mais des cas récents comme Facebook, où un site accède discrètement à des apps sur le téléphone, ont brisé ce principe. En d’autres termes, la réalité actuelle permet à des sites web et à des serveurs du réseau local d’agir contre l’intérêt de l’utilisateur.

    • En réponse à l’idée que « les utilisateurs ordinaires n’ont qu’à autoriser ou refuser dans une popup », quelqu’un mentionne que macOS demande déjà ce type d’autorisation par application, et que la plupart des utilisateurs cliquent sur « Autoriser » sans réfléchir. Il est donc peu probable qu’un mécanisme par site accroisse énormément leur vigilance.

    • Certains disent ne pas comprendre pourquoi un site web devrait avoir accès au réseau local. Cela ne ferait que créer un tout nouveau modèle de menace de sécurité, et ils doutent qu’il existe déjà des cas où aucune meilleure solution n’est possible.

  • Certains aimeraient qu’Apple, Microsoft et Google appliquent une approche similaire aussi à l’USB et au Bluetooth. Presque toutes les apps installées récemment demandent l’accès au Bluetooth, ce qui est jugé très pénible. L’idée serait que les identifiants des appareils Bluetooth accessibles soient déclarés dans le manifest, et que l’OS limite l’accès à ces seuls appareils. Par exemple, l’app Bose ne devrait voir que les appareils Bose. Quelqu’un raconte avoir déjà refusé des autorisations parce qu’il ne comprenait pas ce que l’application demandait exactement. Comme pour la caméra ou le GPS, il serait souhaitable d’avoir un enregistrement d’identifiant d’appareil et une invite utilisateur. Dans le cas de Bose, on pourrait enregistrer un préfixe bose.xxx et ne demander dans le manifest qu’un accès "bose.*", que l’OS autoriserait selon cette seule règle. Une logique similaire est proposée pour l’USB et les appareils du réseau local, avec l’espoir que l’OS empêche les apps d’explorer librement le réseau, l’USB ou le Bluetooth.

    • Quelqu’un espère qu’un jour, Apple au moins, proposera aux apps une option de « fausse autorisation ». Par exemple, si une app prétend avoir absolument besoin de la liste de contacts, l’OS pourrait lui montrer une liste aléatoire impossible à distinguer d’une vraie. Le même principe pourrait s’appliquer au GPS. Il est aussi mentionné que, d’après ce qui a été entendu, WhatsApp ne permettrait pas d’attribuer des noms aux contacts si l’on ne partage pas son carnet d’adresses.

    • Certains préfèrent un modèle de contrôle granulaire, comme les intégrations tierces de GitHub : « ABC veut consulter mes dépôts. Lesquels souhaitez-vous partager ? »

  • Selon un avis, Internet Explorer résolvait autrefois ce problème avec son système de zones. Voir la documentation Microsoft.

    • Ironiquement, Chrome utilisait aussi partiellement le modèle de sécurité par zones d’IE sous Windows, mais il n’existait presque pas de documentation officielle à ce sujet.

    • Certains trouvent absurde qu’il n’existe pas d’alternative moderne à cela, et estiment que l’accès au réseau local devrait lui aussi être traité comme une permission spéciale, au même titre que la caméra ou le micro.

  • Il semble incroyable que les navigateurs web aient autorisé ce comportement par défaut. Si un site public pouvait accéder en secret à tout mon système de fichiers, ce serait une faille de sécurité effroyable ; pourtant, pour les services du réseau local, les requêtes XHR fonctionnent simplement, et toute la sécurité repose sur la seule configuration du serveur. Pour un développeur, si une app web interne tourne sur son PC de développement pour des tests avec une sécurité très faible voire absente, alors facebook.com, google.com, etc. peuvent y accéder directement. À la maison aussi, beaucoup de gens exécutent des services sans authentification en se fiant au pare-feu du routeur ; difficile d’avoir la certitude qu’ils ont tous bien configuré CORS.

    • Il y a un fort scepticisme sur le fait que tout le monde configure correctement CORS ; en pratique, certains pensent que le taux de non-configuration doit être proche de 0 %.

  • On espère que cette proposition aidera à bloquer la technique de Meta consistant à partager des identifiants entre apps natives et sites web via un mécanisme basé sur localhost avec son propre SDK, surtout sur Android. Plus de détails ici.

  • D’après certains, accorder à un site web une permission générale d’accès au réseau local est une autorisation beaucoup trop grossière et inutilement large. La plupart des sites qui ont réellement besoin d’une telle permission n’ont besoin d’accéder qu’à un seul serveur local. Autoriser tout le local viole donc le principe du moindre privilège. De plus, la plupart des utilisateurs ne savent même pas ce qui tourne sur localhost ou sur leur réseau, et ne perçoivent donc pas correctement le risque.

    • Comme la plupart des gens ne savent pas ce qui écoute sur localhost ou sur le réseau, si le navigateur affiche un message d’autorisation pour, par exemple, http://localhost:3146 ou http://localhost:8089, beaucoup ne comprendront même pas ce que cela signifie. Selon cet avis, un message plus intuitif comme « Ce site tente d’accéder à des ressources du réseau local » serait préférable à un jargon technique.

    • Pour bien faire, il faudrait pratiquement un niveau de contrôle de type pare-feu dans le navigateur, avec une API permettant de gérer finement des éléments comme les CIDR, les ports, etc. Certains souhaiteraient que les extensions de navigateur puissent aussi utiliser une telle API de firewall, ou qu’une interface par défaut permette de distinguer clairement la portée des permissions demandées — par exemple une machine précise comme le routeur, le LAN, le VPN ou le réseau privé de Windows.

  • Depuis la disparition des plugins NPAPI, de nombreux sites publics n’ont plus eu d’autre choix que de lancer un serveur HTTP sur localhost pour s’intégrer à des logiciels locaux. Si l’on complexifie aussi cette ergonomie, cela risque de devenir extrêmement pénible. Selon cet avis, les éditeurs de navigateurs auraient dû prévoir une technologie de remplacement après NPAPI, mais il est maintenant trop tard.

    • La plupart des logiciels préfèrent enregistrer un gestionnaire de protocole au niveau de l’OS : par exemple, si un site transmet un lien comme zoommtg://, le navigateur délègue à Zoom ou à une autre application. Les usages purement locaux comme Jupyter Notebook, sans requêtes cross-origin, ne seraient pas affectés. De même, le retour OAuth2 vers une URL localhost semble n’être qu’une simple redirection et ne poserait donc pas de problème.

    • D’autres estiment qu’il vaudrait même mieux que cette méthode de communication via serveur HTTP local avec une application locale disparaisse complètement, car elle a servi de source à des vulnérabilités de sécurité.

    • Des technologies comme Mozilla Native messaging existent déjà. Elles exigent certes l’installation d’une extension, mais cela est vu comme un compromis équitable par rapport à NPAPI.

    • Si un logiciel local fonctionnait en mode « pull » — l’application interrogeant périodiquement l’extérieur — il ne serait plus nécessaire de lancer un serveur, et cela éviterait en plus qu’un site web ne scanne librement le réseau local d’autrui.

  • En JavaScript, si l’on envoie une requête fetch ou POST sans option CORS, CORS empêche seulement de lire la réponse ; le navigateur envoie quand même la requête. Si une app locale met en place sur son serveur un proxy ajoutant les en-têtes CORS, alors n’importe quel site peut y accéder via fetch/XMLHttpRequest en JavaScript. Les extensions peuvent aussi modifier les en-têtes et contourner CORS. Il est trop facile de contourner cela par simple manipulation d’en-têtes, alors que CSP (Content Security Policy) est en pratique très difficile, voire presque impossible, à contourner. L’app Facebook exploite déjà ce genre d’architecture en faisant tourner son propre serveur proxy CORS. Comme WebSocket existe aussi, même un flag Chrome bloquant l’accès à localhost serait inefficace. Un blocage total de localhost ferait au contraire plus de mal que de bien, puisque de nombreux utilisateurs s’appuient sur des serveurs locaux pour des bookmarks self-hosted, des notes ou des gestionnaires de mots de passe.

  • Des inquiétudes sont aussi exprimées concernant IPv6. Certains se demandent s’il existe vraiment un moyen de déterminer qu’une adresse IPv6 est en partie locale ; sinon, cette proposition poserait problème sur des réseaux IPv6 only. Quelqu’un dit avoir rencontré ce problème dans une app IoT : comme il était difficile d’identifier si une adresse IPv6 était locale, il a choisi de rediriger tout IPv6 vers du local IPv4. Même les adresses IPv6 link-local n’étaient guère utiles dans une app classique. Le fait de traiter les domaines .local comme des serveurs locaux est également délicat, car l’interprétation varie selon les OS. Par exemple, sur Raspberry Pi OS, "some_address" se résout via mDNS, mais pas "someaddress.local", alors que sur Ubuntu 24.04 c’est l’inverse : seul "someaddress.local" fonctionne, pas "someaddress". "someaddress.local." ne fonctionne pas non plus. Enfin, il est frustrant de ne pas pouvoir utiliser de certificats privés pour des adresses du réseau local, et le problème des « restrictions HTTPS pour les adresses locales » devrait impérativement être résolu.

    • Un autre avis rappelle qu’en IPv6, la notion de « routable » existe toujours, et qu’on pourrait donc définir logiquement le caractère site-local au niveau de la table de routage. En IPv4, on structurait autrefois le site dans le 2e octet et le VLAN dans le 3e ; IPv6 offre encore plus d’options. Tous les appareils IPv6 possèdent une adresse link-local, correspondant au VLAN local. .local relève d’Apple, du DNS et plus généralement de la correspondance nom-adresse, sans lien direct avec l’adresse IP elle-même. Pour HTTPS sur un réseau local, on peut utiliser la validation DNS-01 de Let’s Encrypt, des CNAME, etc. C’est assez pénible, mais il existe des solutions gratuites, et des outils comme acme.sh sont recommandés. Il faudrait clarifier plus proprement les concepts d’IPv4, IPv6, DNS, mDNS et Bonjour ; et, avec nostalgie, certains rappellent qu’il fut un temps où même la capture de paquets était payante, alors qu’aujourd’hui la situation est bien meilleure.

    • D’autres précisent qu’il n’existe aucun moyen, depuis l’endpoint, de déterminer si une adresse IPv6 est « locale », précisément parce que le principe d’IPv6 est le routage global. Ils notent aussi que Google lui-même semblait hésiter sur le sens de « local » dans l’article, avant de basculer vers une définition de « private ». Créer via HTTP une frontière de sécurité non standard basée sur le CIDR serait, selon eux, une approche aberrante ; une application devrait être conçue en supposant que le service est public. Quant à .local, il est bien inclus dans la spécification mDNS, mais est en pratique largement ignoré.

  • Certains espèrent sincèrement voir ce mécanisme mis en place rapidement, en particulier avec une possibilité permettant à un domaine HTTPS d’accéder à un site local en HTTP. Ils évoquent de nombreux cas d’usage intéressants dans la maison connectée, les médias et le divertissement.