Propuesta para restringir qué sitios pueden acceder a la red local del usuario

• El equipo de seguridad de Chrome propuso un nuevo sistema de "permiso de acceso a la red local" para resolver el problema del acceso de los sitios web a la red local
• Actualmente, los sitios web públicos pueden intentar acceder o atacar sin autorización dispositivos de la red local del usuario, como impresoras; esta propuesta busca bloquear las solicitudes a la red local sin permiso del usuario
• A diferencia de Private Network Access (PNA), funcionaría con base en consentimiento de permisos del usuario en lugar de preflight, reforzando el control del usuario y permitiendo adaptarse solo con actualizaciones del sitio, sin cambios en los dispositivos
• En concreto, si un sitio público hace una solicitud fetch a una IP local, un dominio .local, etc., el navegador pedirá consentimiento explícito al usuario si no hay permiso
• Con esta política se refuerzan la seguridad y la privacidad, mientras que los casos de uso legítimos, como la configuración de dispositivos IoT, seguirán funcionando con autorización del usuario

---

Resumen y objetivo de la propuesta

• El equipo Chrome Secure Web and Network publicó un diseño inicial de un esquema de permisos de "acceso a la red local" para resolver el problema del acceso no autorizado desde sitios web públicos a la red local
• Hasta ahora, un sitio visitado podía intentar ataques como CSRF contra dispositivos de la red local del usuario, como impresoras o routers
• La propuesta plantea que el navegador bloquee las solicitudes que crucen límites entre espacios de direcciones, como de IP pública → IP local, y que solo las permita con consentimiento explícito del usuario por sitio

Contexto y diferencias clave

• El sistema actual de Private Network Access (PNA) se basa en preflight (solicitud/respuesta previa), y requería cambios también en los dispositivos, lo que dificultaba su adopción
• Esta propuesta puede implementarse solo con consentimiento de permisos del usuario, y como solo requiere cambios menores en los sitios, su aplicación y expansión serían más viables en la práctica

Objetivos y no objetivos

• Objetivos
  • Bloquear la explotación de dispositivos y servidores vulnerables mediante ataques web tipo drive-by
  • Permitir la comunicación entre sitios públicos y dispositivos locales solo cuando el usuario lo quiera y lo autorice
• No objetivos
  • No se busca bloquear por completo los flujos de uso razonables, como la configuración o el control de dispositivos locales existentes
  • Los problemas de HTTPS en redes locales o la emisión compleja de certificados quedan fuera del alcance de esta propuesta

Casos de uso

• Caso 1: si un usuario común no lo desea, cuando example.com intente hacer una solicitud a 192.168.0.1, el navegador preguntará si la permite y, si se rechaza, bloqueará la solicitud
• Caso 2: las páginas oficiales de configuración web de fabricantes de dispositivos, como equipos IoT o routers, podrán comunicarse tras obtener permiso del usuario en el primer acceso

Diseño concreto

• Separación de espacios de direcciones:
  • La capa de red IP se clasifica en tres niveles: loopback (solo para sí mismo), local (dentro de la red local) y public (accesible para todos)
  • Incluye varios criterios para identificar la red local, como dominios .local, IP privadas de RFC1918/4193 y nombres link-local de RFC6762
• Solicitudes a la red local: public→local, public→loopback, local→loopback y otros accesos desde un espacio más público hacia una red interna requerirán permiso
  • Se considerarán solicitudes a la red local tanto las que van de la red pública a la red local/loopback como las de local a loopback
  • Excepciones: local→local o loopback→cualquier dirección no estarán sujetas a restricción
• Prompt de permisos:
  • Cuando un sitio haga una solicitud hacia la red local y no tenga permiso, el navegador mostrará un prompt preguntando al usuario si desea permitirlo
  • Si se rechaza, la solicitud se bloquea; si se acepta, continúa
