Aislamiento de sitio

El aislamiento de sitios es una característica de ciertos navegadores web que permite aislar sitios de origen cruzado entre sí. La característica fue propuesta originalmente por Reis et al. en 2009, con iteraciones posteriores de Microsoft, en la forma de implementación de la función en el navegador de investigación Gazelle. Sin embargo, la función no logró ganar terreno debido a problemas relacionados con su implementación y problemas de rendimiento.

En 2018, tras la publicación de las vulnerabilidades Spectre y Meltdown al público, Google comenzó a trabajar para agregar aislamiento de sitios en Chrome, lo que finalmente 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 con el nombre en clave Project Fission.

A pesar de los beneficios de seguridad de esta función, los investigadores también han encontrado problemas de seguridad en torno a varios aspectos de esta función. Estos incluyen problemas con la protección percibida contra ataques transitorios como Spectre y Meltdown, así como nuevos ataques de sincronización y agotamiento de recursos habilitados por esta característica.

Antecedentes editar

Hasta 2017, la arquitectura de seguridad predominante de los principales navegadores se adhería al modelo de proceso por instancia. Esto implicaba que el navegador comprendiera distintos procesos de espacio aislado, incluido el proceso del navegador, el proceso de GPU, el proceso de red y el proceso de renderizado. El proceso de representación singular se conectaría con otros servicios privilegiados cuando fuera necesario para ejecutar acciones elevadas al visualizar una página web.[1][2]

Aunque este modelo evitó con éxito 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 enfrentó una tracción limitada debido a problemas percibidos con los modelos más nuevos, particularmente aquellos relacionados con el rendimiento y la memoria.[2][4]

Sin embargo, en 2017, la divulgación de los exploits de Spectre y Meltdown alteró este panorama. Si bien anteriormente el acceso a la memoria restringida era un proceso relativamente complicado que requería un renderizador comprometido, la vulnerabilidad de Spectre hizo que fuera mucho más fácil acceder a la memoria arbitraria. Esto expuso los problemas del modelo de seguridad de proceso por instancia, ya que al usar JavaScript, el sitio web podía 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 previamente renderizadas. En consecuencia, se requería una nueva arquitectura de seguridad que permitiera separar la representación de diferentes páginas web en procesos completamente aislados.[5][6]

Historia editar

A lo largo de los años, se han propuesto múltiples versiones de la arquitectura de aislamiento del sitio. En 2009, Reis et al. propuso 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.[1]​ Posteriormente, esto fue mejorado 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 con el documento específico que se estaba cargando.[7]​ Casi al mismo tiempo, también se estaba trabajando en el OP (que más tarde se convertiría en el navegador OP2), IBOS, Tahoma y el navegador SubOS, todos los cuales proponían diferentes paradigmas para resolver el problema de la separación de procesos entre sitios.[2][8]

Implementación moderna editar

En 2019, Google Chrome publicó un documento de conferencia en USENIX Security 2019 que detallaba los cambios en su modelo de seguridad de navegador existente en respuesta a una investigación reciente que demuestra que el ataque Spectre podría usarse dentro del proceso de renderizado del navegador. El artículo propuso cambios al modelo que se basaron en gran medida en el trabajo de Reis et al. en 2009. La implementación de Chrome del aislamiento de sitios utilizaría los orígenes web como principal diferenciador de un «sitio» a nivel de proceso.[9][10]​ Además, el equipo de Chrome también implementó la idea de que los marcos de los sitios web se ejecuten fuera de proceso, una característica sugerida por el navegador web Gazelle, así como por los navegadores web OP y OP2. Esto requirió una importante reingeniería del código de manejo de procesos de Chrome, lo que requirió más de 4000 confirmaciones durante un período de 5 años por parte de 320 contribuyentes.[8]

La implementación del aislamiento de sitios por parte de Chrome les permitió eliminar múltiples ataques universales de secuencias de comandos entre sitios (uXSS), lo que permitió a los atacantes comprometer la política del mismo origen. El equipo de Chrome descubrió que los 94 ataques uXSS reportados entre 2014 y 2018 quedarían ineficaces si se implementara el aislamiento del sitio.[11][12]​ Además de esto, el equipo de Chrome también afirmó que su implementación del aislamiento del sitio sería eficaz para prevenir diversas 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.[8]

En marzo de 2021, Firefox anunció que también implementaría el aislamiento de sitios. Esta característica había estado en desarrollo durante varios meses bajo el nombre en clave Proyecto Fisión.[13]​ La implementación de Firefox repitió algunas de las fallas que se habían encontrado en la implementación de Chrome, es decir, el hecho de que páginas web similares aún eran vulnerables a los ataques uXSS.[11][14]​ Al igual que en Chrome, el proyecto también requirió una reescritura del código de manejo del proceso en Firefox.[15]

