Actualizaciones
- 7 de julio de 2022: Se actualizó el estado actual y se agregó la definición del espacio de direcciones IP.
- 27 de abril de 2022: Se actualizó el anuncio del cronograma.
- 7 de marzo de 2022: Se anunció la reversión después de que se descubrieron problemas en Chrome 98.
Introducción
Chrome dará de baja el acceso directo a los extremos de red privada desde sitios web públicos como parte de la especificación de acceso a redes privadas (PNA).
Chrome comenzará a enviar una solicitud preliminar de CORS antes de cualquier solicitud de red privada para un subrecurso, que solicitará permiso explícito del servidor de destino. Esta solicitud de comprobación previa llevará un encabezado nuevo, Access-Control-Request-Private-Network: true, y la respuesta a esta debe llevar un encabezado correspondiente, Access-Control-Allow-Private-Network: true.
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 redireccionaran a servidores maliciosos.
Plan de lanzamiento
Chrome lanzará este cambio en dos fases para darles tiempo a los sitios web de detectarlo y realizar los ajustes necesarios.
En Chrome 104:
- Chrome realiza experimentos enviando solicitudes preliminares antes de las solicitudes de subrecursos de red privada.
- Las fallas de la verificación preliminar solo muestran advertencias en DevTools, sin afectar las solicitudes de red privada.
- Chrome recopila datos de compatibilidad y se comunica con los sitios web afectados más grandes.
- Esperamos que sea ampliamente compatible con los sitios web existentes.
En Chrome 113 o versiones posteriores:
- Esto comenzará solo si los datos de compatibilidad indican que el cambio es lo suficientemente seguro y si nos comunicamos directamente cuando sea necesario.
- Chrome aplica la política de que las solicitudes de verificación previa deben tener éxito, de lo contrario, se rechazan.
- Al mismo tiempo, comienza una prueba de baja para permitir que los sitios web afectados por esta fase soliciten una extensión de tiempo. La prueba durará al menos 6 meses.
¿Qué es el acceso a redes privadas (PNA)?
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.
Chrome ya implementó parte de la especificación: a partir de Chrome 96, solo los contextos seguros pueden realizar solicitudes de red privada. Consulta nuestra entrada de blog anterior para obtener más información.
La especificación también extiende el protocolo de uso compartido de recursos entre dominios (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.
Cómo clasifica la PNA las direcciones IP y cómo identifica una red privada
Las direcciones IP se clasifican en tres espacios de direcciones IP:
- public
- private
- local
El espacio de direcciones IP local contiene direcciones IP que son direcciones de bucle invertido IPv4 (127.0.0.0/8) definidas en el artículo 3.2.1.3 de la RFC1122 o direcciones de bucle invertido IPv6 (::1/128) definidas en el artículo 2.5.3 de la RFC4291.
El espacio de direcciones IP privadas contiene direcciones IP que solo tienen significado dentro de la red actual, incluidas 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16 definidas en RFC1918, las direcciones 169.254.0.0/16 de vínculo local definidas en RFC3927, las direcciones unicast IPv6 locales únicas fc00::/7 definidas en RFC4193, las direcciones unicast IPv6 de vínculo local fe80::/10 definidas en la sección 2.5.6 de RFC4291 y las direcciones IPv6 asignadas a IPv4 en las que la dirección IPv4 asignada es privada.
El espacio de direcciones IP públicas contiene todas las demás direcciones que no se mencionaron anteriormente.
Una dirección IP local se considera más privada que una dirección IP privada, que se considera más privada que una dirección IP pública.
Obtén más información en Se solicitan comentarios: CORS para redes privadas (RFC1918).
Solicitudes de comprobación previa
Segundo plano
Las solicitudes de comprobación previa son un mecanismo que presenta el estándar de uso compartido de recursos entre dominios (CORS) que se usa para solicitar permiso a un sitio web de destino antes de enviarle una solicitud HTTP que podría tener efectos secundarios. Esto garantiza que el servidor de destino comprenda el protocolo CORS y reduce significativamente el riesgo de ataques CSRF.
La solicitud de permiso se envía como una solicitud HTTP OPTIONS con encabezados de solicitud de CORS específicos que describen la próxima solicitud HTTP. La respuesta debe incluir encabezados de respuesta de CORS específicos que acepten explícitamente la próxima solicitud.
Novedades de Acceso a redes privadas
Se introduce un nuevo par de encabezados de solicitud y respuesta para las solicitudes de verificación previa:
Access-Control-Request-Private-Network: truese establece en todas las solicitudes de verificación previa de PNA.- Se debe configurar
Access-Control-Allow-Private-Network: trueen todas las respuestas de verificación previa de PNA.
Las solicitudes preliminares de PNA se envían para todas las solicitudes de red privada, sin importar el método ni el modo de solicitud. Se envían antes de las solicitudes en el modo cors, así como en no-cors y todos los demás modos. Esto se debe a que todas las solicitudes de red privada se pueden usar para ataques CSRF, independientemente del modo de solicitud y de si el contenido de la respuesta está disponible o no para el iniciador.
Las solicitudes de verificación previa para la PNA también se envían para solicitudes del mismo origen, si la dirección IP de destino es más privada que la del iniciador. Esto es diferente de la CORS normal, en la que las solicitudes de verificación previa son solo para solicitudes entre dominios. Las solicitudes de verificación previa para solicitudes del mismo origen protegen contra los ataques de revinculación de DNS.
Ejemplos
El comportamiento observable depende del modo de la solicitud.
Modo sin CORS
Supongamos que https://foo.example/index.html incorpora <img src="https://bar.example/cat.gif" alt="dancing cat"/> y bar.example se resuelve en 192.168.1.1, una dirección IP privada según RFC 1918.
Primero, Chrome envía una solicitud de comprobación previa:
HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true
Para que se procese esta solicitud de forma correcta, el servidor debe responder con lo siguiente:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true
Luego, Chrome enviará la solicitud real:
HTTP/1.1 GET /cat.gif
...
A la que el servidor puede responder con normalidad.
Modo de CORS
Supongamos que https://foo.example/index.html ejecuta el siguiente código:
await fetch('https://bar.example/delete-everything', {
method: 'PUT',
credentials: 'include',
})
Una vez más, supongamos que bar.example se resuelve en 192.168.1.1.
Primero, Chrome envía una solicitud de comprobación previa:
HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true
Para que se procese esta solicitud de forma correcta, el servidor debe responder con lo siguiente:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
Luego, Chrome enviará la solicitud real:
HTTP/1.1 PUT /delete-everything
Origin: https://foo.example
A las que el servidor puede responder según las reglas habituales de CORS:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
Cómo saber si tu sitio web se ve afectado
A partir de Chrome 104, si se detecta una solicitud de red privada, se enviará una solicitud preliminar antes de ella. Si esta solicitud de verificación previa falla, se enviará la solicitud final, pero aparecerá una advertencia en el panel de problemas de DevTools.
Las solicitudes de verificación previa afectadas también se pueden ver y diagnosticar en el panel de red:
Si tu solicitud hubiera activado una verificación previa de CORS normal sin reglas de acceso a la red privada, es posible que aparezcan dos verificaciones previas en el panel de red, y la primera siempre parezca haber fallado. Este es un error conocido y puedes ignorarlo.
Para revisar lo que sucede si se aplica el éxito de la verificación preliminar, puedes pasar el siguiente argumento de línea de comandos a partir de Chrome 98:
--enable-features=PrivateNetworkAccessRespectPreflightResults
Cualquier solicitud de comprobación previa que falle provocará que la recuperación falle. Esto te permitirá probar si tu sitio web funcionará después de la segunda fase de nuestro plan de lanzamiento. Los errores se pueden diagnosticar de la misma manera que las advertencias con los paneles de DevTools mencionados anteriormente.
Qué hacer si tu sitio web se ve afectado
Cuando se lance este cambio en Chrome 104, no se espera que afecte a ningún sitio web. Sin embargo, te recomendamos que actualices las rutas de solicitud afectadas para asegurarte de que tu sitio web siga funcionando como se espera.
Tienes dos soluciones disponibles:
- Controla las solicitudes de comprobación previa del servidor
- Inhabilita las verificaciones de PNA con políticas empresariales
Controla las solicitudes de comprobación previa del servidor
Actualiza el servidor de destino de las recuperaciones afectadas para controlar las solicitudes de verificación previa de PNA. Primero, implementa la compatibilidad con las solicitudes de comprobación previa de CORS estándar en las rutas afectadas. Luego, agrega compatibilidad con los dos encabezados de respuesta nuevos.
Cuando tu servidor recibe una solicitud de verificación previa (una solicitud OPTIONS con encabezados de CORS), debe verificar la presencia de un encabezado Access-Control-Request-Private-Network: true. Si este encabezado está presente en la solicitud, el servidor debe examinar el encabezado Origin y la ruta de la solicitud junto con cualquier otra información relevante (como Access-Control-Request-Headers) para garantizar que la solicitud sea segura.
Por lo general, debes permitir el acceso a un solo origen bajo tu control.
Una vez que el servidor decida permitir la solicitud, debería responder 204 No Content (o 200 OK) con los encabezados de CORS necesarios y el nuevo encabezado PNA. Estos encabezados incluyen Access-Control-Allow-Origin y Access-Control-Allow-Private-Network: true, así como otros según sea necesario.
Consulta los ejemplos para ver situaciones concretas.
Inhabilita las verificaciones de Acceso a la red privada con políticas empresariales
Si tienes control administrativo sobre tus usuarios, puedes inhabilitar las verificaciones de Acceso a la red privada con cualquiera de las siguientes políticas:
Para obtener más información, consulta Información sobre la administración de políticas de Chrome.
Envíanos tus 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.
Para informarnos al respecto, informa un problema con Chromium en crbug.com y establece el componente en Blink>SecurityFeature>CORS>PrivateNetworkAccess.
¿Qué sigue?
A continuación, Chrome extenderá las verificaciones de acceso a la red privada para abarcar los trabajadores web: trabajadores dedicados, trabajadores compartidos y service workers. De manera tentativa, nuestro objetivo es que Chrome 107 comience a mostrar advertencias.
Luego, Chrome extenderá las verificaciones de Acceso a redes privadas para abarcar las navegaciones, incluidos los iframes y las ventanas emergentes. De manera tentativa, esperamos que Chrome 108 comience a mostrar advertencias.
En ambos casos, procederemos con cautela con un lanzamiento gradual similar para darles a los desarrolladores web tiempo para ajustarse y estimar el riesgo de compatibilidad.
Agradecimientos
Foto de portada de Mark Olsen en Unsplash.