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, evolucionando masivamente los casos de uso y las experiencias. 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 que era capaz de comprometer la seguridad de computadoras 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, vienen nuevos problemas.
Nuevas vulnerabilidades del navegador:
WASM (WebAssembly)
WASM permite que aplicaciones de alto rendimiento se ejecuten en el navegador, habilitando tareas como renderizado 3D y cálculos complejos. Esto es excelente para crear aplicaciones web más interactivas y visualmente atractivas.
Sin embargo, en 2018, investigadores demostraron cómo WebAssembly podría usarse para crear malware de cryptojacking altamente 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 las computadoras 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 crear una función WebAssembly para realizar numerosas operaciones push, se indujo un desbordamiento de enteros, lo que llevó a la ejecución remota de código. Este exploit, demostrado en Pwn2Own 2021, aprovechó fugas de memoria y una cadena de Return-Oriented Programming (ROP) para lograr la ejecución arbitraria de código. El problema fue parcheado 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 excelente para crear aplicaciones gráficas detalladas y juegos directamente en el navegador.
Esto nuevamente abrió un nuevo camino para ataques. En 2022, ocurrió una vulnerabilidad cuando una página web especialmente diseñada desencadenó una condición de use-after-free, permitiendo potencialmente a un atacante ejecutar código arbitrario. Cisco Talos coordinó con Google para asegurar que el problema fuera parcheado 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 mostraron que WebGPU podía ser atacado. Llenaron el caché con su propio código usando JavaScript y WebGPU y luego observaron cuándo sus datos eran eliminados del caché al ser ingresados. Este método les permitió analizar pulsaciones de teclas de manera rápida y precisa. También pudieron obtener claves usadas para el cifrado AES basado en GPU. Este ataque incluso podía enviar datos secretamente a velocidades de hasta 10 Kb/s.
IndexedDB
IndexedDB es una API de bajo nivel para almacenar grandes cantidades de datos estructurados, habilitando aplicaciones offline complejas. Esta tecnología soporta aplicaciones web avanzadas que necesitan funcionar sin conexión, como las aplicaciones web progresivas (PWAs).
Pero nuevamente, 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 potencialmente revelar su identidad. El problema surgió debido a una violación de reglas. La regla dice que los nombres de bases de datos deben mantenerse separados, pero fueron compartidos entre diferentes sitios web, permitiendo a estos sitios ver qué otros sitios fueron visitados en la misma sesión del navegador.
Apple abordó el problema en una semana en las actualizaciones de macOS Monterey 12.2 e iOS 15.3.
¿Puede cside protegerte en estos casos?
En cside, protegemos tus sitios contra scripts de terceros dañinos o comprometidos. Al colocar nuestro script por encima de todos los demás, los enviamos a través de nuestro motor de detección y filtramos autónomamente cualquier problema potencial. Obtienes visibilidad completa de lo que el código está haciendo, incluyendo amenazas potenciales. Además, a menudo optimizamos los scripts para que se ejecuten más rápido.
Pero, ¿podemos ayudar contra los casos mencionados anteriormente?
No hace falta decir que los sistemas de detección requieren actualizaciones continuas para identificar variaciones completamente nuevas o métodos de ocultar información. Es importante saber que preservamos el código solicitado, permitiéndonos proporcionarte los datos necesarios para determinar qué salió mal, independientemente de si identificamos el problema o no.
Dicho esto, así es como podemos protegerte hoy de los ataques mencionados anteriormente:
WASM (WebAssembly): cside monitorea y controla la ejecución de scripts de terceros. El monitoreo específico de WASM está en la hoja de ruta para ser agregado 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 scripts y el uso de recursos, incluyendo patrones de acceso a 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, incluyendo también recursos de GPU.
IndexedDB: monitoreamos el código completo, que incluye cualquier llamada a APIs sensibles como IndexedDB.
Otras mejores prácticas:
- Actualizaciones Regulares: Mantén todas las herramientas instaladas actualizadas para asegurar que tengas los últimos parches de seguridad. Elimina cualquier script no utilizado.
- Firewalls de Aplicaciones Web (WAF): Implementa WAFs para agregar una capa extra de seguridad, protegiendo las aplicaciones web de una variedad de ataques.
- Educar a los Usuarios: Si es posible, capacita a los usuarios sobre los riesgos de phishing y ataques de ingeniería social, que pueden llevar a una seguridad comprometida.
- Reducir scripts de terceros: solo importa aquellos que son cruciales y ten un plan claro sobre en qué páginas tales scripts deberían tener acceso.
- Emplear Autenticación Multifactor (MFA): Usa MFA para agregar una capa extra de seguridad a las cuentas de usuarios y administradores, haciendo más difícil el acceso no autorizado.
- Política de Seguridad de Contenido (CSP): Implementa CSP para prevenir ataques de cross-site scripting (XSS) controlando qué recursos el navegador tiene permitido cargar. Recuerda que los CSPs tienen algunas limitaciones significativas por sí solos, sobre lo cual escribimos más [aquí](https://cside.com/compare#:~:text=Detecting%20Scripts-,Content%20Security%20Policies%20(CSP%29,-JS%20Based).
¿Cómo se ve el futuro del navegador?
Los navegadores continuarán evolucionando. Uno podría argumentar medio en broma que todo se está convirtiendo en un navegador, dada la tendencia de las aplicaciones móviles transformándose en Aplicaciones Web Progresivas (Un artículo detallado sobre este tema está actualmente en progreso). Las PWAs se volverán más fluidas, ofreciendo una experiencia similar a una aplicación nativa en todos los dispositivos. También la mayor integración de IA y mejoras en privacidad e identidad en línea continuarán dando forma a nuestros navegadores.
Ten la seguridad de que estamos desarrollando para el futuro y estamos mejorando continuamente nuestros servicios y motores de detección para cubrir un área más grande del espacio de seguridad del lado del cliente.
Puedes comenzar y asegurar tu(s) sitio(s) gratis, actualizando para acceder a más funciones según lo desees. Puedes monitorear nuestro registro de cambios para ver actualizaciones y posibles desarrollos futuros.
Si deseas hablar con nuestro equipo de soporte sobre cualquier problema o inquietud específica, puedes hacerlo aquí.