• Integración con fetch API: se puede indicar una opción como targetAddressSpace: "local" en una llamada fetch, lo que permite distinguir claramente el destino
  • La especificación de Fetch solo define la conexión, no la resolución DNS, así que la verificación de si se trata de una solicitud a la red local se hará al establecer una nueva conexión
  • Las solicitudes a la red local solo se permitirán en contextos seguros; si no se obtuvo permiso, aparecerá el prompt, y si se concede, se permitirá la solicitud
  • Al agregar el parámetro targetAddressSpace en las opciones de fetch(), los desarrolladores podrán especificar explícitamente el espacio de direcciones de destino
    • ej.) fetch("http://router.com/ping";, { targetAddressSpace: "local" })
  • Si la dirección realmente conectada no coincide con el espacio indicado en la opción, la solicitud fallará para evitar bypasses de contenido mixto
• La misma política se aplicará a HTML, WebRTC, ServiceWorker, etc.
  • Se agregarán valores de espacio de direcciones a documentos HTML/workers para rastrear el espacio según el origen
  • Al agregar candidatos en el ICE Agent de WebRTC, las direcciones locales/loopback usarán prompt de permisos
  • Los permisos se integrarán con la Permissions API, para que un sitio pueda consultar su estado actual
  • Por defecto, solo el documento de nivel superior podrá acceder a la red local; si es necesario, podrá delegar el permiso a iframes mediante la política de delegación de Permissions Policy
• Problemas de contenido mixto (HTTP/HTTPS):
  • Se contemplan escenarios como intentos de acceso a la red local desde contextos no seguros, carga de subrecursos por HTTP o aplicación del bloqueo de contenido mixto
  • Para literales de IP privadas, dominios .local y solicitudes con targetAddressSpace, se omitirán los pasos de upgrade y bloqueo de contenido mixto, y en la conexión posterior se bloqueará si el origen no tiene permiso
• Ejemplos de funcionamiento
  • Ante un acceso inesperado a la red local, el usuario puede rechazar el permiso para bloquear solicitudes no autorizadas
  • En el caso de una página de control de dispositivos operada por el fabricante, si se hace la llamada con la propiedad adecuada (por ejemplo, targetAddressSpace="local"), podrá seguir funcionando como hasta ahora con el consentimiento del usuario

Alternativas y debate

• Enfoque PNA:
  • El PNA existente requería CORS preflight, pero su aplicación y despliegue reales eran difíciles
  • En algunos tramos se propuso usar prompts de permisos y permitir excepciones de contenido mixto
  • Existen limitaciones prácticas por problemas de DNS o falta de soporte en las especificaciones de ciertos dispositivos
• Bloquear todas las solicitudes a la red local: es simple, pero no es realista porque rompería casos de uso y aumentaría el costo de evasión
• Mantener el estado actual: a medida que los sistemas operativos empiezan a gestionar permisos de red local por aplicación, se subraya la necesidad de hacerlo también a nivel del navegador
• Alternativas para contenido mixto:
  • Se debatió evaluar la seguridad del método de conexión e implementar opciones como "permitir solo subrecursos seguros de la red local"
  • También se discutieron alternativas como declarar el espacio de direcciones mediante headers de respuesta/meta tags o agregar atributos a elementos HTML

Puntos adicionales

• Se discute la posibilidad de agregar atributos de espacio de direcciones también a subrecursos HTML, como iframe o img
• Se reflejan resultados de investigación sobre problemas como la transitividad excesiva de permisos una vez concedidos
• Se plantea restringir el acceso a la red local durante la navegación del frame principal o mostrar una pantalla de advertencia intersticial
• También se considera tratar de forma amplia como solicitudes a la red local todas las solicitudes cross-origin dirigidas a direcciones local/loopback
• Se estudian mecanismos de permisos más granulares por red, así como la necesidad de volver a pedir consentimiento al cambiar de red o de ubicación

Consideraciones de seguridad y privacidad

