Tecnologías como WebAssembly (WASM), WebGPU e IndexedDB han transformado lo que los navegadores pueden lograr. Esta evolución ha expandido la funcionalidad de los navegadores. Sin embargo, esta mayor complejidad también trae una preocupación significativa de ciberseguridad: una superficie de ataque ampliada.
Para entender dónde estamos hoy, hagamos un viaje por el camino de la memoria.
¿Recuerdas cuando necesitabas Flash Player para ver contenido multimedia enriquecido en sitios web? Adobe Flash fue revolucionario para su época, permitiendo animaciones, juegos y aplicaciones interactivas. Pero también era notorio por sus vulnerabilidades de seguridad y actualizaciones frecuentes.
Por ejemplo, en 2015, la filtración de la controvertida empresa Hacking Team reveló múltiples vulnerabilidades de día cero en Flash Player que fueron utilizadas para atacar usuarios en todo el mundo. Estos exploits permitieron a los atacantes ejecutar código arbitrario en las máquinas de los usuarios, lo que llevó a posibles robos de datos, instalación de malware y más. El advenimiento de HTML5 y JavaScript marcó el comienzo del fin para Flash, proporcionando formas más seguras y versátiles de crear contenido web interactivo.
Los applets de Java también estaban plagados de vulnerabilidades de seguridad. Una brecha significativa ocurrió en 2012, cuando se descubrió una vulnerabilidad de día cero en Java SE 7 y fue rápidamente explotada en la naturaleza. Este exploit permitió a los atacantes eludir las restricciones de seguridad y ejecutar código arbitrario en los sistemas afectados, lo que llevó a infecciones generalizadas de malware. El engorroso proceso de actualización y el auge de tecnologías web más seguras y eficientes como HTML5, CSS3 y frameworks modernos de JavaScript llevaron al declive gradual de los applets de Java.
Microsoft Silverlight es otro ejemplo de 2016. La vulnerabilidad CVE-2016-0034 en Silverlight, encontrada a través de datos filtrados de Hacking Team. Este exploit de día cero, comercializado por un hacker ruso, podía eludir las protecciones en IE y Firefox.
Un ejemplo final proviene de Adobe en 2012, donde se descubrió un exploit capaz de comprometer la seguridad de los ordenadores que ejecutaban Adobe X y XI (Adobe Reader 10 y 11). Esta vulnerabilidad permitió a los atacantes eludir la protección de sandbox de Reader.
Esta es una historia tan antigua como el tiempo. Con el nuevo progreso, llegan nuevos problemas.
Nuevas vulnerabilidades del navegador:
WASM (WebAssembly)
WASM permite que aplicaciones de alto rendimiento se ejecuten en el navegador, habilitando tareas como el renderizado 3D y cálculos complejos. Esto es genial para crear aplicaciones web más interactivas y visualmente atractivas.
Sin embargo, en 2018, investigadores demostraron cómo WebAssembly podía usarse para crear malware de cryptojacking muy eficiente que minaba criptomonedas usando los recursos de CPU de la víctima.
Un ejemplo es cuando el script CoinHive, que mina criptomonedas, fue insertado en el servicio BrowseAloud. Esto causó que el script se ejecutara en los ordenadores de miles de visitantes sin su conocimiento. Debido a WebAssembly, el script operaba de manera fluida y secreta, usando los dispositivos de los visitantes para minar criptomonedas.
En 2021, se encontró otra vulnerabilidad en WASM. Permitía un desbordamiento de pila al manipular el seguimiento del tamaño de la pila en el Low-Level Interpreter (LLInt). Al diseñar una función de WebAssembly para realizar numerosas operaciones push, se inducía un desbordamiento de enteros, lo que llevaba a la ejecución remota de código. Este exploit, demostrado en Pwn2Own 2021, aprovechaba fugas de memoria y una cadena de Return-Oriented Programming (ROP) para lograr la ejecución arbitraria de código. El problema se parcheó en Safari 14.1.1 (CVE-2021-30734).
WebGPU
WebGPU ofrece características gráficas de alto nivel. Permite a los desarrolladores aprovechar la potencia de la GPU directamente desde el navegador. Esto es genial para crear aplicaciones gráficas detalladas y juegos directamente en el navegador.
Esto, de nuevo, abrió un nuevo camino para los ataques. En 2022, ocurrió una vulnerabilidad cuando una página web especialmente diseñada desencadenaba una condición de use-after-free, permitiendo potencialmente a un atacante ejecutar código arbitrario. Cisco Talos se coordinó con Google para asegurar que el problema se parcheara en las versiones de Chrome 102.0.4956.0 y 99.0.4844.82.
En abril de 2024, científicos de la Universidad de Graz y la Universidad de Rennes demostraron que WebGPU podía ser atacado. Llenaron la caché con su propio código usando JavaScript y WebGPU y luego observaron cuándo sus datos eran eliminados de la caché al introducirse. Este método les permitió analizar pulsaciones de teclas de forma rápida y precisa. También pudieron obtener claves usadas para el cifrado AES basado en GPU. Este ataque incluso podía enviar datos en secreto a velocidades de hasta 10 Kb/s.
IndexedDB
IndexedDB es una API de bajo nivel para almacenar grandes cantidades de datos estructurados, que permite crear aplicaciones offline complejas. Esta tecnología soporta aplicaciones web avanzadas que necesitan funcionar sin conexión, como las aplicaciones web progresivas (PWA).
Pero de nuevo, la mayor capacidad de almacenamiento de datos también significa que más datos sensibles podrían estar en riesgo.
Por ejemplo, en 2022, una vulnerabilidad en la implementación de IndexedDB de Safari 15 permitió a cualquier sitio web rastrear la actividad de internet de un usuario y revelar potencialmente su identidad. El problema surgió por el incumplimiento de una regla. La regla dice que los nombres de las bases de datos deben mantenerse separados, pero se compartían entre distintos sitios web, permitiendo a estos sitios ver qué otros sitios se habían visitado en la misma sesión del navegador.
Apple solucionó el problema en una semana con las actualizaciones de macOS Monterey 12.2 e iOS 15.3.
¿Puede cside protegerte en estos casos?
En cside, protegemos tus sitios frente a scripts de terceros dañinos o comprometidos. Al colocar nuestro script por encima de todos los demás, los hacemos pasar por nuestro motor de detección y filtramos de forma autónoma cualquier problema potencial. Obtienes visibilidad completa de lo que hace el código, incluidas las amenazas potenciales. Además, a menudo optimizamos los scripts para que se ejecuten más rápido.
Pero, ¿podemos ayudar frente a los casos mencionados anteriormente?
Los sistemas de detección requieren actualizaciones continuas para identificar variaciones completamente nuevas o métodos para ocultar información. Conservamos el código solicitado, así que dispones de los datos necesarios para determinar qué salió mal, tanto si detectamos el problema como si no.
Así es como te protegemos hoy de los ataques mencionados anteriormente:
WASM (WebAssembly): cside supervisa y controla la ejecución de scripts de terceros. La monitorización específica de WASM está en la hoja de ruta para añadirse más adelante y se está convirtiendo en una superficie de ataque cada vez más peligrosa.
WebGPU: podemos rastrear y analizar el comportamiento de los scripts y el uso de recursos, incluidos los patrones de acceso a la GPU, para detectar anomalías indicativas de ataques de canal lateral. Al identificar actividad sospechosa antes de que el navegador renderice el script, cside puede bloquear o marcar scripts potencialmente maliciosos antes de que puedan explotar, también, los recursos de GPU.
IndexedDB: monitorizamos el código completo, lo que incluye cualquier llamada a APIs sensibles como IndexedDB.
Otras buenas prácticas:
- Actualizaciones periódicas: mantén todas las herramientas instaladas al día para asegurarte de tener los últimos parches de seguridad. Elimina cualquier script que no uses.
- Firewalls de aplicaciones web (WAF): implementa WAF para añadir una capa extra de seguridad, protegiendo las aplicaciones web frente a una variedad de ataques.
- Educa a los usuarios: si es posible, forma a los usuarios sobre los riesgos del phishing y los ataques de ingeniería social, que pueden comprometer la seguridad.
- Reduce los scripts de terceros: mantén solo los que necesites, y ten un plan claro sobre a qué páginas puede acceder cada script.
- Emplea autenticación multifactor (MFA): usa MFA para añadir una capa extra de seguridad a las cuentas de usuarios y administradores, dificultando el acceso no autorizado.
- Política de seguridad de contenido (CSP): implementa CSP para prevenir ataques de cross-site scripting (XSS) controlando qué recursos puede cargar el navegador. Recuerda que las CSP tienen por sí solas algunas limitaciones importantes, sobre las que escribimos más [aquí](https://cside.com/compare#:~:text=Detecting%20Scripts-,Content%20Security%20Policies%20(CSP%29,-JS%20Based).
¿Cómo será el futuro del navegador?
Los navegadores seguirán evolucionando. Se podría argumentar medio en broma que todo se está convirtiendo en un navegador, dada la tendencia de las aplicaciones móviles a transformarse en Progressive Web Apps (actualmente estamos preparando un artículo detallado sobre este tema). Las PWA serán cada vez más fluidas, ofreciendo una experiencia similar a la de una app nativa en todos los dispositivos. Además, la mayor integración de la IA y las mejoras en privacidad e identidad online seguirán transformando nuestros navegadores.
Mejoramos continuamente nuestros servicios y motores de detección para cubrir un área más amplia del espacio de seguridad del lado del cliente.
Puedes empezar y proteger tu(s) sitio(s) gratis, y actualizar para acceder a más funciones cuando quieras. Puedes seguir nuestro registro de cambios para ver las actualizaciones y lo que viene a continuación.
Si quieres hablar con nuestro equipo de soporte sobre cualquier problema o duda concreta, puedes hacerlo aquí.
