Aislamiento del sitio

El aislamiento de sitios es una función de seguridad del navegador que agrupa los sitios web en procesos aislados según su origen . Esta técnica permite que el entorno aislado bloquee los ataques de omisión entre orígenes 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 trabajaba de forma independiente en su implementación en el navegador de investigación Gazelle al mismo tiempo. Inicialmente, el enfoque no logró consolidarse debido al gran esfuerzo de ingeniería necesario para implementarlo en un navegador completo y a las preocupaciones sobre el impacto en el rendimiento real del uso potencialmente ilimitado de procesos. En 2018, tras el descubrimiento público de las vulnerabilidades Spectre y Meltdown , Google aceleró el trabajo, culminando 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 las ventajas de seguridad que ofrece esta función, también presenta limitaciones e inconvenientes. Si bien proporciona una protección básica contra ataques de canal lateral como Spectre y Meltdown , la protección total contra estos ataques requiere que los desarrolladores habiliten explícitamente ciertas protecciones avanzadas del navegador. El principal inconveniente del aislamiento de sitios web radica en el mayor consumo de recursos que implican los procesos adicionales. Esto limita su eficacia en algunos tipos de dispositivos y, en ciertos casos, puede utilizarse indebidamente para realizar ataques de agotamiento de recursos .

Hasta 2017, la arquitectura de seguridad predominante de los principales navegadores se basaba en el modelo de un proceso por instancia de navegación. Esto implicaba que el navegador constaba de distintos procesos aislados , incluyendo el proceso del navegador, el proceso de la GPU, el proceso de red y el proceso de renderizado. El proceso de renderizado interactuaba con otros servicios privilegiados cuando era necesario para ejecutar acciones elevadas al visualizar una página web. ^{[ 1 ] [ 2 ]}

Aunque este modelo logró prevenir los problemas asociados con el acceso de JavaScript malicioso al sistema operativo, carecía de la capacidad de aislar adecuadamente los sitios web entre sí. ^{[ 3 ]} A pesar de estas preocupaciones, la adopción de un modelo más robusto tuvo una acogida limitada debido a los problemas percibidos con los modelos más recientes, particularmente aquellos relacionados con el rendimiento y la memoria. ^{[ 4 ] [ 5 ]}

En 2017, la revelación de las vulnerabilidades Spectre y Meltdown alteró este panorama. Anteriormente, acceder a memoria arbitraria era complicado, ya que 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 sensible de páginas de origen cruzado renderizadas previamente. ^{[ 6 ] [ 7 ]} 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. ^{[ 8 ] [ 7 ]}

En 2009, Reis et al. propusieron la primera versión del modelo de proceso por sitio para aislar páginas web según su origen web. ^{[ 9 ]} Este modelo fue mejorado en 2009 por el navegador de investigación Gazelle , que separaba marcos de documentos específicos según su principal web, una barrera de seguridad que correspondía al documento específico que se estaba cargando. ^{[ 10 ] [ 11 ]} Casi al mismo tiempo, también se trabajaba en los navegadores OP (que más tarde se convertiría en el navegador OP2), IBOS, Tahoma y SubOS, todos los cuales proponían diferentes paradigmas para resolver el problema de la separación de procesos entre sitios. ^{[ 12 ] [ 13 ]}

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 implementar código para i-frames fuera de proceso (OOPIF). ^{[ 14 ]} Posteriormente, en enero de 2015, se celebró una Cumbre de Aislamiento de Sitios en BlinkOn, donde se presentó al equipo de ocho ingenieros y se describió la motivación, los objetivos, la arquitectura, el cronograma propuesto y el progreso realizado hasta el momento. La presentación también incluyó una demostración de Chrome ejecutándose con un prototipo inicial de aislamiento de sitios. ^{[ 15 ]}

En 2019, Reis y otros del proyecto Google Chrome presentaron un documento en USENIX Security ^{[ 16 ]} que detallaba cambios en su modelo de seguridad de navegador existente en respuesta a la investigación reciente que demostraba que el ataque Spectre podía usarse dentro del proceso de renderizado del navegador. ^{[ 17 ] [ 18 ]} El documento proponía cambios en el modelo que se basaban en el trabajo de Reis y otros en 2009. ^{[ 19 ]} La implementación de Chrome del aislamiento de sitios 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 de los sitios web se ejecutaran fuera del proceso, una característica que había sido sugerida por los autores del navegador web Gazelle , así como de los navegadores web OP y OP2. ^{[ 12 ]} Esto requirió una reingeniería significativa del código de manejo de procesos de Chrome, involucrando más de 4000 confirmaciones de 320 colaboradores durante un período de 5 años. ^{[ 22 ]}

La implementación del aislamiento de sitios de Chrome le permitió eliminar múltiples ataques de secuencias de comandos entre sitios universales (uXSS). ^{[ 23 ]} Los ataques uXSS permiten a los atacantes comprometer la política del mismo origen , otorgando acceso sin restricciones para inyectar y cargar código JavaScript controlado por el atacante en otros sitios web. ^{[ 24 ]} El equipo de Chrome descubrió que los 94 ataques uXSS reportados entre 2014 y 2018 serían neutralizados mediante la implementación del aislamiento de sitios. ^{[ 25 ]} Además, el equipo de Chrome también afirmó que su implementación del aislamiento de sitios sería eficaz para prevenir variaciones del grupo de ataques de temporizació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 función de aislamiento de sitios. Esta función había estado en desarrollo durante varios meses bajo el nombre en clave Proyecto Fission. ^{[ 26 ]} La implementación de Firefox corrigió algunas de las fallas que se habían encontrado en la implementación de Chrome, principalmente el hecho de que páginas web similares aún eran 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 ^{[ 5 ]} debido a un aumento en la cantidad de espacio de memoria ocupado por los procesos. ^{[ 30 ]} Esta sobrecarga de rendimiento también se reflejó en implementaciones reales. ^{[ 31 ]} La implementación de aislamiento de sitios de Chrome, en promedio, requería de uno a dos núcleos más que la misma implementación sin aislamiento de sitios. ^{[ 5 ]} Además, los ingenieros que trabajaban en el proyecto de aislamiento de sitios observaron un aumento del 10 al 13 por ciento en el uso de memoria cuando se utilizaba 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 ataques uXSS y de ejecución transitoria . ^{[ 34 ]} Para ello, superaron múltiples obstáculos de rendimiento y compatibilidad, y al hacerlo, impulsaron un esfuerzo a nivel de la industria para mejorar la seguridad de los navegadores . Sin embargo, a pesar de esto, se ha descubierto que ciertos aspectos de las defensas de Spectre son deficientes. ^{[ 6 ]} En particular, se ha descubierto que la capacidad del aislamiento de sitios para defenderse contra ataques de temporización es incompleta. ^{[ 35 ]} En 2021, Agarwal et al. lograron desarrollar un exploit llamado Spook.js que pudo romper las defensas Spectre de Chrome y exfiltrar datos a través de páginas web en diferentes orígenes. ^{[ 36 ]} En el mismo año, investigadores de Microsoft lograron aprovechar el aislamiento de sitios para realizar una variedad de ataques de temporización que les permitieron filtrar información de origen cruzado mediante la manipulación cuidadosa de los protocolos de comunicación entre procesos empleados por el aislamiento de sitios. ^{[ 37 ]}

En 2023, investigadores de la Universidad Ruhr de 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 ]}