En bref : désobfuscation de JavaScript
- La désobfuscation de JavaScript est le processus qui consiste à retransformer un script obfusqué en code lisible par un humain, afin d'auditer son comportement. L'obfuscation est utilisée à la fois par des éditeurs légitimes (pour protéger la propriété intellectuelle) et par des attaquants (pour cacher des charges utiles malveillantes).
- La boîte à outils standard combine manipulation d'AST, exécution symbolique et reconstruction du graphe de flux de contrôle. Les outils prêts à l'emploi gèrent les schémas d'obfuscation courants ; les obfuscateurs personnalisés exigent une analyse sur mesure.
- À l'exécution, le code malveillant obfusqué doit tout de même se révéler lorsqu'il accède aux éléments du DOM ou ouvre des connexions réseau. La surveillance en session détecte ce comportement même quand la désobfuscation statique échoue.
Peu de temps ? Découvrez le blocage Magecart et skimmer dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
L'obfuscation JavaScript consiste à transformer du code JavaScript normal et lisible par un humain en une forme intentionnellement difficile à lire et à comprendre. L'obfuscation est généralement utilisée pour dissimuler la signification réelle du code, ce qui rend extrêmement difficile le suivi ou la rétro-ingénierie de ses fonctions. Contrairement au chiffrement du code, l'obfuscation ne nécessite ni algorithme ni clé privée pour s'exécuter. La logique et les fonctionnalités du code restent exactement les mêmes, mais le code est truffé de noms de fonctions vagues et opaques, de structures programmatiques étranges et de chaînes encodées.
Les développeurs peuvent parfois utiliser des outils comme les obfuscateurs JavaScript pour protéger leur code et leur propriété intellectuelle et empêcher qu'ils ne soient volés. Mais d'un point de vue sécurité, notamment dans le contexte des scripts tiers, le code obfusqué est un signal d'alarme majeur. Les attaquants utilisent souvent cette obfuscation pour dissimuler leur code malveillant, qu'il s'agisse de malware, de logique de vol de données ou de code d'exploitation, à l'intérieur de ce qui ressemble à un amas aléatoire de texte. Cela seul peut souvent contourner des scanners de sécurité simples et rendre l'analyse manuelle des scripts bien plus difficile.
Pourquoi la désobfuscation de JavaScript est-elle importante pour la sécurité ?
En matière de sécurité web, la visibilité sur les charges utiles - c'est-à-dire la capacité à voir et inspecter le code qui s'exécute sur votre site - est absolument critique. Désobfusquer JavaScript (inverser ou décoder le code) offre à un analyste de sécurité une compréhension claire du script et de ce qu'il exécute sous le capot. Si vous ne pouvez pas percer cette obfuscation, vous êtes effectivement aveugle à ce que ce code pourrait faire.
Se fier uniquement à des mesures de sécurité superficielles ne suffit pas à protéger votre site. Par exemple, les en-têtes Content Security Policy peuvent restreindre les sources depuis lesquelles les scripts sont autorisés à se charger, mais n'offrent aucune visibilité sur la charge utile des scripts eux-mêmes. Si un hébergeur tiers est compromis et commence à servir des malwares obfusqués - comme nous l'avons signalé en 2024 avec l'attaque Polyfill - une CSP ne vous indiquera pas que le contenu du script est malveillant. Parce qu'il provient d'une source approuvée, elle lui fera confiance et ne signalera pas le contenu potentiellement malveillant qu'il sert.
Une autre raison pour laquelle la visibilité sur les charges utiles est critique tient à la nature dynamique de la plupart des attaques côté client. Comme nous l'avons couvert dans notre rapport d'attaques côté client du T2, cside a commencé à observer de plus en plus d'attaques qui injectent du code obfusqué dans des sites, lequel envoie souvent des signaux à un serveur de commande et contrôle pour recevoir des instructions supplémentaires. Cela peut exposer un site à des menaces telles que la publicité malveillante et les redirections, les scripts de cryptojacking et les kits d'exploitation de navigateur, tous contrôlés dynamiquement par un tiers.
Quels sont les signaux d'alarme JavaScript courants à surveiller ?
Code illisible ou brouillé
L'un des plus grands signaux d'alarme à surveiller est qu'un script soit un enchevêtrement insensé de caractères, de longs tableaux numériques et de fonctions étranges qui ne ressemblent à aucun code lisible par un humain. Les attaquants dissimulent souvent des chaînes en les encodant via des échappements hexadécimaux, Base64 et Unicode, en les découpant en morceaux illisibles. Ces variables ressembleront à _0x5e ou aa1122bbcc et auront rarement des identifiants significatifs. Les bibliothèques légitimes peuvent minifier du code qui y ressemble, mais elles ne seront généralement pas profondément obfusquées avec des données parasites.
Données encodées / parasites dans les chaînes
Les scripts malveillants dissimulent souvent des chaînes critiques (comme des URL, des mots-clés, des charges utiles JavaScript) en les encodant et en y insérant des données parasites. Par exemple, ils peuvent avoir une URL obfusquée via un encodage hexadécimal et y parsemer plusieurs sous-chaînes parasites constantes pour contrecarrer le décodage. Des fonctions comme atob(), unescape() et des routines personnalisées qui transforment des chaînes sont souvent des indicateurs clairs que le script cherche à dissimuler quelque chose. Par le passé, des attaquants ont été connus pour insérer du texte aléatoire ou utiliser plusieurs couches d'encodage afin de masquer des variables comme eval et document.cookie.
Génération dynamique de fonctions (eval et ses équivalents)
Un autre signal d'alarme dans un script est l'utilisation de fonctions comme eval(), le constructeur Function() ou setTimeout() et setInterval(). Cela signifie souvent que le script construit du code à l'exécution, ce qui peut être une technique privilégiée par les malwares pour décompresser la véritable charge utile. Les scripts légitimes modernes utilisent rarement eval() en raison des implications en matière de sécurité et de performances, donc sa présence dans un script tiers devrait éveiller les soupçons. De même, créer dynamiquement des éléments de script dans le DOM via document.createElement('script') est une autre façon d'injecter du code malveillant. Si vous repérez du code qui construit une balise <script> avec une URL externe suspecte, c'est un signal d'alarme majeur indiquant que votre site pourrait être compromis.
Connexions externes suspectes
Tout script tiers qui référence des domaines ou des adresses IP externes sans rapport avec la fonction du site est un signe révélateur de comportement malveillant. Par exemple, si un script obfusqué effectue soudainement une requête fetch() ou XHR vers un domaine sans rapport avec le site, c'est souvent un indicateur de comportement malveillant. Les attaquants utilisent souvent leurs propres serveurs pour l'exfiltration ou les points de contrôle, et toute apparition de ces domaines dans du code tiers est un signal d'alarme.
Manipulations du HTML et du DOM
Le JavaScript malveillant obfusqué manipule souvent la page de manière furtive. Cela se traduit souvent par la création d'éléments invisibles ou en superposition, la définition de valeurs z-index extrêmement élevées (pour couvrir la page avec une saisie ou une invite frauduleuse) et l'injection de formulaires et d'écouteurs d'événements. cside a récemment signalé une attaque survenue sur CoinMarketCap qui utilisait une fenêtre contextuelle malveillante avec une valeur z-index élevée pour inciter les utilisateurs à connecter leurs portefeuilles à un tiers malveillant, vidant leurs portefeuilles de toute cryptomonnaie qu'ils contenaient.
L'obfuscation polymorphique dans les attaques JavaScript
L'une des techniques les plus avancées et évasives que les attaquants peuvent utiliser pour dissimuler la véritable intention de leur script est l'obfuscation polymorphique. L'obfuscation polymorphique désigne du code qui change de structure à chaque livraison de la charge utile, même si le comportement sous-jacent reste identique. Cette technique est empruntée au développement traditionnel de malwares, où les binaires polymorphiques modifient leur apparence pour échapper à la détection des antivirus. Dans l'écosystème JavaScript côté navigateur, les attaquants obtiennent cette même évasion en faisant tourner les noms de variables, en restructurant les fonctions, en modifiant le flux de contrôle et en superposant du code parasite aléatoire tout au long du script.
Cela signifie que deux charges utiles ayant la même intention, comme l'écrémage d'un formulaire de paiement sur un site web, peuvent sembler entièrement différentes au niveau du code. Cela met en échec les méthodes de détection comme les signatures basées sur les hachages et les filtres statiques basés sur les IOC, et rend la protection globale incroyablement difficile. Parce que le code est dynamique et changeant, les défenses périmétriques comme la Content Security Policy (CSP) et la Subresource Integrity (SRI) ne peuvent pas offrir une protection suffisante à votre site contre les attaques polymorphiques. Ces protections sont capables de valider l'origine du script et de détecter s'il a été modifié, mais n'offrent aucune visibilité sur ce que le script fait réellement à l'exécution.
Quels outils et technologies permettent de désobfusquer JavaScript ?
La désobfuscation est essentiellement un exercice de rétro-ingénierie visant à transformer les chaînes et fonctions encodées en quelque chose de lisible par un humain. Il faut souvent combiner plusieurs des techniques ci-dessous pour désobfusquer complètement un script :
- Embellisseurs ou formateurs de code : des outils comme JSBeautify, deobfuscate.io, JSnice et de4js peuvent prendre un script compressé ou minifié et ré-indenter le code pour ajouter des sauts de ligne, le transformant en un morceau de code correctement structuré. Cela ne supprime souvent pas l'obfuscation, mais rend la mise en forme du code plus lisible.
- Utilitaires de décodage de chaînes : le code obfusqué encodant fréquemment des données en hexadécimal, Base64, etc., l'utilisation d'outils de décodage simples peut permettre de récupérer les chaînes initiales. De nombreux analystes de sécurité utilisent des scripts Python ou des sites comme Dencode.com pour décoder les formats courants.
- Refactorisation et remplacement manuels : parfois, la méthode la plus simple est aussi la plus manuelle - après avoir utilisé un embellisseur de code, lire le code et remplacer statiquement les noms de variables ou de fonctions obfusqués par leur signification réelle peut aider à comprendre l'intention derrière certaines fonctions.
- Analyse AST : pour les scripts très complexes, les chercheurs en sécurité se tournent souvent vers des scripts développés sur mesure pour analyser et transformer le code. Utiliser un parseur JavaScript pour obtenir l'arbre syntaxique abstrait (AST) d'un script permet à un chercheur de naviguer programmatiquement dans la structure et de supprimer les couches d'obfuscation. Cette approche peut aider à simplifier automatiquement des éléments comme l'aplatissement du flux de contrôle ou l'encodage élaboré des fonctions, bien qu'elle exige de solides compétences en programmation.
Le JavaScript obfusqué peut-il être analysé automatiquement ?
L'analyse automatique et le sandboxing sont indispensables pour traiter de grands volumes de JavaScript obfusqué et détecter les menaces en temps réel. Analyser manuellement chaque script est souvent impraticable, si bien que les organisations peuvent recourir à une combinaison de sandboxing dynamique, d'analyse statique du code et de renseignement sur les menaces pour comprendre le JavaScript à grande échelle.
- Analyse dynamique par sandboxing : une approche pour déterminer ce que fait un code suspect consiste à l'exécuter dans un environnement contrôlé (en utilisant par exemple un navigateur qui parcourt le code pas à pas) et à observer son comportement. Lorsqu'un script obfusqué y est exécuté, le bac à sable peut souvent enregistrer des comportements qui semblent malveillants. Le script tente-t-il de modifier le formulaire de paiement ? Effectue-t-il un appel AJAX vers un domaine suspect ou connu comme malveillant ? Génère-t-il des iframes cachées ou consomme-t-il une quantité significative de CPU ? Parce que le bac à sable observe les actions du script, il peut signaler des schémas même si le code était obfusqué. Certains bacs à sable peuvent même s'accrocher au moteur JavaScript pour extraire le code désobfusqué une fois que le script s'est décompressé en mémoire. L'approche dynamique est intéressante car elle ne nécessite pas de comprendre le code et observe directement les résultats malveillants, mais elle peut être détectée par des malwares avancés, qui modifieraient alors leur comportement.
- Analyse statique avec intelligence artificielle et grands modèles de langage : du côté de l'analyse statique, les outils de sécurité utilisent souvent la reconnaissance de motifs et l'intelligence artificielle pour examiner le texte et le comportement des scripts afin de déterminer s'ils sont malveillants, même obfusqués. L'utilisation de grands modèles de langage pour établir rapidement une base d'activité à partir du script est devenue de plus en plus populaire, car elle permet à un analyste de sécurité de distinguer rapidement un script simplement minifié d'un script malveillant.
Chez cside, notre pipeline d'analyse automatique évalue le JavaScript à la fois dans sa forme obfusquée et désobfusquée, en exécutant des règles de détection avant et après la normalisation du code vers une forme lisible. Cette approche à double couche nous aide à détecter des menaces évasives qui ne pourraient apparaître qu'une fois le code décompressé. Contrairement à de nombreux scanners traditionnels, cside utilise des modèles de détection basés sur les attributs pour observer comment un script interagit avec l'API DOM et quels éléments il peut créer, modifier et attacher. Ces attributs comportementaux nous permettent de repérer des changements suspects même si le script est fortement obfusqué ou généré à l'exécution.
Quels sont des exemples concrets d'attaques JavaScript malveillantes obfusquées ?
Le JavaScript obfusqué a été au cœur de nombreuses attaques réelles sur lesquelles cside a publié des rapports, des violations très médiatisées aux campagnes de malware du quotidien.
- Écrémeurs de cartes de crédit Magecart : Magecart est un terme générique désignant des groupes qui ont historiquement injecté du JavaScript malveillant dans des sites e-commerce pour voler des données de cartes de paiement. Lors de l'attaque contre British Airways en 2018, des attaquants ont compromis des scripts tiers et inséré du code d'écrémage obfusqué. Ce code était conçu pour voler les informations de carte de crédit sur les pages de paiement et les envoyer vers des serveurs contrôlés par les attaquants, tout en se fondant dans les scripts légitimes. Les attaquants Magecart utilisent couramment l'obfuscation de scripts pour encoder les fonctions et dissimuler la véritable intention de la logique du code. Pour plus d'informations sur l'attaque contre British Airways, cside a publié un rapport spécial sur l'attaque (et sur la façon dont nous avons fini par récupérer le domaine utilisé dans l'attaque !)
- Scripts de cryptojacking : l'essor des mineurs de cryptomonnaie exécutés dans le navigateur a également vu le recours au code obfusqué pour mettre en œuvre ces attaques. Dans une attaque de cryptojacking, un attaquant injecte un script qui utilise silencieusement le processeur d'un visiteur pour miner de la cryptomonnaie. Pour éviter une détection facile (en dehors d'un pic de l'utilisation du processeur de l'utilisateur), le code était souvent obfusqué ou servi depuis un CDN de contenu compromis. cside a récemment publié un article sur la façon dont les attaques de cryptojacking sont devenues plus fréquentes au cours de la dernière année et ont considérablement évolué dans leur mode d'exécution.
- Injection via Progressive Web App et redirections : en 2025, cside a signalé une attaque utilisant une Progressive Web App pour rediriger des utilisateurs mobiles vers une arnaque de contenu pour adultes chinois. La charge utile de cette attaque avait déjà été observée auparavant, mais sa diffusion via une Progressive Web App constituait un vecteur d'attaque incroyablement singulier. Bien que les PWA soient souvent négligées dans le domaine de la sécurité côté client, elles sont elles aussi susceptibles aux attaques côté navigateur que cside observe fréquemment.
Quelles sont les meilleures pratiques pour la surveillance et la défense continues de la sécurité JavaScript ?
Protéger votre application web du code tiers malveillant n'est pas un effort ponctuel, mais nécessite une surveillance continue et de bonnes pratiques pour minimiser les risques.
- La Méthode Script de cside : cside récupère les scripts tiers externes sur notre propre infrastructure, nous permettant d'intercepter, d'analyser et de stopper les attaques JavaScript avant qu'elles ne s'exécutent dans le navigateur de l'utilisateur. cside permet une surveillance en temps réel du comportement des scripts à chaque chargement de page, sans modifier le code de l'application ni ajuster les exigences de Content Security Policy. En inspectant les scripts à la fois dans leur forme obfusquée et normalisée, le proxy peut appliquer des règles et signaler des anomalies - même lorsque les attaquants font tourner les couches d'obfuscation ou injectent des charges utiles dynamiques.
- Restreindre et valider les sources de scripts : utiliser des en-têtes Content Security Policy (CSP) pour contrôler strictement les sources depuis lesquelles les scripts peuvent être chargés est une autre excellente façon de protéger votre site contre les attaques indésirables. Utiliser une règle CSP pour n'autoriser que vos domaines et les CDN connus, et bloquer tout le reste, constitue une excellente première étape pour sécuriser le JavaScript qui s'exécute sur votre site. Combiner la CSP avec des vérifications de Subresource Integrity (SRI), capables de détecter si un fichier a été altéré et d'empêcher son exécution, peut vous garantir de ne charger que ce que vous avez l'intention de charger.
- Restez informé et formez votre équipe : le paysage des menaces évolue incroyablement vite, et de nouvelles techniques d'obfuscation et d'attaque émergent en permanence. Investissez dans la formation de vos équipes de sécurité, ainsi que de vos équipes de développement, sur ces tendances et les bonnes pratiques pour s'en protéger. Suivez les rapports de renseignement sur les menaces et mettez à jour vos propres schémas de détection en conséquence. Assurez-vous de disposer d'un plan de réponse aux incidents spécifiquement dédié aux incidents côté client - par exemple, si vous détectez soudainement un écrémeur obfusqué sur votre site, qui alertez-vous ? Se préparer à ces scénarios garantit une réponse capable de minimiser les dommages, si elle est correctement gérée.
Réflexions finales
Dans l'écosystème de navigateurs actuel, le JavaScript tiers est à la fois une nécessité et un risque pour les sites web. Les techniques d'obfuscation peuvent servir du code légitime, mais elles sont aussi souvent utilisées par les attaquants pour dissimuler des charges utiles nuisibles, rendant plus difficile que jamais la détection, l'analyse et la réponse face aux menaces potentielles. Avoir la capacité de désobfusquer JavaScript et de surveiller son comportement n'est plus optionnel. C'est absolument critique.
Chez cside, nous avons conçu notre technologie pour donner aux équipes une visibilité sur ce qui se passe réellement à l'intérieur des scripts tiers. À mesure que les attaques côté client continuent d'évoluer, investir dans la visibilité sur les charges utiles et la surveillance en temps réel est la meilleure défense que vous puissiez déployer aujourd'hui. Si vous êtes prêt à reprendre le contrôle de votre risque lié au JavaScript tiers, prenez contact avec nous et explorez davantage de notre blog de renseignement sur les menaces pour rester informé des schémas d'attaque.
