Des technologies comme WebAssembly (WASM), WebGPU et IndexedDB ont transformé ce que les navigateurs peuvent accomplir. Cette évolution a élargi les fonctionnalités des navigateurs, faisant massivement évoluer les cas d'usage et les expériences. Cependant, cette complexité accrue apporte également une préoccupation majeure en matière de cybersécurité : une surface d'attaque élargie.
Pour comprendre où nous en sommes aujourd'hui, faisons un voyage dans le passé.
Vous souvenez-vous de l'époque où vous aviez besoin de Flash Player pour visualiser du contenu multimédia riche sur les sites web ? Adobe Flash était révolutionnaire pour son époque, permettant des animations, des jeux et des applications interactives. Mais il était également tristement célèbre pour ses vulnérabilités de sécurité et ses mises à jour fréquentes.
Par exemple, en 2015, la fuite de la société controversée Hacking Team a révélé de multiples vulnérabilités zero-day dans Flash Player qui ont été utilisées pour cibler des utilisateurs à travers le monde. Ces exploits permettaient aux attaquants d'exécuter du code arbitraire sur les machines des utilisateurs, entraînant un vol potentiel de données, l'installation de logiciels malveillants, et plus encore. L'avènement de HTML5 et JavaScript a marqué le début de la fin pour Flash, offrant des moyens plus sûrs et polyvalents de créer du contenu web interactif.
Les applets Java étaient également criblées de vulnérabilités de sécurité. Une violation importante s'est produite en 2012, lorsqu'une vulnérabilité zero-day dans Java SE 7 a été découverte et rapidement exploitée dans la nature. Cet exploit permettait aux attaquants de contourner les restrictions de sécurité et d'exécuter du code arbitraire sur les systèmes affectés, entraînant des infections massives par des logiciels malveillants. Le processus de mise à jour fastidieux et l'essor de technologies web plus sûres et efficaces comme HTML5, CSS3 et les frameworks JavaScript modernes ont conduit au déclin progressif des applets Java.
Microsoft Silverlight est un autre exemple de 2016. La vulnérabilité CVE-2016-0034 dans Silverlight, trouvée via les données divulguées de Hacking Team. Cet exploit zero-day, échangé par un hacker russe, pouvait contourner les protections dans IE et Firefox.
Un dernier exemple provient d'Adobe en 2012, où un exploit a été découvert qui était capable de compromettre la sécurité des ordinateurs exécutant Adobe X et XI (Adobe Reader 10 et 11). Cette vulnérabilité permettait aux attaquants de contourner la protection sandbox de Reader.
C'est une histoire aussi vieille que le monde. Avec les nouveaux progrès viennent de nouveaux problèmes.
Nouvelles vulnérabilités des navigateurs :
WASM (WebAssembly)
WASM permet aux applications haute performance de s'exécuter dans le navigateur, permettant des tâches comme le rendu 3D et des calculs complexes. C'est excellent pour créer des applications web plus interactives et visuellement attrayantes.
Cependant, en 2018, des chercheurs ont démontré comment WebAssembly pouvait être utilisé pour créer des logiciels malveillants de cryptojacking hautement efficaces qui minaient de la cryptomonnaie en utilisant les ressources CPU de la victime.
Un exemple est lorsque le script CoinHive, qui mine de la cryptomonnaie, a été inséré dans le service BrowseAloud. Cela a fait que le script s'exécutait sur les ordinateurs de milliers de visiteurs à leur insu. Grâce à WebAssembly, le script fonctionnait de manière fluide et secrète, utilisant les appareils des visiteurs pour miner de la cryptomonnaie.
En 2021, une autre vulnérabilité dans WASM a été trouvée. Elle permettait un débordement de pile en manipulant le suivi de la taille de la pile dans le Low-Level Interpreter (LLInt). En créant une fonction WebAssembly pour effectuer de nombreuses opérations push, un débordement d'entier a été induit, conduisant à l'exécution de code à distance. Cet exploit, démontré au Pwn2Own 2021, a exploité des fuites de mémoire et une chaîne Return-Oriented Programming (ROP) pour réaliser l'exécution de code arbitraire. Le problème a été corrigé dans Safari 14.1.1 (CVE-2021-30734).
WebGPU
WebGPU offre des fonctionnalités graphiques de haut niveau. Il permet aux développeurs d'exploiter la puissance du GPU directement depuis le navigateur. C'est excellent pour créer des applications graphiques détaillées et des jeux directement dans le navigateur.
Cela a de nouveau ouvert une nouvelle voie pour les attaques. En 2022, une vulnérabilité s'est produite lorsqu'une page web spécialement conçue a déclenché une condition use-after-free, permettant potentiellement à un attaquant d'exécuter du code arbitraire. Cisco Talos s'est coordonné avec Google pour s'assurer que le problème était corrigé dans les versions Chrome 102.0.4956.0 et 99.0.4844.82.
En avril 2024, des scientifiques de l'Université de Graz et de l'Université de Rennes ont montré que WebGPU pouvait être attaqué. Ils ont rempli le cache avec leur propre code en utilisant JavaScript et WebGPU et ils ont ensuite observé quand leurs données étaient supprimées du cache en étant saisies. Cette méthode leur a permis d'analyser rapidement et avec précision les frappes au clavier. Ils pouvaient également obtenir des clés utilisées pour le chiffrement AES basé sur GPU. Cette attaque pouvait même envoyer secrètement des données à des vitesses allant jusqu'à 10 Kb/s.
IndexedDB
IndexedDB est une API de bas niveau pour stocker de grandes quantités de données structurées, permettant des applications hors ligne complexes. Cette technologie prend en charge des applications web avancées qui doivent fonctionner hors ligne, telles que les applications web progressives (PWA).
Mais encore une fois, la capacité de stockage de données accrue signifie également que davantage de données sensibles pourraient être à risque.
Par exemple, en 2022, une vulnérabilité dans l'implémentation IndexedDB de Safari 15 permettait à n'importe quel site web de suivre l'activité internet d'un utilisateur et potentiellement révéler son identité. Le problème est survenu à cause d'une violation de règle. La règle dit que les noms de base de données doivent être gardés séparés, mais ils étaient partagés entre différents sites web, permettant à ces sites web de voir quels autres sites étaient visités dans la même session de navigateur.
Apple a résolu le problème en une semaine dans les mises à jour macOS Monterey 12.2 et iOS 15.3.
cside peut-il vous protéger dans ces cas ?
Chez cside, nous protégeons vos sites contre les scripts tiers nuisibles ou compromis. En plaçant notre script au-dessus de tous les autres, nous les proxyfions à travers notre moteur de détection et filtrons automatiquement tout problème potentiel. Vous obtenez une visibilité complète sur ce que fait le code, y compris les menaces potentielles. De plus, nous optimisons souvent les scripts pour qu'ils s'exécutent plus rapidement.
Mais pouvons-nous aider contre les cas mentionnés ci-dessus ?
Il va sans dire que les systèmes de détection nécessitent des mises à jour continues pour identifier des variations ou des méthodes de dissimulation d'informations entièrement nouvelles. Il est important de savoir que nous préservons le code demandé, nous permettant de vous fournir les données nécessaires pour déterminer ce qui s'est mal passé, que nous ayons identifié le problème ou non.
Cela dit, voici comment nous pouvons vous protéger aujourd'hui contre les attaques mentionnées ci-dessus :
WASM (WebAssembly) : cside surveille et contrôle l'exécution des scripts tiers. La surveillance spécifique à WASM est sur la feuille de route pour être ajoutée plus tard et devient une surface d'attaque de plus en plus dangereuse.
WebGPU : nous pouvons suivre et analyser le comportement des scripts et l'utilisation des ressources, y compris les modèles d'accès GPU, pour détecter les anomalies indicatives d'attaques par canal auxiliaire. En identifiant l'activité suspecte avant que le navigateur ne rende le script, cside peut bloquer ou signaler les scripts potentiellement malveillants avant qu'ils ne puissent exploiter, y compris les ressources GPU.
IndexedDB : nous surveillons le code complet, qui inclut tous les appels aux API sensibles comme IndexedDB.
Autres meilleures pratiques :
- Mises à jour régulières : Maintenez tous les outils installés à jour pour vous assurer d'avoir les derniers correctifs de sécurité. Supprimez tous les scripts inutilisés.
- Pare-feu d'applications web (WAF) : Implémentez des WAF pour ajouter une couche de sécurité supplémentaire, protégeant les applications web contre une variété d'attaques.
- Éduquez les utilisateurs : Si possible, formez les utilisateurs sur les risques d'attaques de phishing et d'ingénierie sociale, qui peuvent conduire à une sécurité compromise.
- Réduisez les scripts tiers : n'importez que ceux qui sont cruciaux et ayez un plan clair sur les pages auxquelles ces scripts devraient avoir accès.
- Employez l'authentification multi-facteurs (MFA) : Utilisez la MFA pour ajouter une couche de sécurité supplémentaire aux comptes utilisateurs et administrateurs, rendant l'accès non autorisé plus difficile.
- Politique de sécurité du contenu (CSP) : Implémentez une CSP pour prévenir les attaques de cross-site scripting (XSS) en contrôlant quelles ressources le navigateur est autorisé à charger. Rappelez-vous que les CSP ont certaines limitations importantes en elles-mêmes, sur lesquelles nous avons écrit plus en détail [ici](https://cside.com/compare#:~:text=Detecting%20Scripts-,Content%20Security%20Policies%20(CSP%29,-JS%20Based).
À quoi ressemble l'avenir du navigateur ?
Les navigateurs continueront d'évoluer. On pourrait dire en plaisantant à moitié que tout se transforme en navigateur, étant donné la tendance des applications mobiles à se transformer en applications web progressives (Un article détaillé sur ce sujet est actuellement en cours). Les PWA deviendront plus transparentes, offrant une expérience semblable à une application native sur tous les appareils. De plus, l'intégration accrue de l'IA et les améliorations en matière de confidentialité et d'identité en ligne continueront de façonner nos navigateurs.
Soyez assuré que nous développons pour l'avenir et améliorons continuellement nos services et moteurs de détection pour couvrir une plus grande zone de l'espace de sécurité côté client.
Vous pouvez commencer et sécuriser votre/vos site(s) gratuitement, en passant à une version supérieure pour accéder à plus de fonctionnalités selon vos besoins. Vous pouvez surveiller notre journal des modifications pour voir les mises à jour et les développements futurs potentiels.
Si vous souhaitez parler à notre équipe de support d'un problème ou d'une préoccupation spécifique, vous pouvez le faire ici.
