Actualizaciones
23 de marzo de 2023: Se actualizó el cronograma y la baja no comenzará hasta Chrome 117.
19 de enero de 2023: Se actualizó el cronograma y dejará de estar disponible hasta la versión 114 de Chrome.
12 de agosto de 2022: Se actualizó el cronograma y dejará de estar disponible hasta la versión 109 de Chrome.
10 de febrero de 2022: Se publicó un artículo actualizado en Acceso a redes privadas: Presentación de las comprobaciones preliminares.
25 de agosto de 2021: Se actualizaron el anuncio del cronograma y la introducción de una prueba de baja.
Como parte de la especificación de Acceso a la red privada, Chrome dará de baja el acceso de sitios web no seguros a extremos de red privada. El objetivo es proteger a los usuarios de ataques de falsificación de solicitudes entre sitios (CSRF) dirigidos a routers y otros dispositivos en redes privadas. Estos ataques afectaron a cientos de miles de usuarios, lo que permitió que los atacantes los redireccionen a servidores maliciosos.
Chrome realizará los siguientes cambios:
- Bloqueo de solicitudes a redes privadas de sitios web públicos no seguros a partir de Chrome 94
- Presentamos una prueba de baja que finalizará en Chrome
- Permitirá a los desarrolladores solicitar una extensión de tiempo para los orígenes seleccionados, que no se verán afectados durante la prueba de baja.
- Se agregó una política de Chrome que permitirá que las implementaciones administradas de Chrome omiten la baja de forma permanente. Disponible en Chrome 92.
Si necesitas más tiempo para mitigar el impacto del registro de baja en la prueba de baja.
Si tienes control de administrador sobre los usuarios, puedes volver a habilitar la función mediante las políticas de Chrome.
Usa una de las siguientes estrategias para mitigar el impacto de las restricciones nuevas:
- Actualiza tu sitio web a HTTPS y, si es necesario, el servidor de destino.
- Actualiza tu sitio web a HTTPS y usa WebTransport.
- Revierte la relación de incorporación.
Línea de tiempo
- Noviembre de 2020: Solicita comentarios sobre los próximos cambios.
- Marzo de 2021: Se anuncian los próximos cambios después de revisar los comentarios y hacer la comunicación. Se cambió el nombre de la especificación de CORS-RFC1918 a Acceso de red privada.
- Abril de 2021: Se lanza Chrome 90 a la versión estable y muestra advertencias de baja.
- Junio de 2021: Se lanza Chrome 92 en versión beta, que prohíbe las solicitudes de red privada en contextos no seguros. Tras recibir comentarios de los desarrolladores que solicitan más tiempo para adaptarse, la baja se aplaza a Chrome 93 y se junto con una prueba de baja.
- Julio de 2021: Después de recibir más comentarios de los desarrolladores, la baja y la prueba complementaria se aplazan a Chrome 94. Además, los sitios web privados ya no se verán afectados por la baja.
- Agosto de 2021: Se lanza Chrome 94 en versión beta. Los desarrolladores web pueden comenzar a registrarse en la prueba de baja.
- Septiembre de 2021: Se lanza Chrome 94 en la versión estable. Los desarrolladores web deberían haberse registrado en la prueba de baja y, luego, haber implementado los tokens de prueba en la producción.
- Diciembre de 2022: Se envió la encuesta de prueba de origen y se recibieron comentarios. La prueba de baja se extendió a Chrome 113.
- Marzo de 2023: La prueba de baja se extendió a Chrome 116 y finalizará en Chrome 117. Se está desarrollando un mecanismo alternativo basado en permisos para la versión inicial en Chrome 114.
- Mayo de 2023 (tentativo): Se lanza el mecanismo basado en permisos en Chrome 114. Los sitios web pueden usarla para salir de la prueba de baja.
- Septiembre de 2023: Se lanza Chrome 117 en la versión estable y finaliza la prueba de baja. Chrome bloquea todas las solicitudes de red privada de contextos públicos no seguros.
¿Qué es el Acceso a redes privadas?
El Acceso a redes privadas (antes conocido como CORS-RFC1918) restringe la capacidad de los sitios web para enviar solicitudes a servidores en redes privadas. Solo permite este tipo de solicitudes desde contextos seguros. La especificación también extiende el protocolo de uso compartido de recursos entre dominios (CORS) para que los sitios web ahora tengan que solicitar de manera explícita un otorgamiento de servidores en redes privadas antes de poder enviar solicitudes arbitrarias.
Las solicitudes de red privada son solicitudes cuya dirección IP del servidor de destino es más privada que la desde la que se recuperó el iniciador de la solicitud. Por ejemplo, una solicitud de un sitio web público (https://example.com) a un sitio web privado (http://router.local) o una solicitud de un sitio web privado a localhost.
Obtén más información en Se desean obtener comentarios: CORS para redes privadas (RFC1918).
¿Qué es una prueba de baja?
Las pruebas de baja (antes conocidas como pruebas de origen inverso) son una forma de prueba de origen que se usa para facilitar la baja de funciones web. Las pruebas de baja permiten a Chrome dar de baja ciertas funciones web y evitar que los sitios web creen dependencias nuevas en ellas, al mismo tiempo que les brindan a los sitios web dependientes actuales más tiempo para migrar.
Durante una prueba de baja, las funciones obsoletas no están disponibles para todos los sitios web de forma predeterminada. Los desarrolladores que aún necesiten usar las funciones afectadas deben registrarse en la prueba de baja y obtener tokens para orígenes web específicos y, luego, modificar sus sitios web para que entreguen esos tokens en encabezados HTTP o metaetiquetas (excepto en este caso). Si un sitio web entrega tokens válidos que coinciden con su origen, Chrome permitirá el uso de la función obsoleta por un tiempo limitado.
Si deseas obtener más información, consulta las instrucciones para comenzar a usar las pruebas de origen de Chrome y la guía para desarrolladores web sobre las pruebas de origen.
Qué cambiará en Chrome
Chrome 94
A partir de Chrome 94, se prohíbe que los contextos públicos no seguros (en general, los sitios web que no se entregan a través de HTTPS o una dirección IP privada) envíen solicitudes a la red privada. Esto se había planificado para Chrome 92, por lo que los mensajes de baja aún podrían mencionar el evento importante anterior.
Esta baja incluye una prueba de baja, que les permite a los desarrolladores web cuyos sitios web usen la función obsoleta y que la sigan usando hasta Chrome 116. Para ello, deben registrarse para obtener tokens. Consulta la siguiente información si necesitas instrucciones para registrarte y habilitar la prueba en tu sitio web.
Se pueden aprovechar un par de políticas de Chrome para inhabilitar la baja por completo o en orígenes específicos, de forma indefinida. Esto permite que las instalaciones administradas de Chrome, por ejemplo, las que se encuentran en configuraciones corporativas, eviten fallas.
Chrome 117
La prueba de baja finaliza. Todos los sitios web deben migrarse de la función obsoleta o las políticas de los usuarios configuradas para seguir habilitando la función.
Acciones recomendadas para desarrolladores
Es más probable que el primer paso de los sitios web afectados tarde un poco hasta que se pueda implementar una solución adecuada, ya sea registrándose en la prueba de baja o usando políticas. Luego, el curso de acción recomendado varía según las circunstancias de cada sitio web afectado.
Regístrate para la prueba de baja
- Haz clic en Registrarse a fin de obtener la prueba de Acceso a red privada desde contextos no seguros para obtener un token de prueba para el origen participante.
- Agrega el
Origin-Trial: $tokenespecífico del origen al encabezado de respuesta. Este encabezado de respuesta solo se debe configurar en las respuestas de recurso principal y navegación cuando el documento resultante usa la función obsoleta. Es inútil (aunque inofensivo) adjuntar este encabezado a las respuestas de los subrecursos.
Dado que se debe habilitar o inhabilitar esta prueba para que un documento pueda realizar solicitudes, no se puede habilitar mediante una etiqueta <meta>. Estas etiquetas solo se analizan desde el cuerpo de la respuesta después de que se hayan emitido las solicitudes de los subrecursos. Esto presenta un desafío para los sitios web que no controlan los encabezados de respuesta, como los sitios web estáticos github.io que entrega un tercero.
Para obtener más detalles, consulta la guía para desarrolladores web sobre las pruebas de origen.
Habilitar políticas
Si tienes control de administrador sobre los usuarios, puedes volver a habilitar la función obsoleta con cualquiera de las siguientes políticas:
Si quieres obtener más detalles sobre cómo administrar las políticas para los usuarios, consulta este artículo del Centro de ayuda.
Cómo acceder a localhost
Si tu sitio web necesita emitir solicitudes a localhost, solo debes actualizar tu sitio web a HTTPS.
El contenido mixto no bloquea las solicitudes que se orientan a http://localhost (o http://127.*.*.*, http://[::1]), incluso cuando se emiten desde contextos seguros.
Ten en cuenta que el motor de WebKit y los navegadores que se basan en él (en particular, Safari) se desvían de la especificación de contenido mixto de W3C aquí y prohíben estas solicitudes como contenido mixto. Tampoco implementan el acceso de red privada, por lo que es posible que los sitios web quieran redireccionar a los clientes que usan esos navegadores a una versión HTTP de texto sin formato del sitio web, lo que aún permitiría que esos navegadores realicen solicitudes a localhost.
Accede a direcciones IP privadas
Si tu sitio web necesita emitir solicitudes a un servidor de destino en una dirección IP privada, solo actualizar el sitio web del iniciador a HTTPS no funcionará. El contenido mixto impide que los contextos seguros envíen solicitudes a través de HTTP de texto sin formato, por lo que el sitio web recién protegido aún no podrá realizar las solicitudes. Hay algunas maneras de solucionar este problema:
- Actualiza ambos extremos a HTTPS.
- Usa WebTransport para conectarte de forma segura al servidor de destino.
- Revierte la relación de incorporación.
Actualizar ambos extremos a HTTPS
Esta solución requiere control sobre la resolución de DNS de los usuarios, como podría ser el caso en contextos de intranet o si los usuarios obtienen las direcciones de sus servidores de nombres desde un servidor DHCP bajo tu control. También es necesario que poseas un nombre de dominio público.
El principal problema de entregar sitios web privados a través de HTTPS es que las autoridades certificadoras de infraestructura de clave pública (CA de PKI) solo proporcionan certificados TLS a sitios web con nombres de dominio público. Para solucionar esto:
- Registra un nombre de dominio público (por ejemplo,
intranet.example) y publica registros DNS que dirijan ese nombre de dominio al servidor público que elijas. - Obtén un certificado TLS para
intranet.example. - Dentro de tu red privada, configura DNS para resolver
intranet.exampleen la dirección IP privada del servidor de destino. - Configura tu servidor privado a fin de usar el certificado TLS para
intranet.example. Esto permite que tus usuarios accedan al servidor privado enhttps://intranet.example.
Luego, puedes actualizar el sitio web que inicia las solicitudes a HTTPS y seguir realizando solicitudes como antes.
Esta solución está preparada para el futuro y reduce la confianza que depositas en tu red, lo que amplía el uso de la encriptación de extremo a extremo dentro de tu red privada.
WebTransport
Esta solución no requiere control sobre la resolución de DNS de tus usuarios. Sin embargo, es necesario que el servidor de destino ejecute un servidor de WebTransport mínimo (servidor HTTP/3 con algunas modificaciones).
Puedes evitar la falta de un certificado TLS válido firmado por una AC de confianza mediante WebTransport y su mecanismo de fijación de certificados. Esto permite establecer conexiones seguras con dispositivos privados que pueden tener un certificado autofirmado, por ejemplo. Las conexiones de WebTransport permiten la transferencia bidireccional de datos, pero no las solicitudes de recuperación. Puedes combinar este enfoque con un service worker para usar un proxy transparente en las solicitudes HTTP en la conexión, desde el punto de vista de tu aplicación web. En el lado del servidor, una capa de traducción correspondiente puede convertir los mensajes de WebTransport en solicitudes HTTP.
Reconocemos que esto representa una gran cantidad de trabajo, pero debería ser mucho más fácil que compilar sobre la base de WebRTC. Nuestra esperanza también es que parte de la inversión necesaria se implemente como bibliotecas reutilizables. También creemos que vale la pena tener en cuenta el hecho de que es probable que los contextos no seguros pierdan el acceso a cada vez más funciones de la plataforma web a medida que esta avanza hacia el fomento del uso de HTTPS de forma más sólida con el paso del tiempo. Independientemente del Acceso a la red privada, es probable que esta sea una inversión inteligente.
Esperamos que WebTransport a través de HTTP/3 se envíe en Chrome 96 (comenzó una prueba de origen) con mitigaciones para protegerse contra el uso compartido de claves y otras prácticas de seguridad de baja calidad, incluidas las siguientes:
- Un tiempo de vencimiento máximo breve para los certificados fijados.
- Un mecanismo específico del navegador para revocar ciertas claves que estuvieron sujetas a abuso
No enviaremos la restricción de contexto seguro hasta al menos dos eventos importantes después de que se lance por completo WebTransport. La prueba de baja se extenderá si es necesario.
Incorporación inversa
Esta solución no requiere ningún control de administrador sobre la red y se puede usar cuando el servidor de destino no tiene la potencia suficiente para ejecutar HTTPS.
En lugar de recuperar subrecursos privados de una app web pública, se puede entregar un esqueleto de la app desde el servidor privado, el cual recupera todos sus subrecursos (como secuencias de comandos o imágenes) de un servidor público, como una CDN. La app web resultante puede realizar solicitudes al servidor privado, ya que se consideran en el mismo origen. Incluso puede hacer solicitudes a otros servidores con IP privadas (pero no a localhost), aunque esto puede cambiar a largo plazo.
Si alojas solo un esqueleto en el servidor privado, puedes actualizar la aplicación web si envías recursos nuevos al servidor público, tal como lo harías con una aplicación web pública. Por otro lado, la aplicación web resultante no es un contexto seguro, por lo que no tiene acceso a algunas de las funciones más potentes de la Web.
Planes para el futuro
Restringir las solicitudes de red privada a contextos seguros es solo el primer paso para iniciar el Acceso a la red privada. Chrome está trabajando para implementar el resto de la especificación en los próximos meses. No te pierdas las novedades.
Cómo restringir el acceso de localhost desde sitios web privados
Los cambios en Chrome 94 solo afectan a los sitios web públicos que acceden a direcciones IP privadas o localhost. La especificación de Acceso a redes privadas también clasifica las solicitudes de sitios web privados en localhost como problemáticas. Con el tiempo, Chrome también dejará de estar disponible. Sin embargo, esto presenta un conjunto de desafíos ligeramente diferente, ya que muchos sitios web privados no tienen nombres de dominio, lo que complica el uso de tokens de prueba de baja.
Solicitudes de comprobación previa de CORS
La segunda parte del acceso a redes privadas consiste en controlar solicitudes de red privadas iniciadas desde contextos seguros con solicitudes de comprobación previa de CORS. La idea es que, incluso cuando la solicitud se haya iniciado desde un contexto seguro, se le solicite al servidor de destino que proporcione un otorgamiento explícito al iniciador. La solicitud solo se envía si la concesión se realiza de forma correcta.
En resumen, una solicitud de comprobación previa de CORS es una solicitud HTTP OPTIONS con algunos encabezados Access-Control-Request-* que indican la naturaleza de la solicitud posterior. Luego, el servidor puede decidir si otorga o no acceso detallado respondiendo a 200 OK con encabezados Access-Control-Allow-*.
Obtén más información sobre este tema en la especificación.
Restringe las recuperaciones de navegación
Chrome dará de baja y, con el tiempo, bloqueará las solicitudes de subrecursos a redes privadas. Esto no afectará las navegaciones a redes privadas, que también se pueden usar en los ataques de CSRF.
La especificación del Acceso a redes privadas no hace una distinción entre los dos tipos de recuperaciones, que, en última instancia, estarán sujetas a las mismas restricciones.
Foto de portada de Markus Spiske en Unsplash