Actualizaciones
23 de marzo de 2023: Se actualizó el cronograma, y la baja no ocurrirá hasta Chrome 117.
19 de enero de 2023: Se actualizó el cronograma y la baja no ocurrirá hasta Chrome 114.
12 de agosto de 2022: Se actualizó el cronograma, y la baja no ocurrirá hasta Chrome 109.
10 de febrero de 2022: Se publicó un artículo actualizado en Acceso a redes privadas: presentamos los vuelos previos
25 de agosto de 2021: Se actualizó el anuncio del cronograma y se presentó una prueba de baja.
Chrome dará de baja el acceso a los extremos de red privada desde sitios web no seguros como parte de la especificación de Acceso a redes privadas. El objetivo es proteger a los usuarios de los 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 redireccionaran a servidores maliciosos.
Chrome implementará 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
- Les permitirá a los desarrolladores solicitar una extensión de tiempo para los orígenes elegidos, que no se verán afectados durante la prueba de baja.
- Se presentó una política de Chrome que permitirá que las implementaciones administradas de Chrome omitan la baja de forma permanente. Disponible en Chrome 92.
Si necesitas más tiempo para mitigar el impacto del registro de baja para 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.
Para mitigar el impacto de las nuevas restricciones, usa una de las siguientes estrategias:
- Actualiza tu sitio web a HTTPS y, si es necesario, al servidor de destino.
- Actualiza tu sitio web a HTTPS y usa WebTransport.
- Revierte la relación de incorporación.
Cronograma
- Noviembre de 2020: Solicitud de comentarios sobre los próximos cambios.
- Marzo de 2021: Después de revisar los comentarios y realizar un contacto, se anunciaron los próximos cambios. Se cambió el nombre de la especificación de CORS-RFC1918 a Acceso a redes privadas.
- Abril de 2021: Se lanzó Chrome 90 a la versión estable, y se muestran advertencias de baja.
- Junio de 2021: Se lanza Chrome 92 en fase beta para prohibir las solicitudes de red privada en contextos no seguros. Después de los comentarios de los desarrolladores que solicitaban más tiempo para adaptarse, la baja se aplazó a Chrome 93 y se acompañará de una prueba de baja.
- Julio de 2021: Después de recibir más comentarios de los desarrolladores, la baja y la prueba correspondientes se posponen a Chrome 94. Además, los sitios web privados ya no se ven afectados por la baja.
- Agosto de 2021: Se lanza la versión beta de Chrome 94. Los desarrolladores web pueden comenzar a registrarse para la prueba de baja.
- Septiembre de 2021: Se lanza Chrome 94 al canal estable. Los desarrolladores web deben haberse registrado en la prueba de baja y haber implementado tokens de prueba en la producción.
- Diciembre de 2022: Se envió la encuesta de la prueba de origen y se recibieron comentarios. La prueba de baja se extiende 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, que se lanzará inicialmente en Chrome 114.
- Mayo de 2023 (provisional): El mecanismo basado en permisos se lanzará en Chrome 114. Los sitios web pueden usarlo para salir de la prueba de baja.
- Septiembre de 2023: Se lanza Chrome 117 a 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 esas solicitudes desde contextos seguros. La especificación también extiende el protocolo de uso compartido de recursos entre orígenes (CORS) para que los sitios web ahora deban solicitar explícitamente una concesión de los 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 que se recuperó del 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 Comentarios deseados: 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 pruebas de origen que se usan para facilitar la baja de funciones web. Las pruebas de baja permiten que Chrome den de baja ciertas funciones web y evitan que los sitios web establezcan nuevas dependencias en ellas, al mismo tiempo que otorgan más tiempo a los sitios web dependientes actuales para migrar fuera de ellas.
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 los orígenes web especificados. Luego, deben modificar sus sitios web para publicar 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 durante un tiempo limitado.
Si quieres obtener más información, consulta Comienza 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, los contextos públicos no seguros (en términos generales, los sitios web que no se entregan a través de HTTPS o desde una dirección IP privada) tienen prohibido realizar solicitudes a la red privada. Esto se había planificado anteriormente para Chrome 92, por lo que los mensajes de baja aún pueden mencionar el hito anterior.
Esta baja se acompaña de una prueba de baja, lo que permite que los desarrolladores web cuyos sitios web usen la función obsoleta la sigan usando hasta Chrome 116 registrándose para obtener tokens. Consulta a continuación para obtener instrucciones sobre cómo registrarte y habilitar la prueba en tu sitio web.
Se puede 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 la configuración corporativa, eviten las fallas.
Chrome 117
Finaliza la prueba de baja. Todos los sitios web deben migrarse de la función obsoleta o las políticas de sus usuarios deben configurarse para seguir habilitando la función.
Acciones recomendadas para desarrolladores
Es probable que el primer paso para los sitios web afectados sea ganar tiempo hasta que se pueda implementar una correcció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 para la prueba de origen de Acceso a red privada desde contextos no seguros y obtén un token de prueba para el origen participante.
- Agrega el
Origin-Trial: $tokenespecífico del origen a tu encabezado de respuesta. Este encabezado de respuesta solo se debe configurar en las respuestas de recursos principales y de 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 esta prueba se debe habilitar o inhabilitar antes de que un documento pueda realizar solicitudes, no se puede habilitar a través de 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 representa un desafío para los sitios web que no tienen el control de los encabezados de respuesta, como los sitios web estáticos de github.io que publica un tercero.
Para obtener más información, 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:
Para obtener más detalles sobre cómo administrar las políticas de tus usuarios, consulta este artículo del Centro de ayuda.
Cómo acceder a localhost
Si tu sitio web necesita enviar solicitudes a localhost, solo debes actualizarlo a HTTPS.
El contenido mixto no bloquea las solicitudes segmentadas para http://localhost (o http://127.*.*.*, http://[::1]), incluso cuando se emiten desde contextos seguros.
Ten en cuenta que el motor WebKit y los navegadores basados en él (en particular, Safari) se desvían de la especificación de contenido mixto del W3C y prohiben estas solicitudes como contenido mixto. Tampoco implementan el acceso a red privada, por lo que los sitios web pueden redireccionar a los clientes que usan esos navegadores a una versión HTTP de texto simple del sitio web, que aún les permitiría realizar solicitudes a localhost.
Cómo acceder a direcciones IP privadas
Si tu sitio web necesita enviar solicitudes a un servidor de destino en una dirección IP privada, no es suficiente con actualizar el sitio web del iniciador a HTTPS. El contenido mixto evita que los contextos seguros realicen solicitudes a través de HTTP de texto sin formato, por lo que el sitio web recientemente protegido no podrá realizar las solicitudes. Existen algunas formas 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.
Actualiza ambos extremos a HTTPS
Esta solución requiere control sobre la resolución de DNS de los usuarios, como puede suceder en contextos de intranet, o si los usuarios obtienen las direcciones de sus servidores de nombres de un servidor DHCP que está bajo tu control. También requiere que tengas un nombre de dominio público.
El principal problema de la entrega de sitios web privados a través de HTTPS es que las autoridades certificadoras de la infraestructura de clave pública (AC de PKI) solo proporcionan certificados TLS a sitios web con nombres de dominio públicos. Para solucionar este problema, sigue estos pasos:
- 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 el DNS para que resuelva
intranet.exampleen la dirección IP privada del servidor de destino. - Configura tu servidor privado para que use el certificado TLS de
intranet.example. Esto permite que los usuarios accedan al servidor privado enhttps://intranet.example.
Luego, puedes actualizar el sitio web que inicia las solicitudes a HTTPS y continuar realizando las 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, requiere que el servidor de destino ejecute un servidor WebTransport mínimo (servidor HTTP/3 con algunas modificaciones).
Puedes omitir la falta de un certificado TLS válido firmado por una AC de confianza con WebTransport y su mecanismo de fijación de certificados. Esto permite establecer conexiones seguras a dispositivos privados que podrían tener un certificado con firma automática, por ejemplo. Las conexiones de WebTransport permiten la transferencia de datos bidireccional, pero no las solicitudes de recuperación. Puedes combinar este enfoque con un trabajador de servicio para usar un proxy de solicitudes HTTP de forma transparente a través de la conexión, desde el punto de vista de tu aplicación web. En el 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 en WebRTC. También esperamos que parte de la inversión necesaria se implemente como bibliotecas reutilizables. También creemos que vale la pena considerar 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 la plataforma avanza hacia el fomento del uso de HTTPS de manera más sólida con el tiempo. Independientemente del Acceso a redes privadas, esta sería una inversión sensata de todos modos.
Esperamos que WebTransport a través de HTTP/3 se envíe en Chrome 96 (comenzó una prueba de origen) con mitigaciones para proteger contra el uso compartido de claves y otras prácticas de seguridad de baja calidad, incluidas las siguientes:
- Un tiempo de vencimiento máximo corto para los certificados fijados
- Un mecanismo específico del navegador para revocar ciertas claves que fueron objeto de abuso.
No enviaremos la restricción de contexto seguro hasta al menos dos eventos importantes después del lanzamiento completo de WebTransport. Si es necesario, se extenderá la prueba de baja.
Incorporación inversa
Esta solución no requiere ningún control administrativo sobre la red y se puede usar cuando el servidor de destino no es lo suficientemente potente 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, que luego recupera todos sus subrecursos (como secuencias de comandos o imágenes) desde un servidor público, como una CDN. La app web resultante puede realizar solicitudes al servidor privado, ya que se consideran del mismo origen. Incluso puede hacer solicitudes a otros servidores con IP privadas (pero no localhost), aunque esto puede cambiar a largo plazo.
Si alojas solo un esqueleto en el servidor privado, puedes actualizar la app web enviando recursos nuevos al servidor público, tal como lo harías con una app web pública. Por otro lado, la app 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 lanzar el acceso a redes privadas. 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 a 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 a localhost. La especificación de Acceso a redes privadas también clasifica las solicitudes de sitios web privados a localhost como problemáticas. Con el tiempo, Chrome también dará de baja estas funciones. 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 es controlar las solicitudes de red privada que se inician desde contextos seguros con solicitudes preliminares de CORS. La idea es que, incluso cuando la solicitud se inició desde un contexto seguro, se le solicita al servidor de destino que proporcione una concesión explícita al iniciador. La solicitud solo se envía si el otorgamiento se realiza correctamente.
En resumen, una solicitud de comprobación previa de CORS es una solicitud de OPTIONS de HTTP que contiene algunos encabezados Access-Control-Request-* que indican la naturaleza de la solicitud posterior. Luego, el servidor puede decidir si otorgar o no acceso detallado respondiendo 200 OK con encabezados Access-Control-Allow-*.
Obtén más detalles sobre esto en la especificación.
Restringe las recuperaciones de navegación
Chrome dará de baja y, finalmente, bloqueará las solicitudes de subrecursos a redes privadas. Esto no afectará la navegación a redes privadas, que también se pueden usar en ataques de CSRF.
La especificación de Acceso a red privada no hace una distinción entre los dos tipos de recuperaciones, que eventualmente estarán sujetas a las mismas restricciones.
Foto de portada de Markus Spiske en Unsplash