Mitigar 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 realizan 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 desde la Internet pública.
Para comprender cómo este cambio afecta el ecosistema web, el equipo de Chrome busca comentarios de los desarrolladores que crean servidores para redes privadas.
¿Cuál es el problema con el statu quo?
Muchos servidores web se ejecutan dentro de una red privada: routers inalámbricos, impresoras, sitios web de intranet, servicios empresariales y dispositivos de Internet de las cosas (IoT) son solo algunos de ellos. Pueden parecer estar 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 doméstico de la víctima. Este tipo de ataque se denomina "pharming de paso" y ocurrió en 2014. Se explotaron 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, un uso compartido de recursos multiorigen (CORS) especializado para redes privadas definidas en RFC1918.
Los navegadores que implementan CORS verifican con los recursos de destino si pueden cargarse desde un origen diferente. Esto se logra con encabezados adicionales intercalados que describen el acceso o con un mecanismo llamado solicitudes preliminares, 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 aquellos que el servidor permita explícitamente a través de CORS y 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 estos dispositivos o servidores que realicen dos acciones:
- Asegúrate de que el sitio web que envía solicitudes a una red privada se publique 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 afectados?
Las solicitudes afectadas 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 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: Es 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 de "vínculo local" (169.254.0.0/16) definido en RFC3927 de IPv4, el prefijo de "dirección local única" (fc00::/7) definido en la sección 3 de RFC4193 de IPv6 o el prefijo de "vínculo local" (fe80::/10) definido en la sección 2.5.6 de RFC4291 de IPv6.
Una red pública Todas las demás
Planes de Chrome para habilitar CORS-RFC1918
Chrome incorporará CORS-RFC1918 en dos pasos:
Paso 1: Solo se permitirán las solicitudes a recursos de red privada desde páginas web HTTPS
Chrome 87 agrega una marca que exige que los sitios web públicos que realizan solicitudes a recursos de redes privadas utilicen 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 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 Herramientas para desarrolladores como ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Puedes probarlo tú mismo 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 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 forma explícita que otorga acceso al recurso.
Queremos recibir tus comentarios
Si alojas un sitio web en una red privada que espera solicitudes de redes públicas, al equipo de Chrome le interesa conocer 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 según lo previsto. - Si tienes algún problema o comentario, informa el problema en crbug.com y configura el componente como
Blink>SecurityFeature>CORS>RFC1918.
Ejemplo de comentarios
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 del administrador, se tratará de contenido mixto. ¿Deberíamos habilitar HTTPS en el sitio web del administrador en una red cerrada?
Este es exactamente el tipo de comentarios que Chrome busca. Informa un problema con tu caso de uso concreto en crbug.com. Chrome quiere conocer tu opinión.