Recepción editar

Históricamente, el aislamiento de sitios sólo lo han implementado los navegadores de investigación. Esto se debió a que se consideró que el enfoque consumía muchos recursos y memoria debido al aumento en la cantidad de espacio de memoria ocupado por los procesos.[4][16]​ Esto también se reflejó en las implementaciones del mundo real.[17]​ La implementación del aislamiento del sitio por parte de Chrome requirió en promedio uno o dos núcleos más que lo mismo sin el aislamiento del sitio.[4]​ Además, los ingenieros que trabajaron en el proyecto de aislamiento del sitio observaron un aumento del 10 al 13 por ciento en el uso de la memoria cuando se utilizó el aislamiento del sitio.[1][18]

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. 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, el aislamiento del sitio no se considera una solución milagrosa. En particular, se ha descubierto que la capacidad del aislamiento del sitio para defenderse contra ataques de sincronización es incompleta.[19]​ En 2021, Agarwal et al. Pudieron desarrollar un exploit llamado Spook.js que fue capaz de romper las defensas Spectre de Chrome y filtrar datos a través de páginas web en diferentes orígenes.[20]​ Ese mismo año, los investigadores de Microsoft pudieron aprovechar el aislamiento del sitio para realizar una variedad de ataques de sincronizació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 del sitio.[19]

En 2023, investigadores de la Universidad del Ruhr de Bochum demostraron que podían aprovechar la arquitectura de proceso requerida por el aislamiento del sitio para agotar los recursos del sistema y también realizar ataques avanzados como el envenenamiento de DNS.[21]

