Se desean comentarios: CORS para redes privadas (RFC1918)

Mitiga los riesgos asociados con la exposición involuntaria de los dispositivos y servidores de la red interna de un cliente a la Web en general.

Eiji Kitamura

Los sitios web maliciosos que realizan solicitudes a dispositivos y servidores alojados en una red privada han sido una amenaza durante mucho tiempo. Los atacantes pueden, por ejemplo, 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 exigir que los dispositivos internos acepten las solicitudes de la Internet pública.

Para comprender cómo este cambio afecta el ecosistema web, el equipo de Chrome busca comentarios de los desarrolladores que creen servidores para redes privadas.

¿Cuál es el problema con el statu quo?

Muchos servidores web se ejecutan en una red privada; los routers inalámbricos, impresoras, sitios web de intranet, servicios empresariales y dispositivos de la Internet de las cosas (IoT) son solo parte de ellos. Pueden parecer que se encuentran en un entorno más seguro que los que se exponen al público, pero los atacantes pueden abusar de esos servidores mediante una página web como proxy. Por ejemplo, los sitios web maliciosos pueden incorporar una URL que, cuando simplemente la ve (en un navegador con JavaScript habilitado), intenta cambiar la configuración del servidor DNS en el router de banda ancha de la casa de la víctima. Este tipo de ataque se denomina "Drive-By Pharming" y ocurrió en 2014. Se modificaron los parámetros de configuración del DNS y permitieron que los atacantes redireccionaran a los usuarios a servidores maliciosos para explotar más de 300,000 routers inalámbricos vulnerables.

CORS-RFC1918

Para mitigar la amenaza de ataques similares, la comunidad web aporta CORS-RFC1918, un uso compartido de recursos entre dominios (CORS) especializado para redes privadas definidas en RFC1918.

Los navegadores que implementan 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 mediante un mecanismo llamado solicitudes de comprobación previa, según la complejidad. Consulta 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 explícitamente mediante CORS y HTTPS. El sitio web que realiza solicitudes a esos recursos deberá enviar encabezados de CORS, y el servidor deberá indicar explícitamente que acepta la solicitud de origen cruzado mediante la respuesta con los encabezados de CORS correspondientes. (Los encabezados de CORS exactos aún están en desarrollo).

Se solicitará a los desarrolladores de dichos dispositivos o servidores que realicen las siguientes dos tareas:

  • Asegúrate de que el sitio web que realiza solicitudes a una red privada se entregue a través de HTTPS.
  • Configura la compatibilidad del servidor para 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 dirección privada definido en la sección 3 de 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 la sección 3.2.1.3 de RFC1122 de IPv4, el espacio “link-local” (169.254.0.0/16) definido en RFC3927 de IPv4, el prefijo “Dirección local única” (fc00::/7) definido en la sección 3 de la secciónRFC4193fe80::/10RFC4291

Una red pública Todos los demás.

Relación entre redes locales, públicas, privadas en CORS-RFC1918
Relación entre las redes locales, privadas y públicas en CORS-RFC1918.

Chrome planea habilitar CORS-RFC1918

Chrome lleva CORS-RFC1918 en dos pasos:

Paso 1: Solo se permitirán solicitudes a recursos de red privada desde páginas web HTTPS

En Chrome 87, se agrega una función experimental que exige que los sitios web públicos que envíen solicitudes a recursos de red privada estén en HTTPS. Puedes ir a about://flags#block-insecure-private-network-requests para habilitarla. Con esta marca 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.

Los errores de CORS-RFC1918 se informarán como errores de la política de CORS en la consola.
Los errores de CORS-RFC1918 se informarán como errores de la política de CORS en Console.

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:

Los errores de CORS-RFC1918 también se informarán como errores de CORS en el panel Network.
Los errores de CORS-RFC1918 también se informarán como errores de CORS en el panel Red.

En Chrome 87, los errores de CORS-RFC1918 solo se informan en la consola de Herramientas para desarrolladores como ERR_INSECURE_PRIVATE_NETWORK_REQUEST.

Puedes probarlo en 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 de comprobación previa 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 manera explícita que otorga acceso al recurso.

Necesitamos tus comentarios

Si alojas un sitio web en una red privada que espera solicitudes de redes públicas, el equipo de Chrome estará interesado en tus comentarios y casos de uso. Hay dos cosas que puedes hacer para ayudar:

  • Ve a about://flags#block-insecure-private-network-requests, activa la marca y verifica si tu sitio web envía solicitudes al recurso de red privada como se espera.
  • Si tienes algún problema o tienes comentarios, infórmalo en crbug.com y establece el componente en Blink>SecurityFeature>CORS>RFC1918.

Comentarios de ejemplo

Nuestro router inalámbrico entrega un sitio web de administrador para la misma red privada, pero a través de HTTP. Si se requiere HTTPS para los sitios web que incorporan el sitio web de administrador, será contenido mixto. ¿Debemos habilitar HTTPS en el sitio web de administración en una red cerrada?

Este es exactamente el tipo de comentarios que Chrome busca. Informa el problema de tu caso de uso concreto en crbug.com. Chrome se complacerá en conocer tu opinión.

Hero image de Stephen Philips en Unsplash.