• Existe preocupación de que un sitio con permiso amplíe su capacidad de explorar y acceder a todos los dispositivos de la red del usuario
• Al aceptar el prompt, el usuario debe entender claramente la intención; frente al enfoque basado en preflight, esto ofrece un control más directo
• Sin permiso previo, no se permitirá ninguna solicitud a la red local, lo que fortalece la protección de la privacidad

[GN⁺]

Opiniones en Hacker News

• Cuando vi esto por primera vez, me gustó la idea; me parece un riesgo totalmente absurdo que un sitio web pueda enviar solicitudes HTTP a IP locales (o en realidad a cualquier IP). Incluso si esto rompe algunas apps empresariales o integraciones, no me preocupa mucho: las empresas pueden volver a habilitar la función con herramientas de administración, y los usuarios normales pueden configurarlo manualmente. En mi opinión, bastaría con mostrar un aviso como: "Este sitio web quiere controlar dispositivos locales: permitir/denegar".

  • Se plantea una perspectiva que corrige un malentendido: los dispositivos de la red local ya están protegidos contra sitios web arbitrarios gracias a CORS. No es perfecto, pero sí bastante efectivo. El problema es que CORS depende únicamente del consentimiento del servidor de destino: el servidor tiene que permitir el acceso de ese sitio web mediante ciertos headers. Esta propuesta busca reforzar eso para que, incluso si tanto el servidor como el sitio web quieren comunicarse, haga falta una aprobación explícita del usuario. Antes se asumía que el acuerdo entre servidor y sitio web era suficiente, pero casos recientes como Facebook, donde un sitio accede en secreto a apps dentro del teléfono, rompieron ese principio. Es decir, ahora existe la realidad de que el sitio web y el servidor de la red local pueden actuar en contra del interés del usuario.

  • Sobre la idea de que "los usuarios normales simplemente pueden permitir o denegar desde un popup", se menciona que macOS ya hace hoy solicitudes de permisos de este tipo por aplicación, y que la mayoría de los usuarios simplemente pulsa "Permitir" sin pensar demasiado. Aunque se hiciera por sitio, probablemente eso no aumentaría tanto la cautela.

  • No se entiende por qué un sitio web debería necesitar acceso a la red local. Eso solo crea un modelo de amenaza completamente nuevo. También se cuestiona si realmente existe algún caso donde no haya una solución mejor.

• Ojalá Apple, Microsoft y Google hicieran algo parecido también con USB y Bluetooth. Últimamente casi todas las apps que uno instala piden permiso para acceder a Bluetooth, y eso resulta muy molesto. Sería ideal que la app tuviera que declarar en el manifest los IDs de los dispositivos Bluetooth a los que puede acceder, y que el sistema operativo limitara el acceso solo a esos dispositivos. Por ejemplo, la app de Bose debería poder ver únicamente dispositivos Bose. Se comenta una experiencia de haber rechazado apps por los permisos que pedían. Igual que con la cámara o el GPS, estaría bien contar con registro de IDs de dispositivo y un prompt al usuario. En el caso de Bose, podría registrarse un prefijo como bose.xxx y que en el manifest solo pidiera acceso a bose.*, para que el sistema operativo permita únicamente esa regla. Se propone aplicar un sistema de identificación parecido también a USB y a dispositivos de red local. La idea es que el sistema operativo impida que las apps exploren libremente la red, USB o Bluetooth.

  • Se espera que algún día al menos Apple ofrezca a las apps una opción de "permiso falso". Por ejemplo, si una app dice que necesita la lista de contactos, que en lugar de la real reciba una lista aleatoria indistinguible. Algo parecido también para el GPS. Incluso se menciona haber oído que WhatsApp no permite asignar nombres a contactos si no compartes la libreta de contactos.

  • Se prefiere un modelo de permisos más granular, como las integraciones de terceros de GitHub: "ABC quiere ver mis repositorios. ¿Qué repositorios quiero compartir?".