Referencias editar

  1. a b c Reis, Charles; Gribble, Steven D. (April 2009). «Isolating web programs in modern browser architectures». Proceedings of the 4th ACM European conference on Computer systems (en inglés). ACM. pp. 219-232. ISBN 978-1-60558-482-9. doi:10.1145/1519065.1519090. Consultado el 24 de diciembre de 2023. 
  2. a b c Dong, Xinshu; Hu, Hong; Saxena, Prateek; Liang, Zhenkai (2013). Crampton, Jason; Jajodia, Sushil, eds. A Quantitative Evaluation of Privilege Separation in Web Browser Designs. Lecture Notes in Computer Science (en inglés). Berlin, Heidelberg: Springer. pp. 75-93. ISBN 978-3-642-40203-6. doi:10.1007/978-3-642-40203-6_5. Consultado el 29 de diciembre de 2023. 
  3. Jia, Yaoqi; Chua, Zheng Leong; Hu, Hong; Chen, Shuo; Saxena, Prateek; Liang, Zhenkai (24 de octubre de 2016). «"The Web/Local" Boundary is Fuzzy: A Security Study of Chrome's Process-based Sandboxing». Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. CCS '16. New York, NY, USA: Association for Computing Machinery. pp. 791-804. ISBN 978-1-4503-4139-4. doi:10.1145/2976749.2978414. 
  4. a b c Zhu, Yongye; Wei, Shijia; Tiwari, Mohit (2022). «Revisiting Browser Performance Benchmarking From an Architectural Perspective». IEEE Computer Architecture Letters 21 (2): 113-116. doi:10.1109/LCA.2022.3210483. Archivado desde el original el 30 de julio de 2023. Consultado el 24 de diciembre de 2023. 
  5. Rogowski, Roman; Morton, Micah; Li, Forrest; Monrose, Fabian; Snow, Kevin Z.; Polychronakis, Michalis (2017). «Revisiting Browser Security in the Modern Era: New Data-Only Attacks and Defenses». 2017 IEEE European Symposium on Security and Privacy (EuroS&P). pp. 366-381. ISBN 978-1-5090-5762-7. doi:10.1109/EuroSP.2017.39. Consultado el 24 de diciembre de 2023. 
  6. «A Spectre proof-of-concept for a Spectre-proof web». Google Online Security Blog (en inglés). Archivado desde el original el 24 de diciembre de 2023. Consultado el 24 de diciembre de 2023. 
  7. Wang, Helen; Grier, Chris; Moshchuk, Alexander; King, Samuel T.; Choudhury, Piali; Venter, Herman; King, Sam (19 de febrero de 2009). «The Multi-Principal OS Construction of the Gazelle Web Browser». SSYM'09: Proceedings of the 18th Conference on USENIX Security Symposium (en inglés estadounidense). Archivado desde el original el 4 de septiembre de 2023. Consultado el 29 de diciembre de 2023. 
  8. a b c Reis, Charles; Moshchuk, Alexander; Oskov, Nasko (2019). Site Isolation: Process Separation for Web Sites within the Browser (en inglés). pp. 1661-1678. ISBN 978-1-939133-06-9. Consultado el 24 de diciembre de 2023. 
  9. Bishop, Douglas L. (2021). Improvements of User's Security and Privacy in a Web Browser (Tesis) (en inglés). Universidad de Dayton. Archivado desde el original el 24 de diciembre de 2023. Consultado el 24 de diciembre de 2023. 
  10. Rokicki, Thomas; Maurice, Clémentine; Laperdrix, Pierre (2021). «SoK: In Search of Lost Time: A Review of JavaScript Timers in Browsers». 2021 IEEE European Symposium on Security and Privacy (EuroS&P). pp. 472-486. ISBN 978-1-6654-1491-3. doi:10.1109/EuroSP51992.2021.00039. Consultado el 24 de diciembre de 2023. 
  11. a b Kokatsu, Jun (10 de noviembre de 2020). «Deep Dive into Site Isolation (Part 1)». Microsoft Browser Vulnerability Research (en inglés). Archivado desde el original el 24 de diciembre de 2023. Consultado el 24 de diciembre de 2023. 
  12. Kim, Young Min; Lee, Byoungyoung (2023). Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions (en inglés). pp. 7055-7071. ISBN 978-1-939133-37-3. Consultado el 24 de diciembre de 2023. 
  13. «Firefox to get a 'site isolation' feature, similar to Chrome». ZDNET (en inglés). Archivado desde el original el 29 de diciembre de 2023. Consultado el 29 de diciembre de 2023. 
  14. Narayan, Shravan; Disselkoen, Craig; Garfinkel, Tal; Froyd, Nathan; Rahm, Eric; Lerner, Sorin; Shacham, Hovav; Stefan, Deian (2020). Retrofitting Fine Grain Isolation in the Firefox Renderer (en inglés). pp. 699-716. ISBN 978-1-939133-17-5. Consultado el 24 de diciembre de 2023. 
  15. «NIKA:\fission-news-1\>». mystor.github.io. Archivado desde el original el 29 de diciembre de 2023. Consultado el 30 de diciembre de 2023. 
  16. Reis, Charles; Gribble, Steven D. (1 de abril de 2009). «Isolating web programs in modern browser architectures». Proceedings of the 4th ACM European conference on Computer systems. EuroSys '09. New York, NY, USA: Association for Computing Machinery. pp. 219-232. ISBN 978-1-60558-482-9. doi:10.1145/1519065.1519090. 
  17. Wang, Helen; Grier, Chris; Moshchuk, Alexander; King, Samuel T.; Choudhury, Piali; Venter, Herman; King, Sam (19 de febrero de 2009). «The Multi-Principal OS Construction of the Gazelle Web Browser». USENIX Security Symposium '09 (en inglés estadounidense). Archivado desde el original el 4 de septiembre de 2023. Consultado el 29 de diciembre de 2023. 
  18. Warren, Tom (12 de julio de 2018). «Chrome now uses more RAM because of Spectre security fixes». The Verge (en inglés). Archivado desde el original el 25 de octubre de 2022. Consultado el 30 de diciembre de 2023. 
  19. a b Jin, Zihao; Kong, Ziqiao; Chen, Shuo; Duan, Haixin (2022). «Timing-Based Browsing Privacy Vulnerabilities Via Site Isolation». 2022 IEEE Symposium on Security and Privacy (SP). pp. 1525-1539. ISBN 978-1-6654-1316-9. doi:10.1109/SP46214.2022.9833710. Consultado el 24 de diciembre de 2023. 
  20. Agarwal, Ayush; o'Connell, Sioli; Kim, Jason; Yehezkel, Shaked; Genkin, Daniel; Ronen, Eyal; Yarom, Yuval (2022). «Spook.js: Attacking Chrome Strict Site Isolation via Speculative Execution». 2022 IEEE Symposium on Security and Privacy (SP). pp. 699-715. ISBN 978-1-6654-1316-9. doi:10.1109/SP46214.2022.9833711. Consultado el 24 de diciembre de 2023. 
  21. Gierlings, Matthias; Brinkmann, Marcus; Schwenk, Jörg (2023). Isolated and Exhausted: Attacking Operating Systems via Site Isolation in the Browser (en inglés). pp. 7037-7054. ISBN 978-1-939133-37-3. Consultado el 24 de diciembre de 2023.