Chrome 67 para computadoras tiene una nueva función llamada Aislamiento de sitios habilitada de forma predeterminada. En este artículo, se explica de qué se trata el aislamiento de sitios, por qué es necesario y por qué los desarrolladores web deben tenerlo en cuenta.
¿Qué es el aislamiento de sitios?
Internet sirve para mirar videos de gatos y administrar billeteras de criptomonedas, entre otras cosas,
pero no quieres que fluffycats.example tenga acceso a tus valiosas criptomonedas. Afortunadamente, los sitios web no suelen poder acceder a los datos de los demás dentro del navegador gracias a la política del mismo origen. Aun así, los sitios web maliciosos pueden intentar eludir esta política para atacar a otros sitios web y, en ocasiones, se encuentran errores de seguridad en el código del navegador que aplica la Política del mismo origen. El equipo de Chrome intenta 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 reducir las probabilidades de que los ataques tengan éxito. Garantiza que las páginas de los diferentes sitios web se ubiquen siempre en procesos diferentes, cada uno de los cuales se ejecute en una zona de pruebas que limite las acciones que este proceso puede realizar. También bloquea el proceso para que no reciba ciertos tipos de datos sensibles de otros sitios. En consecuencia, con el aislamiento de sitios es mucho más difícil que un sitio web malicioso use ataques especulativos de canal lateral, como Spectre, para robar datos de otros sitios. A medida que el equipo de Chrome termine de aplicar más políticas, el aislamiento de sitios también será útil cuando la página de un atacante pueda infringir algunas de las reglas en su propio proceso.
El aislamiento de sitios efectivamente dificulta que sitios web que no sean de confianza accedan a información de tus cuentas en otros sitios web o la roben. Ofrece protección adicional contra varios tipos de errores de seguridad, como los ataques recientes de canal lateral Meltdown y Spectre.
Para obtener más información sobre el aislamiento de sitios, consulta nuestro artículo en el Blog de seguridad de Google.
Bloqueo de lectura de origen cruzado
Incluso cuando todas las páginas de varios sitios se colocan en procesos separados, las páginas pueden solicitar de forma legítima algunos subrecursos entre sitios, como imágenes y JavaScript. Una página web maliciosa podría usar un
elemento <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 proceso del procesador, momento en el cual el procesador nota que no es un formato de imagen válido y no renderiza una imagen. Sin embargo, el atacante podría explotar una vulnerabilidad como Spectre para poder leer ese fragmento de memoria.
En lugar de usar <img>, el atacante también podría usar <script> para confirmar los datos sensibles en la 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 evita que el contenido de balance.json ingrese a la memoria de la memoria del proceso del procesador 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:
- recursos de datos, como documentos HTML, XML o JSON
- 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 multimedia se pueden incluir desde cualquier origen, incluso sin encabezados de CORS permisivos.
CORB evita que el proceso del procesador reciba un recurso de datos de origen cruzado (es decir, HTML, XML o JSON) en los siguientes casos:
- el recurso tiene un encabezado
X-Content-Type-Options: nosniff - CORS no permite explícitamente el acceso al recurso
Si el recurso de datos de origen cruzado no tiene configurado el encabezado X-Content-Type-Options: nosniff,
CORB intentará realizar un análisis del cuerpo de la respuesta para determinar si es HTML, XML o JSON. Esto es necesario porque algunos servidores web están mal configurados y entregan imágenes como text/html, por ejemplo.
Los recursos de datos que bloquea la política de CORB se presentan al proceso como vacíos, aunque la solicitud aún ocurre en segundo plano. Como resultado, a una página web maliciosa le resulta difícil extraer datos de varios sitios para robarlos.
Para una seguridad óptima y los beneficios de CORB, recomendamos lo siguiente:
- Marca las respuestas con el encabezado
Content-Typecorrecto. (Por ejemplo, los recursos HTML se deben entregar comotext/html, los recursos JSON con un tipo de MIME JSON y los recursos XML con un tipo de MIME de XML). - Inhabilita el rastreo usando el encabezado
X-Content-Type-Options: nosniff. Sin este encabezado, Chrome hace un análisis de contenido rápido para intentar confirmar que el tipo sea correcto, pero como se opta por permitir respuestas para evitar el bloqueo de elementos como los archivos JavaScript, es mejor que hagas lo correcto de forma afirmativa.
Para obtener más detalles, consulta el artículo sobre CORB para desarrolladores web o nuestra explicación detallada sobre CORB.
¿Por qué debería importar el aislamiento de sitios a los desarrolladores web?
En general, el aislamiento de sitios es una función del navegador en segundo plano que no está expuesta directamente a los desarrolladores web. No hay una nueva API expuesta en la Web que aprender, por ejemplo. En general, las páginas web no deberían poder notar la diferencia cuando se ejecutan con o sin aislamiento de sitios.
Sin embargo, hay algunas excepciones a esta regla. La habilitación del aislamiento de sitios implica algunos efectos secundarios sutiles que podrían afectar tu sitio web. Mantenemos una lista de problemas conocidos de aislamiento de sitios y, a continuación, explicamos los más importantes.
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 pueden distribuirse entre varios procesos. Es posible que esto afecte a las páginas si suponen que un cambio en el diseño se propaga de inmediato a todos los marcos de la página.
Como ejemplo, consideremos un sitio web llamado fluffykittens.example que se comunica con un widget social 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>
Al principio, el ancho del <iframe> del widget de redes sociales es de 123 píxeles. Sin embargo, la página de FluffyKittens cambia el ancho a 456 píxeles (activando el diseño) 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 mediante la API de postMessage, registra el ancho de su elemento <html> raíz.
¿Qué valor de ancho se registra? Antes de que Chrome habilitara el aislamiento de sitios, la respuesta era 456. El acceso a document.documentElement.clientWidth fuerza el diseño, que solía ser síncrono antes de que Chrome habilitara el aislamiento de sitios. Sin embargo, con el aislamiento de sitios habilitado, el nuevo diseño del widget social de origen cruzado
ahora se realiza de forma asíncrona en un proceso independiente. Por lo tanto, la respuesta ahora también puede ser 123, es decir, el valor width anterior.
Si una página cambia el tamaño de un <iframe> de origen cruzado y, luego, le envía un elemento postMessage, con el aislamiento del sitio, es posible que el marco receptor aún no reconozca su tamaño nuevo cuando reciba el mensaje. En términos más generales, es posible que las páginas dejen de funcionar si se supone que un cambio de diseño se propaga de inmediato a todos los marcos de la página.
En este ejemplo particular, una solución más sólida establecería el width en el marco superior y detectaría ese cambio en <iframe> escuchando un evento resize.
Los controladores de descarga podrían agotar el tiempo de espera con más frecuencia
Cuando un marco navega o se cierra, el documento antiguo y los documentos de submarcos incorporados en él
ejecutan su controlador unload. Si la navegación nueva ocurre en el mismo proceso del procesador (p.ej., para una navegación del mismo origen), los controladores unload del documento anterior y sus submarcos pueden ejecutarse durante mucho tiempo antes de permitir que se confirme la navegación nueva.
addEventListener('unload', () => {
doSomethingThatMightTakeALongTime();
});
En esta situación, los controladores unload de todos los marcos son muy confiables.
Sin embargo, incluso sin el aislamiento de sitios, algunas navegaciones de marcos principales son procesos cruzados, lo que afecta el comportamiento del controlador de descargas. Por ejemplo, si escribes la URL en la barra de direcciones para navegar de old.example a new.example, la navegación de new.example se realizará en un proceso nuevo. Los controladores de descarga 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 finalizan dentro de 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 se convierten en un proceso cruzado, de modo que los documentos de diferentes sitios no compartan 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 los comportamientos en segundo plano y de tiempo de espera que se describieron anteriormente.
Otra diferencia que se genera con el aislamiento de sitios es el nuevo orden paralelo de los controladores de descarga: sin este aislamiento, los controladores de descarga se ejecutan en un orden descendente estricto entre los fotogramas. Sin embargo, con el aislamiento de sitios, los controladores de descarga se ejecutan en paralelo en diferentes procesos.
Estas son consecuencias fundamentales de habilitar el aislamiento de sitios. El equipo de Chrome está trabajando para mejorar la confiabilidad de los controladores de descarga en casos de uso comunes, cuando sea posible. También conocemos los errores en los que los controladores de descarga de submarcos aún no pueden usar ciertas funciones y estamos trabajando para resolverlos.
Un caso importante de los controladores de descarga es enviar pings de final de sesión. Por lo general, esto se hace de la siguiente manera:
addEventListener('pagehide', () => {
const image = new Image();
img.src = '/end-of-session';
});
Un enfoque mejor y más sólido a la luz de 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 sitios web que no sean de confianza accedan a información de tus cuentas en otros sitios web o la roben, ya que aísla cada sitio en su propio proceso. Como parte de eso, CORB intenta mantener los recursos de datos sensibles fuera del proceso del procesador. Nuestras recomendaciones anteriores garantizan que aproveches al máximo estas nuevas funciones de seguridad.
Gracias a Alex Moshchuk, Charlie Reis, Jason Miller, Nasko Oskov, Philip Walton, Shubhie Panicker y Thomas Steiner por leer una versión de borrador de este artículo y dar sus comentarios.