• Se señala que Internet Explorer antes resolvía este tipo de problemas con su sistema de zonas (zoning); para más detalles, ver la documentación de Microsoft.

  • Irónicamente, Chrome también usó en parte el esquema de seguridad por zonas de IE en Windows, pero casi no hubo documentación oficial al respecto.

  • Se considera absurdo que no exista una alternativa moderna a eso. El acceso a la red local también debería permitirse solo como un permiso especial, al nivel de la cámara o el micrófono.

• Cuesta creer que los navegadores web hayan permitido esto por defecto. Si un sitio web público pudiera acceder en secreto a todo mi sistema de archivos sería una vulnerabilidad espantosa, pero con servicios de red local se puede hacer simplemente vía XHR, dejando la seguridad solo en manos de la configuración del servidor. Si eres desarrollador y ejecutas una webapp interna en tu PC de desarrollo para hacer pruebas, con seguridad muy relajada o inexistente, entonces facebook.com o google.com podrían acceder a ella directamente. En casa también hay mucha gente que confía en el firewall del router y ejecuta servicios sin autenticación; no está nada claro que todos tengan bien configurado CORS.

  • Hay escepticismo respecto a que todo el mundo tenga CORS bien configurado; se sostiene que en la práctica el porcentaje de servicios sin configurar correctamente debe ser cercano a 0%.

• Se espera que esta propuesta pueda ayudar a impedir que Meta use su SDK para compartir códigos de identificación entre apps nativas y sitios web mediante un truco basado en localhost. En particular se menciona este caso en Android: más detalles aquí.

• Se critica que un sitio web tenga como permiso algo tan tosco y excesivamente amplio como "acceso a la red local". La mayoría de los sitios que realmente necesitan permiso solo requieren acceso a un único servidor local. Permitir todo lo local viola el principio de mínimo privilegio. Además, la mayoría de los usuarios ni siquiera sabe qué está corriendo en localhost o en su red, así que tampoco comprende bien el riesgo.

  • Como la mayoría de las personas no sabe si hay algo ejecutándose en localhost o en la red, aunque el navegador mostrara un mensaje de permiso para http://localhost:3146 o http://localhost:8089, ni siquiera podrían adivinar qué significa. Un mensaje más intuitivo para el usuario, en vez de jerga técnica, sería algo como: "Este sitio quiere acceder a recursos de la red local".

  • Para implementarlo bien, en la práctica haría falta algo parecido a un firewall dentro del navegador. Sería bueno tener una API con control detallado sobre CIDR, puertos, etc. También estaría bien que las extensiones del navegador pudieran usar esa API de firewall, o que la interfaz por defecto distinguiera con claridad entre rangos como una máquina específica (por ejemplo, el router), la LAN, la VPN o la private network de Windows, para pedir permisos por separado para cada uno.

• Se menciona que, desde la desaparición de los plugins NPAPI, muchos sitios web públicos que quieren integrarse con software local no tienen otra opción que levantar un servidor HTTP en localhost. Si además se complica esa usabilidad, podría volverse muy incómodo. Los desarrolladores de navegadores debieron haber preparado una tecnología alternativa después de NPAPI, pero ahora ya es tarde.

  • La mayoría del software prefiere registrar handlers de protocolo a nivel del sistema operativo, de modo que si un sitio web pasa un enlace como zoommtg://, el navegador lo deriva a Zoom o a la app correspondiente. Cosas como Jupyter Notebook, que se usan localmente sin solicitudes cross-origin, no se verían afectadas. Tampoco parece problemático redirigir a una URL localhost después de un login OAuth2, porque solo sería un redirect.

  • También se expresa la postura de que sería incluso mejor si este modelo de comunicación vía servidor HTTP con apps locales desapareciera por completo, porque ha servido como fuente de vulnerabilidades de seguridad.

  • Ya existen tecnologías como Mozilla Native messaging. Requieren instalar una extensión, pero comparado con NPAPI se considera un enfoque más justo.

  • Si el software local funcionara con un modelo de "pull" (la app hace solicitudes periódicas hacia afuera), ya no haría falta levantar un servidor, y además se evitaría que sitios web escaneen sin control distintas partes de la red local ajena.

