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
Chrome dará de baja el acceso directo a los extremos de red privada de los públicos sitios web como parte del Acceso a redes privadas (PNA) especificación.
Chrome comenzará a enviar una solicitud preliminar de CORS antes de cualquier solicitud de red privada para un subrecurso, que solicita
para obtener permisos explícitos del servidor de destino. Esta solicitud preliminar
tienen un nuevo encabezado, Access-Control-Request-Private-Network: true, y el
debe llevar el encabezado correspondiente,
Access-Control-Allow-Private-Network: true
El objetivo es proteger a los usuarios de los ataques de falsificación de solicitudes entre sitios (CSRF). orientar a routers y otros dispositivos en redes privadas. Estos ataques han afectado a cientos de miles de usuarios, lo que permite que los atacantes los redireccionen a servidores maliciosos.
Plan de lanzamiento
Chrome lanzará este cambio en dos fases para que los sitios web tengan tiempo para notar el cambio y realizar los ajustes necesarios.
En Chrome 104:
- Chrome experimenta con el envío de solicitudes preliminares antes de la red privada solicitudes de subrecursos.
- Las fallas de solicitud preliminar solo muestran advertencias en Herramientas para desarrolladores, sin lo contrario que afectan las solicitudes de red privada.
- Chrome recopila datos de compatibilidad y se comunica con las principales sitios web.
- Esperamos que esta función sea ampliamente compatible con los sitios web existentes.
Como muy pronto en Chrome 113, ocurre lo siguiente:
- Este comenzará solo si los datos de compatibilidad indican que el el cambio es lo suficientemente seguro, y nos contactamos directamente cuando es necesario.
- Chrome exige que las solicitudes preliminares se completen correctamente; de lo contrario, fallarán. las solicitudes.
- Una prueba de baja comienza en para permitir que los sitios web afectados por esta fase soliciten extensión de tiempo. La prueba durará al menos 6 meses.
¿Qué es el acceso a redes privadas (PNA)?
Acceso a redes privadas (anteriormente conocido como CORS-RFC1918) restringe la capacidad de los sitios web de enviar solicitudes a servidores privados redes.
Chrome ya implementó parte de la especificación: a partir de Chrome 96, solo los contextos seguros tienen permitido realizar solicitudes de red privada. Consulta nuestra entrada de blog anterior para obtener más detalles.
La especificación también extiende el uso compartido de recursos entre dominios (CORS) protocolo para que los sitios web deban solicitar explícitamente un otorgamiento a los servidores en redes privadas antes de que se les permita enviar solicitudes arbitrarias.
¿Cómo PNA clasifica las direcciones IP e 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 IPv4
Direcciones de bucle invertido (127.0.0.0/8) definidas en la sección 3.2.1.3 de RFC1122
o direcciones IPv6 de bucle invertido (::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 definido en RFC1918,
las direcciones de vínculo local 169.254.0.0/16 definidas en RFC3927.
direcciones IPv6 unicast locales únicas fc00::/7 definidas en RFC4193,
Direcciones IPv6 de unidifusión IPv6 de vínculo local fe80::/10 definidas en la sección 2.5.6 de RFC4291
y las direcciones IPv6 asignadas con 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, se considera más privada que una dirección IP pública.
Obtén más información en Feedback solicitados: CORS para redes privadas (RFC1918).
Solicitudes preliminares
Información general
Las solicitudes preliminares son un mecanismo que introduce el estándar de uso compartido de recursos entre dominios (CORS) que se usa solicitar permiso a un sitio web objetivo antes de enviarle una solicitud HTTP que pueden tener efectos secundarios. Esto garantiza que el servidor de destino entienda 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 CORS específicos.
para describir la próxima solicitud HTTP. La respuesta debe llevar encabezados de respuesta de CORS específicos
aceptando explícitamente la próxima solicitud.
Novedades de Acceso a redes privadas
Se presenta un nuevo par de encabezados de solicitud y respuesta a las solicitudes con verificación previa:
- Se establece
Access-Control-Request-Private-Network: trueen todas las solicitudes preliminares de PNA - Se debe establecer
Access-Control-Allow-Private-Network: trueen todas las respuestas preliminares de PNA
Las solicitudes preliminares de PNA se envían para todas las solicitudes de red privada
independientemente del método de solicitud y
mode. Se envían
antes que en las solicitudes en el modo cors, así como en no-cors y en todos los demás modos. Esta
es que todas las solicitudes de red privada
pueden utilizarse para ataques CSRF,
independientemente del modo de solicitud y si el contenido de la respuesta se hace o no
disponibles para el iniciador.
Las solicitudes preliminares de PNA también se envían para las solicitudes del mismo origen, si la la dirección IP de destino es más privada que la del iniciador. No se parece a lo normal CORS, en el que las solicitudes de comprobación previa son solo para solicitudes de origen cruzado. Preliminar las solicitudes de solicitudes del mismo origen protegen contra Ataques de revinculación de DNS.
Ejemplos
El comportamiento observable depende del modo de solicitud.
Modo sin CORS
Di https://foo.example/index.html incorporaciones
<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
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 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 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 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 la cual 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 crea la solicitud se enviará antes. Si esta solicitud preliminar falla, se enviará una solicitud, pero aparecerá una advertencia en las Herramientas para desarrolladores de problemas.
Las solicitudes preliminares afectadas también se pueden ver y diagnosticar en el panel de red:
Si tu solicitud hubiera activado una solicitud preliminar normal de CORS sin Acceso a redes privadas, pueden aparecer dos solicitudes preliminares de red, y el primero parece haber fallado. Este es un error conocido y puedes ignorarlo sin problemas.
Para revisar qué sucede si se aplicó de manera forzosa la solicitud preliminar correcta, puedes pasa el siguiente argumento de línea de comandos, a partir de Chrome 98:
--enable-features=PrivateNetworkAccessRespectPreflightResults
Cualquier solicitud de comprobación previa con errores dará como resultado una recuperación con errores. Esto puede permitirte para probar si tu sitio web funcionaría después del la segunda fase de nuestro plan de implementación. Los errores se pueden diagnosticar de la misma manera que las advertencias con los paneles de Herramientas para desarrolladores mencionados anteriormente.
Qué hacer si su sitio web se ve afectado
Cuando se lance este cambio en Chrome 104, no se espera que dañe sitio web. Sin embargo, te recomendamos que actualices las rutas de las solicitudes afectadas a para garantizar que tu sitio web funcione como se espera.
Hay dos soluciones disponibles para ti:
- Controla las solicitudes preliminares del servidor
- Inhabilitar verificaciones de PNA con políticas empresariales
Controla las solicitudes preliminares del servidor
Actualiza el servidor de destino de cualquier recuperación afectada para controlar la comprobación previa de PNA solicitudes. Primero, implementa la compatibilidad con las solicitudes preliminares de CORS estándar en las rutas afectadas. Luego, agrega compatibilidad para los dos encabezados de respuesta nuevos.
Cuando tu servidor recibe una solicitud de comprobación previa (una solicitud OPTIONS con CORS)
encabezados), el servidor debe comprobar la presencia de un
Encabezado Access-Control-Request-Private-Network: true. Si este encabezado es
presente en la solicitud, el servidor debe examinar el encabezado Origin y el
la ruta de la solicitud junto con cualquier otra información relevante (como
Access-Control-Request-Headers) para garantizar que se pueda permitir la solicitud con seguridad.
Por lo general, debes permitir el acceso a un único origen bajo tu control.
Una vez que tu servidor decida permitir la solicitud, debería responder
204 No Content (o 200 OK) con los encabezados de CORS necesarios y el nuevo PNA
encabezado. Estos encabezados incluyen Access-Control-Allow-Origin y
Access-Control-Allow-Private-Network: true y otras que sean necesarias.
Consulta los ejemplos para ver situaciones concretas.
Inhabilitar las verificaciones de Acceso a redes privadas mediante políticas empresariales
Si tienes control de administrador sobre tus usuarios, puedes inhabilitar El acceso a la red realiza verificaciones mediante cualquiera de las siguientes políticas:
Para obtener más información, consulta Comprende 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.
Comunícate con nosotros informando un problema con Chromium en crbug.com y, luego, establece
el componente a Blink>SecurityFeature>CORS>PrivateNetworkAccess.
¿Qué sigue?
A continuación, Chrome extenderá las verificaciones de Acceso a redes privadas para Trabajadores web: trabajadores dedicados, trabajadores compartidos y service workers. Nuestro objetivo es pronosticar para que Chrome 107 empiece a mostrar advertencias.
Luego, Chrome extenderá las verificaciones de Acceso a redes privadas para cubrir las navegaciones, incluidos iframes y emergentes. Nuestro objetivo es comenzar la versión 108 de Chrome mostrando advertencias.
En ambos casos, procederemos con cautela con un lanzamiento en etapas similar, con el fin de dar tiempo a los desarrolladores web para ajustar y estimar el riesgo de compatibilidad.
Agradecimientos
Foto de portada de Mark Olsen en Retiro: