Aislamiento de sitios para desarrolladores web

Mathias Bynens

Chrome 67 para computadoras de escritorio tiene una nueva función llamada aislamiento de sitios habilitada de forma predeterminada. Esta En este artículo, se explica en qué consiste el aislamiento de sitios, por qué es necesario y por qué los desarrolladores web ten en cuenta.

¿Qué es el aislamiento de sitios?

Internet se usa para mirar videos de gatos y administrar monederos de criptomonedas, entre otras cosas. pero no te gustaría que fluffycats.example tuviera acceso a tus preciadas criptomonedas. Por suerte, los sitios web no pueden acceder a los datos entre sí dentro del navegador gracias al Same-Origin Política. Aun así, los sitios web maliciosos pueden intentar evadir esta política para atacar a otros sitios web. ocasionalmente se encuentran errores de seguridad en el código del navegador que aplica la política del mismo origen. El El equipo de Chrome tiene como objetivo corregir estos errores lo más rápido posible.

El aislamiento de sitios es una función de seguridad de Chrome que ofrece una línea de defensa adicional para es menos probable que tales ataques tengan éxito. Garantiza que siempre se coloquen páginas de diferentes sitios web en procesos diferentes; cada uno se ejecuta en una zona de pruebas que limita lo que el proceso puede hacer. También impide que el proceso reciba ciertos tipos de datos sensibles de otros sitios. Como resultado, con el aislamiento de sitios es mucho más difícil para un sitio web malicioso usar ataques de canal lateral, como Spectre, para robar datos de otros sitios. Cuando el equipo de Chrome termina aplicaciones de seguridad adicionales, el aislamiento de sitios también será útil, incluso cuando la página de un atacante pueda dañar algunos de las reglas en su propio proceso.

El aislamiento de sitios dificulta eficazmente que los sitios web que no son de confianza accedan a información o la roben. desde tus cuentas en otros sitios web. Ofrece protección adicional contra varios tipos de errores de seguridad, como los recientes ataques de canal lateral de Meltdown y Spectre.

Para obtener más detalles sobre el aislamiento de sitios, consulte nuestro artículo del blog de seguridad de Google.

Bloqueo de lectura de origen cruzado

Aunque todas las páginas entre sitios se ubiquen en procesos separados, las páginas pueden solicitar legítimamente algunos subrecursos entre sitios, como imágenes y JavaScript. Una página web maliciosa podría usar un <img> para cargar un archivo JSON con datos sensibles, como tu saldo bancario:

<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->

Sin el aislamiento de sitios, el contenido del archivo JSON llegaría a la memoria del procesador. y, en ese momento, el renderizador nota que no es un formato de imagen válido y no se renderiza una imagen. Sin embargo, el atacante podría entonces aprovechar una vulnerabilidad como Spectre para leer esa información fragmento de memoria.

En lugar de usar <img>, el atacante también podría usar <script> para confirmar los datos sensibles en memoria:

<script src="https://your-bank.example/balance.json"></script>

El bloqueo de lectura de origen cruzado, o CORB, es una nueva función de seguridad que impide que los contenidos de balance.json nunca ingrese a la memoria de la memoria de proceso del renderizador en función de su tipo de MIME.

Analicemos cómo funciona CORB. Un sitio web puede solicitar dos tipos de recursos de un servidor:

1. recursos de datos, como documentos HTML, XML o JSON
2. Recursos multimedia como imágenes, JavaScript, CSS o fuentes

Un sitio web puede recibir recursos de datos de su propio origen o de otros orígenes con encabezados CORS permisivos, como Access-Control-Allow-Origin: * Por otro lado, los recursos de medios pueden incluirse desde cualquier incluso sin encabezados permisivos de CORS.

CORB impide que el proceso del renderizador reciba un recurso de datos de origen cruzado (es decir, HTML, XML o JSON) si:

• el recurso tiene un encabezado X-Content-Type-Options: nosniff
• CORS no permite el acceso al recurso de forma explícita

Si el recurso de datos de origen cruzado no tiene configurado el encabezado X-Content-Type-Options: nosniff, CORB intenta hacer un análisis del cuerpo de la respuesta para determinar si es HTML, XML o JSON. Este es necesario porque algunos servidores web están mal configurados y entregan imágenes, por ejemplo, como text/html.

Los recursos de datos que bloquea la política de CORB se presentan al proceso como vacíos, aunque la solicitud aún se realiza en segundo plano. Como resultado, una página web maliciosa tiene dificultades extraer datos entre sitios en su proceso para robarlos.

Para obtener una seguridad óptima y aprovechar el CORB, te recomendamos lo siguiente:

• Marca las respuestas con el encabezado Content-Type correcto. (Por ejemplo, los recursos HTML deben ser se entrega como text/html, recursos JSON con un tipo de MIME JSON y recursos XML con un tipo de MIME XML).
• Utiliza el encabezado X-Content-Type-Options: nosniff para inhabilitar los análisis. Sin este encabezado, Chrome hace un análisis rápido de contenido para confirmar que el tipo sea correcto, pero como este opta por permitir las respuestas para evitar bloquear elementos como los archivos JavaScript, es mejor que hagas afirmativamente lo correcto por tu cuenta.

Para obtener más información, consulta la Artículo de CORB para desarrolladores web o nuestra explicación detallada de CORB.

¿Por qué el aislamiento de sitios es importante para los desarrolladores web?

En general, el aislamiento de sitios es una función del navegador detrás de escena que no está a los desarrolladores web. Por ejemplo, no hay una nueva API expuesta en la Web para aprender. En general, la Web las páginas no deberían poder distinguir la diferencia cuando se ejecutan con o sin el aislamiento de sitios.

Sin embargo, hay algunas excepciones a esta regla. Habilitar el aislamiento de sitios implica algunas y tienen efectos secundarios que podrían afectar su sitio web. Mantenemos una lista de problemas conocidos de aislamiento de sitios y detallaremos los más importantes a continuación.

El diseño de página completa ya no es síncrono

Con el aislamiento de sitios, ya no se garantiza que el diseño de página completa sea síncrono, ya que los marcos de una página ahora puede estar repartida en varios procesos. Esto podría afectar las páginas si suponen que un el cambio de diseño se propaga de inmediato a todos los marcos de la página.

A modo de ejemplo, consideremos un sitio web llamado fluffykittens.example que se comunica con una widget de redes sociales alojado en social-widget.example:

<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
  const iframe = document.querySelector('iframe');
  iframe.width = 456;
  iframe.contentWindow.postMessage(
    // The message to send:
    'Meow!',
    // The target origin:
    'https://social-widget.example'
  );
</script>

Primero, el ancho del <iframe> del widget de redes sociales es de 123 píxeles. Pero luego, la página de FluffyKittens Cambia el ancho a 456 píxeles (diseño de activación) y envía un mensaje al widget de redes sociales. que tiene el siguiente código:

<!-- https://social-widget.example/ -->
<script>
  self.onmessage = () => {
    console.log(document.documentElement.clientWidth);
  };
</script>

Cada vez que el widget de redes sociales recibe un mensaje a través de la API de postMessage, registra el ancho de su elemento raíz <html>.

¿Qué valor de ancho se registra? Antes de que Chrome habilitara el aislamiento de sitios, la respuesta era 456. Acceso document.documentElement.clientWidth fuerza el diseño, que antes era síncrono antes de Chrome habilitado el aislamiento de sitios. Sin embargo, con el aislamiento de sitios habilitado, el widget de redes sociales de origen cruzado el rediseño ahora ocurre de forma asíncrona en un proceso independiente. Ahora la respuesta también puede ser 123, es decir, el valor anterior de width.

Si una página cambia el tamaño de un <iframe> de origen cruzado y, luego, le envía un objeto postMessage con Aislamiento de sitios: es posible que el marco receptor aún no sepa su nuevo tamaño al recibir el mensaje. Más pero, por lo general, esto podría generar fallas en las páginas si suponen que un cambio de diseño se propaga de inmediato a todos o marcos en la página.

En este ejemplo en particular, una solución más sólida establecería el elemento width en el marco superior. detectar ese cambio en el <iframe> escuchando un evento resize.

Es posible que el tiempo de espera de los controladores de descarga se agote con más frecuencia

Cuando un marco navega o se cierra, el documento antiguo y los documentos de submarco incorporados en él todos ejecutan su controlador unload. Si la navegación nueva ocurre en el mismo proceso del renderizador (p.ej., para una navegación del mismo origen), se pueden ejecutar los controladores unload del documento anterior y sus submarcos mucho tiempo antes de permitir que se confirme la navegación nueva.

addEventListener('unload', () => {
  doSomethingThatMightTakeALongTime();
});

En este caso, los controladores unload en todos los marcos son muy confiables.

Sin embargo, incluso sin el aislamiento del sitio, algunas navegaciones del marco principal son procesos cruzados, lo que afecta y descargar el comportamiento del controlador. Por ejemplo, si navegas de old.example a new.example escribiendo la URL en la barra de direcciones, la navegación de new.example se realiza en un proceso nuevo. La descarga los controladores para old.example y sus submarcos se ejecutan en el proceso old.example en segundo plano. después de que se muestra la página new.example y los controladores de descarga anteriores se finalizan si no lo hacen finalizan en un tiempo de espera determinado. Debido a que es posible que los controladores de descarga no finalicen antes del tiempo de espera, el comportamiento de descarga es menos confiable.

Con el aislamiento de sitios, todas las navegaciones entre sitios pasan a ser procesos cruzados, de modo que los documentos de sitios diferentes no comparten un proceso entre sí. Como resultado, la situación anterior se aplica en más casos, y los controladores de descarga en <iframe> suelen tener comportamientos en segundo plano y de tiempo de espera. descrita anteriormente.

Otra diferencia que resulta del aislamiento de sitios es el nuevo orden paralelo de los controladores de descarga: sin Aislamiento de sitios, los controladores de descarga se ejecutan en un orden descendente estricto en todos los marcos. Sin embargo, con Sites Los controladores de descarga y aislamiento se ejecutan en paralelo en diferentes procesos.

Estas son consecuencias fundamentales de habilitar el aislamiento de sitios. El equipo de Chrome está trabajando en lo que mejora la confiabilidad de los controladores de descarga para casos de uso comunes, cuando sea posible. También estamos de los errores en los que los controladores de descarga de submarcos aún no pueden usar ciertas funciones trabajando para resolverlos.

Un caso importante para los controladores de descarga es enviar pings al final de la sesión. Por lo general, esto se hace como sigue:

addEventListener('pagehide', () => {
  const image = new Image();
  img.src = '/end-of-session';
});

Un mejor enfoque y más sólido ante este cambio es usar navigator.sendBeacon. en su lugar:

addEventListener('pagehide', () => {
  navigator.sendBeacon('/end-of-session');
});

Si necesitas más control sobre la solicitud, puedes usar la opción keepalive de la API de Fetch:

addEventListener('pagehide', () => {
  fetch('/end-of-session', {keepalive: true});
});

Conclusión

El aislamiento de sitios dificulta que los sitios web que no son de confianza accedan a tu información o la roben. en otros sitios web al aislar cada sitio en su propio proceso. Como parte de eso, CORB intenta para mantener los recursos de datos sensibles fuera del proceso del renderizador. Nuestras recomendaciones anteriores garantizan que puedas aprovechar al máximo estas nuevas funciones de seguridad.

Gracias a Alex Moshchuk: Charlie Reis, Jason Miller: Nasko Oskov Philip Walton, Shubhie Panicker y Tomás Steiner para leer una versión del borrador de este artículo y dar sus comentarios.