El aislamiento de sitios es una función de seguridad del navegador web que agrupa los sitios web en procesos aislados según sus orígenes asociados . Esta técnica permite que el proceso aislado bloquee los desvíos de origen cruzado que, de otro modo, quedarían expuestos por vulnerabilidades explotables en el proceso aislado.
La función fue propuesta públicamente por primera vez por Charles Reis y otros, aunque Microsoft estaba trabajando independientemente en su implementación en el navegador de investigación Gazelle al mismo tiempo. El enfoque inicialmente no logró ganar fuerza debido al gran esfuerzo de ingeniería requerido para implementarlo en un navegador con todas las funciones y a las preocupaciones sobre el impacto en el rendimiento del mundo real del uso de procesos potencialmente ilimitados.
En mayo de 2013, un miembro del equipo de aislamiento de sitios de Google Chrome anunció en la lista de correo chromium-dev que comenzarían a generar código para i-frames fuera de proceso (OOPIF). [1] A esto le siguió una cumbre de aislamiento de sitios en BlinkOn en enero de 2015, en la que se presentó al equipo de ocho ingenieros y se describieron la motivación, los objetivos, la arquitectura, el cronograma propuesto y el progreso logrado hasta el momento. La presentación también incluyó una demostración de Chrome ejecutándose con un prototipo inicial de aislamiento de sitios. [2]
En 2018, tras el descubrimiento de las vulnerabilidades Spectre y Meltdown , Google aceleró el trabajo, que culminó con el lanzamiento de la función en 2019. En 2021, Firefox también lanzó su propia versión de aislamiento de sitios en la que habían estado trabajando bajo el nombre en clave Project Fission .
A pesar de los beneficios de seguridad que ofrece esta función, tiene limitaciones y desventajas. Si bien proporciona una protección básica contra ataques de canal lateral como Spectre y Meltdown , la protección completa contra dichos ataques requiere que los desarrolladores habiliten explícitamente ciertas protecciones avanzadas del navegador.
La principal desventaja del aislamiento de sitios es el mayor consumo de recursos que requieren los procesos adicionales. Esto limita su eficacia en algunas clases de dispositivos y, en algunos casos, puede utilizarse de forma indebida para permitir ataques de agotamiento de recursos .
Hasta 2017, la arquitectura de seguridad predominante de los principales navegadores se ceñía al modelo de proceso por instancia de navegación. Esto implicaba que el navegador comprendía distintos procesos aislados , incluidos el proceso del navegador, el proceso de GPU, el proceso de red y el proceso de renderizado. El proceso de renderizado interactuaría con otros servicios privilegiados cuando fuera necesario para ejecutar acciones elevadas al visualizar una página web. [3] [4]
Aunque este modelo logró evitar con éxito los problemas asociados con el acceso de JavaScript malicioso al sistema operativo, carecía de la capacidad para aislar adecuadamente los sitios web entre sí. [5] A pesar de estas preocupaciones, la adopción de un modelo más sólido tuvo una tracción limitada debido a los problemas percibidos con los modelos más nuevos, en particular los relacionados con el rendimiento y la memoria. [6] [7]
Sin embargo, en 2017, la divulgación de los exploits Spectre y Meltdown alteró este panorama. Anteriormente, acceder a memoria arbitraria era complicado y requería un renderizador comprometido. Sin embargo, con Spectre, se desarrollaron ataques que abusaban de las características de Javascript para leer casi toda la memoria en el proceso de renderizado, incluida la memoria que almacena información potencialmente confidencial de páginas de origen cruzado renderizadas anteriormente. [8] [9] Esto expuso los problemas del modelo de seguridad de proceso por instancia. En consecuencia, se requirió una nueva arquitectura de seguridad que permitiera la separación del renderizado de diferentes páginas web en procesos completamente aislados. [10] [9]
En 2009, Reis et al. propusieron la primera versión del modelo de proceso por sitio para aislar páginas web en función del origen web de la página. [11] Esto fue mejorado en 2009 por el navegador de investigación Gazelle , que separaba marcos de documentos específicos en función de su principal web, una barrera de seguridad que se correspondía con el documento específico que se estaba cargando. [12] [13] Casi al mismo tiempo, también se estaba trabajando en el OP (que luego se convertiría en el navegador OP2), IBOS, Tahoma y los navegadores SubOS, todos los cuales propusieron diferentes paradigmas para resolver el problema de la separación de procesos entre sitios. [14] [15]
En 2019, Reis, et al del proyecto Google Chrome presentaron un documento en USENIX Security [16] que detallaba los cambios en su modelo de seguridad del navegador existente en respuesta a la investigación reciente que demuestra que el ataque Spectre podría usarse dentro del proceso de renderizado del navegador. [17] [18] El documento propuso cambios al modelo que tomó prestado del trabajo de Reis et al. en 2009. [19] La implementación del aislamiento del sitio de Chrome usaría los orígenes web como un diferenciador principal de un "sitio" a nivel de proceso. [20] [21] Además, el equipo de Chrome también implementó la idea de que los marcos del sitio web se ejecuten fuera del proceso, una característica que había sido sugerida por los autores del navegador web Gazelle , así como los navegadores web OP y OP2. [14] Esto requirió una reingeniería significativa del código de manejo de procesos de Chrome, que involucró a más de 4000 confirmaciones de 320 contribuyentes durante un período de 5 años. [22]
La implementación del aislamiento de sitios de Chrome le permitió eliminar múltiples ataques universales de secuencias de comandos entre sitios (uXSS). [23] Los ataques uXSS permiten a los atacantes comprometer la política del mismo origen , otorgando acceso sin restricciones para inyectar y cargar javascript controlado por el atacante en otro sitio web. [24] El equipo de Chrome descubrió que los 94 ataques uXSS informados entre 2014 y 2018 se volverían ineficaces con la implementación del aislamiento de sitios. [25] Además de esto, el equipo de Chrome también afirmó que su implementación del aislamiento de sitios sería efectiva para prevenir variaciones del grupo de ataques de sincronización Spectre y Meltdown que dependían de que el espacio de direcciones de la víctima estuviera en el mismo proceso que el proceso del atacante. [18]
En marzo de 2021, el equipo de desarrollo de Firefox anunció que también implementaría su sistema de aislamiento de sitios. Esta función había estado en desarrollo durante varios meses bajo el nombre en código Project Fission. [26] La implementación de Firefox solucionó algunas de las fallas que se habían encontrado en la implementación de Chrome, a saber, el hecho de que páginas web similares seguían siendo vulnerables a ataques uXSS. [27] [28] El proyecto también requirió una reescritura del código de manejo de procesos en Firefox. [29]
Antes de 2019, el aislamiento de sitios solo se había implementado en navegadores de investigación. Se consideraba que el aislamiento de sitios consumía muchos recursos [7] debido a un aumento en la cantidad de espacio de memoria que ocupaban los procesos. [30] Esta sobrecarga de rendimiento también se reflejó en las implementaciones del mundo real. [31] La implementación del aislamiento de sitios de Chrome, en promedio, tomó de uno a dos núcleos más que la misma implementación sin aislamiento de sitios. [7] Además, los ingenieros que trabajaron en el proyecto de aislamiento de sitios observaron un aumento del 10 al 13 por ciento en el uso de memoria cuando se utilizó el aislamiento de sitios. [32] [33]
Chrome fue el primer navegador web importante de la industria en adoptar el aislamiento de sitios como defensa contra uXSS y ataques de ejecución transitoria . [34] Para ello, superaron múltiples obstáculos de rendimiento y compatibilidad y, al hacerlo, iniciaron un esfuerzo en toda la industria para mejorar la seguridad del navegador . Sin embargo, a pesar de esto, se han encontrado ciertos aspectos de las defensas de Spectre deficientes. [8] En particular, se ha descubierto que la capacidad del aislamiento de sitios para defenderse de los ataques de sincronización es incompleta. [35] En 2021, Agarwal et al. pudieron desarrollar un exploit llamado Spook.js que pudo romper las defensas Spectre de Chrome y exfiltrar datos en páginas web en diferentes orígenes. [36] En el mismo año, los investigadores de Microsoft pudieron aprovechar el aislamiento de sitios para realizar una variedad de ataques de sincronización que les permitieron filtrar información de origen cruzado mediante una cuidadosa manipulación de los protocolos de comunicación entre procesos empleados por el aislamiento de sitios. [37]
En 2023, los investigadores de la Universidad del Ruhr en Bochum demostraron que podían aprovechar la arquitectura de procesos requerida por el aislamiento del sitio para agotar los recursos del sistema y también realizar ataques avanzados como el envenenamiento de DNS . [38]