Mitiga los riesgos asociados con la exposición no intencional de dispositivos y servidores en la red interna de un cliente a la Web en general.
Los sitios web maliciosos que envían solicitudes a dispositivos y servidores alojados en una red privada son una amenaza desde hace mucho tiempo. Por ejemplo, los atacantes pueden cambiar la configuración de un router inalámbrico para habilitar ataques de Man-in-the-Middle. CORS-RFC1918 es una propuesta para bloquear esas solicitudes de forma predeterminada en el navegador y requerir que los dispositivos internos habiliten las solicitudes de Internet pública.
Para comprender cómo este cambio afecta al ecosistema web, el equipo de Chrome está buscando comentarios de los desarrolladores que compilan servidores para redes privadas.
¿Qué es lo que está mal con el statu quo?
Muchos servidores web se ejecutan dentro de una red privada: los routers inalámbricos, las impresoras, los sitios web de intranet, los servicios empresariales y los dispositivos de la Internet de las cosas (IoT) son solo una parte de ellos. Puede parecer que se encuentran en un entorno más seguro que los expuestos al público, pero los atacantes pueden abusar de esos servidores usando una página web como proxy. Por ejemplo, los sitios web maliciosos pueden incorporar una URL que, cuando la víctima la ve (en un navegador habilitado para JavaScript), intenta cambiar la configuración del servidor DNS en el router de banda ancha de la víctima. Este tipo de ataque se denomina “pharming con ataque de conducción” y ocurrió en 2014. Se aprovecharon más de 300,000 routers inalámbricos vulnerables cambiando su configuración de DNS y permitiendo que los atacantes redireccionaran a los usuarios a servidores maliciosos.
CORS-RFC1918
Para mitigar la amenaza de ataques similares, la comunidad web está implementando CORS-RFC1918, el uso compartido de recursos multiorigen (CORS) especializado para redes privadas definido en RFC1918.
Los navegadores que implementan el CORS verifican con los recursos de destino si se pueden cargar desde un origen diferente. Esto se logra con encabezados adicionales intercalados que describen el acceso o con un mecanismo llamado solicitudes de verificación previa, según la complejidad. Lee Uso compartido de recursos entre dominios para obtener más información.
Con CORS-RFC1918, el navegador bloqueará la carga de recursos a través de la red privada de forma predeterminada, excepto los que el servidor permita de forma explícita con CORS y a través de HTTPS. El sitio web que realice solicitudes a esos recursos deberá enviar encabezados de CORS, y el servidor deberá indicar explícitamente que acepta la solicitud de origen cruzado respondiendo con los encabezados de CORS correspondientes. (Los encabezados de CORS exactos aún están en desarrollo).
Se les pedirá a los desarrolladores de esos dispositivos o servidores que realicen dos acciones:
- Asegúrate de que el sitio web que envía solicitudes a una red privada se entregue a través de HTTPS.
- Configura la compatibilidad del servidor con CORS-RFC1918 y responde con los encabezados HTTP esperados.
¿Qué tipos de solicitudes se ven afectadas?
Entre las solicitudes afectadas, se incluyen las siguientes:
- Solicitudes de la red pública a una red privada
- Solicitudes de una red privada a una red local
- Solicitudes de la red pública a una red local
Una red privada: Un destino que se resuelve en el espacio de direcciones privadas definido en el artículo 3 de la RFC1918 en IPv4, una dirección IPv6 asignada a IPv4 en la que la dirección IPv4 asignada es privada o una dirección IPv6 fuera de las subredes ::1/128, 2000::/3 y ff00::/8.
Una red local: Un destino que se resuelve en el espacio de “bucle invertido” (127.0.0.0/8) definido en el artículo 3.2.1.3 de la RFC1122 de IPv4, el espacio “vínculo local” (169.254.0.0/16) definido en la RFC3927 de IPv4, el prefijo “dirección local única” (fc00::/7) definido en el artículo 3 de la RFC4193 de IPv6 o el prefijo “vínculo local” (fe80::/10) definido en el artículo 2.5.6 de la RFC4291 de IPv6.
Una red pública Todas las demás
Planes de Chrome para habilitar CORS-RFC1918
Chrome implementará CORS-RFC1918 en dos pasos:
Paso 1: Las solicitudes a recursos de red privada solo se permitirán desde páginas web HTTPS
Chrome 87 agrega una marca que exige que los sitios web públicos que realizan solicitudes a recursos de red privados usen HTTPS. Puedes ir a about://flags#block-insecure-private-network-requests para habilitarla. Si esta marca está activada, se bloquearán todas las solicitudes a un recurso de red privada desde un sitio web HTTP.
A partir de Chrome 88, los errores de CORS-RFC1918 se informarán como errores de la política de CORS en la consola.
En el panel Red de las herramientas para desarrolladores de Chrome, puedes habilitar la casilla de verificación Solicitudes bloqueadas para enfocarte en las solicitudes bloqueadas:
En Chrome 87, los errores de CORS-RFC1918 solo se informan en la consola de DevTools como ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Puedes probarlo tú mismo con este sitio web de prueba.
Paso 2: Envía solicitudes de comprobación previa con un encabezado especial
En el futuro, cada vez que un sitio web público intente recuperar recursos de una red privada o local, Chrome enviará una solicitud preliminar antes de la solicitud real.
La solicitud incluirá un encabezado Access-Control-Request-Private-Network: true además de otros encabezados de solicitud de CORS. Entre otras cosas, estos encabezados identifican el origen que realiza la solicitud, lo que permite un control de acceso detallado. El servidor puede responder con un encabezado Access-Control-Allow-Private-Network:
true para indicar de forma explícita que otorga acceso al recurso.
Se solicitan comentarios
Si alojas un sitio web en una red privada que espera solicitudes de redes públicas, al equipo de Chrome le interesan tus comentarios y casos de uso. Puedes hacer dos cosas para ayudar:
- Ve a
about://flags#block-insecure-private-network-requests, activa la marca y comprueba si tu sitio web envía solicitudes al recurso de red privada como se espera. - Si tienes algún problema o comentario, informa el problema en crbug.com y establece el componente en
Blink>SecurityFeature>CORS>RFC1918.
Comentarios de ejemplo
Nuestro router inalámbrico entrega un sitio web de administración para la misma red privada, pero a través de HTTP. Si se requiere HTTPS para los sitios web que incorporan el sitio web del administrador, será contenido mixto. ¿Debemos habilitar HTTPS en el sitio web del administrador en una red cerrada?
Este es exactamente el tipo de comentarios que busca Chrome. Informa un problema con tu caso de uso concreto en crbug.com. A Chrome le encantaría saber de ti.
Imagen hero de Stephen Philips en Unsplash.