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 sobre el cronograma.
- 7 de marzo de 2022: Se anunció la reversión después de que se descubrieran problemas en Chrome 98.
Introducción
Como parte de la especificación del Acceso a la red privada (PNA), Chrome dejará de estar disponible el acceso directo a extremos de red privada desde sitios web públicos.
Chrome comenzará a enviar una solicitud de comprobación previa de CORS antes de cualquier solicitud de red privada para un subrecurso, para lo cual se solicita 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 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 redireccionen a servidores maliciosos.
Plan de lanzamiento
Chrome lanzará este cambio en dos fases para darles tiempo a los sitios web para que noten el cambio y se ajusten en consecuencia.
En Chrome 104:
- Chrome realiza experimentos mediante el envío de solicitudes preliminares antes de las solicitudes de subrecursos de la red privada.
- Las fallas de solicitud preliminar solo muestran advertencias en Herramientas para desarrolladores, sin afectar de otra manera las solicitudes de la red privada.
- Chrome recopila datos de compatibilidad y se comunica con los sitios web más grandes afectados.
- Esperamos que esta función sea ampliamente compatible con los sitios web existentes.
En Chrome 113, como muy pronto:
- Esto comenzará solo cuando los datos de compatibilidad indiquen que el cambio es suficientemente seguro y nos comunicamos directamente cuando fuera necesario.
- Chrome exige que las solicitudes de comprobación previa se completen correctamente; de lo contrario, fallan.
- Una prueba de baja comienza al mismo tiempo 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 de redes privadas.
Chrome ya implementó parte de la especificación: a partir de Chrome 96, solo se permiten contextos seguros para realizar solicitudes de red privada. Consulta nuestra entrada de blog anterior para obtener más detalles.
La especificación también extiende el protocolo de uso compartido de recursos entre dominios (CORS) para que los sitios web ahora deben solicitar explícitamente un otorgamiento de servidores en redes privadas antes de poder enviar solicitudes arbitrarias.
¿Cómo clasifica 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 locales contiene direcciones IP que son direcciones de bucle invertido IPv4 (127.0.0.0/8) definidas en la sección 3.2.1.3 de RFC1122 o direcciones de bucle invertido de IPv6 (::1/128) definidas en la sección 2.5.3 de 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, direcciones de vínculo local 169.254.0.0/16 definidas en RFC3927, direcciones IPv6 de unidifusión locales únicas fc00::/7 definidas en RFC4193,
direcciones IPv6 con unidifusión RFC 6.fe80::/10RFC4291
El espacio de direcciones IP públicas contiene todas las demás direcciones no mencionadas anteriormente.
Una dirección IP local se considera más privada que una privada, que es más privada que una pública.
Obtén más información en Se desean obtener comentarios: CORS para redes privadas (RFC1918).
Solicitudes preliminares
Información general
Las solicitudes de comprobación previa son un mecanismo ingresado por 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 de CSRF.
La solicitud de permiso se envía como una solicitud HTTP OPTIONS con encabezados de solicitud CORS específicos que describen la próxima solicitud HTTP. La respuesta debe tener encabezados de respuesta de CORS específicos que acepten de forma explícita la próxima solicitud.
Novedades del Acceso a redes privadas
Se presenta un nuevo par de encabezados de solicitud y respuesta a las solicitudes de comprobación previa:
Access-Control-Request-Private-Network: trueestá configurado en todas las solicitudes de comprobación preliminar de PNA- Se debe configurar
Access-Control-Allow-Private-Network: trueen todas las respuestas de la solicitud preliminar de PNA
Las solicitudes de comprobación previa para PNA se envían para todas las solicitudes de red privada, independientemente del método y modo de la solicitud. Se envían antes que 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 de CSRF, sin importar el modo de solicitud y si el contenido de la respuesta está disponible o no para el iniciador.
Las solicitudes de comprobación previa de PNA también se envían para solicitudes del mismo origen, si la dirección IP de destino es más privada que el iniciador. Esto difiere del CORS normal, en el que las solicitudes de comprobación previa son solo para solicitudes de origen cruzado. Las solicitudes de comprobación previa para solicitudes del mismo origen protegen contra ataques de revinculación de DNS.
Ejemplos
El comportamiento observable depende del modo de la solicitud.
Modo sin CORS
Digamos que https://foo.example/index.html incorpora <img src="https://bar.example/cat.gif" alt="dancing cat"/> y que bar.example se resuelve en 192.168.1.1, una dirección IP privada según RFC 1918.
Chrome primero envía una solicitud preliminar:
HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true
Para que esta solicitud se procese correctamente, el servidor debe responder de la siguiente manera:
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 lo que el servidor puede responder normalmente
Modo 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.
Chrome primero envía una solicitud preliminar:
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 esta solicitud se procese correctamente, el servidor debe responder de la siguiente manera:
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 lo que el servidor puede responder según las reglas de CORS habituales:
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 de comprobación previa antes que ella. Si falla esta solicitud de comprobación previa, se seguirá enviando la solicitud final, pero se mostrará una advertencia en el panel de problemas de Herramientas para desarrolladores.
Las solicitudes de comprobación previa afectadas también se pueden ver y diagnosticar en el panel de red:
Si tu solicitud hubiera activado una solicitud preliminar de CORS normal sin reglas de acceso a la red privada, es posible que aparezcan dos comprobaciones preliminares en el panel de red, y la primera parece haber fallado siempre. Este es un error conocido y puedes ignorarlo sin problemas.
Para revisar lo que sucede si se aplicó éxito de la solicitud preliminar, puedes pasar el siguiente argumento de línea de comandos a partir de Chrome 98:
--enable-features=PrivateNetworkAccessRespectPreflightResults
Cualquier solicitud preliminar errónea generará una recuperación con errores. Esto puede permitirte 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 en los paneles de Herramientas para desarrolladores mencionados anteriormente.
Qué hacer si tu sitio web se ve afectado
Cuando se lanza este cambio en Chrome 104, no se espera que rompa ningún sitio web. Sin embargo, te recomendamos que actualices las rutas de solicitud afectadas para asegurarte de que el sitio web siga funcionando como se espera.
Hay dos soluciones disponibles:
- Controla las solicitudes de comprobación previa en el servidor
- Inhabilita las comprobaciones de PNA con políticas empresariales
Cómo controlar las solicitudes preliminares del servidor
Actualiza el servidor de destino de cualquier recuperación afectada para controlar las solicitudes de comprobació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 para los dos encabezados de respuesta nuevos.
Cuando el servidor recibe una solicitud de comprobación previa (una solicitud OPTIONS con encabezados de CORS), el servidor 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 de permitir.
Por lo general, debes permitir el acceso a un solo origen bajo tu control.
Una vez que tu servidor decida permitir la solicitud, debe responder 204 No Content (o 200 OK) con los encabezados de CORS necesarios y el nuevo encabezado de 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 de situaciones concretas.
Inhabilitar las verificaciones de acceso a la red privada mediante políticas empresariales
Si tienes control de administrador sobre tus usuarios, puedes inhabilitar las verificaciones de acceso a la red privada mediante 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, el equipo de Chrome estará interesado en tus comentarios y casos de uso.
Informa un problema con Chromium en crbug.com para informarnos al respecto y configura el componente en Blink>SecurityFeature>CORS>PrivateNetworkAccess.
Próximos pasos
A continuación, Chrome extenderá las verificaciones de acceso a la red privada para abarcar a los trabajadores web: trabajadores dedicados, trabajadores compartidos y service worker. Nuestro objetivo tentativamente 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. Nuestro objetivo tentativamente es que Chrome 108 comience a mostrar advertencias.
En ambos casos, procederemos cautelosamente con un lanzamiento por fases similar a fin de que los desarrolladores web tengan tiempo para ajustar y estimar el riesgo de compatibilidad.
Agradecimientos
Foto de portada de Mark Olsen en Unsplash.