• En JavaScript, si se hace un fetch o una solicitud POST sin opción de cors, CORS solo impide leer la respuesta, pero el navegador sí envía la solicitud. Si una app local logra que el servidor añada headers CORS mediante un proxy, cualquier sitio podría acceder vía JS fetch/XMLHttpRequest. Las extensiones también pueden modificar headers y saltarse CORS. Es demasiado fácil hacer este tipo de bypass tocando headers, mientras que CSP (Content Security Policy) es realmente muy difícil o casi imposible de eludir. La app de Facebook incluso hoy opera con su propio servidor proxy de cors para este tipo de estructura. También existe WebSocket, así que aunque Chrome tenga un flag para bloquear acceso a localhost, sería inútil. Bloquear localhost por completo haría más daño que bien, porque muchos usuarios usan servidores locales para bookmarks self-hosted, notas, gestores de contraseñas y similares; impedir esos casos sería irracional.

• Hay preocupación por problemas en entornos IPv6. Se pregunta si realmente existe una forma de distinguir si una dirección IPv6 es parcialmente local; de no ser así, esta propuesta sería problemática en redes solo IPv6. Se comenta una experiencia en apps IoT donde costaba identificar si una dirección IPv6 era local, así que se optó por redirigir todo IPv6 a local IPv4. Incluso las direcciones IPv6 link-local resultaban poco útiles en apps normales. El hecho de considerar dominios .local como servidores locales también depende mucho de la implementación del sistema operativo y no es consistente: por ejemplo, en Raspberry Pi OS some_address se resuelve por mDNS pero someaddress.local no; en Ubuntu 24.04 funciona someaddress.local pero no someaddress; y someaddress.local. tampoco funciona. Por último, también frustra no poder usar certificados privados para direcciones de red local, y se enfatiza que el problema de "restringir https para direcciones locales" también debe resolverse.

  • Se responde que IPv6 todavía conserva el concepto de "enrutable", así que lógicamente se podría definir si algo es site-local a nivel de tabla de ruteo. Antes en IPv4 se usaba una estructura con site en el segundo octeto y VLAN en el tercero; IPv6 ofrece más opciones. Todos los dispositivos IPv6 tienen una dirección link-local (la VLAN local), y .local es un término relacionado con el mapeo entre nombre y dirección en Apple, DNS, etc., no directamente con la dirección IP. Para certificados https en la red local se puede usar la validación DNS-01 de Let's Encrypt, CNAME y similares. Es engorroso, pero hay opciones gratuitas, y también se recomienda una herramienta como acme.sh. Se sugiere ordenar mejor conceptos como IPv4, IPv6, DNS, mDNS y Bonjour, recordando incluso tiempos en que hasta capturar paquetes era de pago; ahora todo está mucho mejor.

  • Se reafirma con claridad la postura de que no hay manera de que el endpoint determine si una dirección IPv6 es "local", porque el principio de IPv6 es el enrutamiento global. Se critica que incluso Google, al discutir el significado de "local" en el artículo, terminó cambiándolo a una definición de "private", lo que demuestra confusión. Crear mediante una extensión de HTTP una frontera de seguridad no estándar basada en CIDR parece un enfoque absurdo. La postura es que las apps deberían diseñar su modelo de seguridad asumiendo que son servicios públicos. .local está incluido en la especificación de mDNS, pero en la práctica casi siempre se ignora.

• Se expresa un deseo genuino de que esto se implemente pronto, especialmente con una función que permita a un dominio HTTPS acceder a un sitio local HTTP. Se mencionan muchos casos de uso interesantes en smart home, medios y entretenimiento.