En bref : JavaScript obfusqué et évasion CSP
- Passe par déclaration : Le JavaScript obfusqué passe CSP en ne déclarant que ce que CSP autorise. Le comportement malveillant commence après le chargement du script.
- Domaines, pas intégrité : CSP autorise des domaines, pas l'intégrité du code. Un domaine de confiance compromis passe quand même. Polyfill.io a passé CSP sur 490 000 sites.
- La conformité exige plus : 6.4.3 et 11.6.1 exigent une détection au-delà de CSP : inventaire de scripts, vérification d'intégrité, détection d'altération.
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.
Trois voies par lesquelles le code obscurci contourne la CSP
La CSP contrôle les sources, pas les charges utiles. Trois patterns d'attaque exploitent cette lacune:
Compromission d'un CDN de confiance ou d'un hôte tiers. Le script se charge depuis un domaine déjà présent dans la liste d'autorisation. Une charge modifiée ne déclenche pas la CSP car l'URL source est inchangée. Polyfill[.]io, les attaques de skimming web Magecart et les récentes compromissions de CDN d'analytique suivent cette voie.
Injection dans des fichiers propriétaires. Un attaquant ayant accès au serveur injecte du code obscurci dans un fichier JavaScript propriétaire existant. Ce fichier se charge depuis le domaine du site, qui est toujours autorisé.
Construction dynamique de code à l'exécution. Un script approuvé se charge et assemble une fonction malveillante à partir de fragments de chaînes à l'exécution, en utilisant eval(), Function() ou des équivalents indirects. La charge dangereuse n'existe jamais dans aucune ressource chargée; elle est construite dans le navigateur après un chargement de page propre.
Aucune de ces routes ne viole une liste d'autorisation de sources. La CSP rapporte tout propre pendant que les malwares obscurcis s'exécutent.
Comment les scripts obscurcis échappent aussi aux scanners automatisés
L'obscurcissement supprime les signaux lisibles que les réviseurs humains et les scanners automatisés recherchent:
| Technique | Ce qu'elle fait | Pourquoi les scanners la manquent |
|---|---|---|
| Division et concaténation de chaînes | Fragmente les URLs et mots-clés en morceaux assemblés à l'exécution | Aucune chaîne complète n'apparaît dans la source statique |
| Encodage Base64 avec décodage dynamique | Stocke la charge comme un blob décodé uniquement à l'exécution | Ressemble à des données, pas à du code exécutable, pour un analyseur statique |
| Séquences d'échappement hexadécimales ou Unicode | Encode les caractères comme \x61 ou A | Les outils statiques doivent exécuter le code pour résoudre la valeur réelle |
| Noms de variables aléatoires | Remplace les identifiants lisibles par des noms courts aléatoires | Supprime le signal de mots-clés sur lequel s'appuient les détecteurs de patterns |
| Chargement dynamique tardif | Récupère la charge réelle depuis un serveur C2 après l'exécution d'un script approuvé | La ressource chargée diffère à chaque analyse |
Les hashes de Subresource Integrity (SRI) protègent contre les substitutions silencieuses de charges depuis des sources connues, mais seulement si un hash peut être fixé pour chaque fichier. Les scripts tiers qui se mettent à jour fréquemment rendent le SRI impraticable en production, ce qui constitue le défi central de la gestion de l'intégrité des scripts pour les scripts dynamiques. Le SRI ne peut pas non plus protéger contre les charges récupérées dynamiquement depuis un endpoint C2, car cette charge n'existait pas lors du calcul d'un quelconque hash.
Pourquoi les scanners statiques ne voient pas un CDN détourné
Les outils d'analyse statique et d'analyse de composition logicielle examinent le code avant son exécution. Ils repèrent les paquets porteurs de CVE publiées, les motifs dangereux comme les affectations à innerHTML depuis une entrée utilisateur, et les dépendances obsolètes. Ce qu'ils ne peuvent pas faire, c'est observer ce qu'un CDN livre réellement au navigateur d'un visiteur.
L'incident polyfill[.]io en est l'exemple le plus net. Lorsque Funnull a acquis le domaine en février 2024, le code source de chaque site intégrant le script est resté inchangé. Le CDN a commencé à injecter du JavaScript malveillant dans les réponses qu'il servait, mais uniquement pour les utilisateurs mobiles, uniquement avec un référent falsifié, et uniquement lorsque le visiteur n'avait pas un motif de cookies associé à Google Analytics et aux outils de développement.
Un scanner statique aurait vu <script src="https://cdn.polyfill[.]io/v3/polyfill.min.js"> dans le HTML et n'aurait trouvé aucune CVE. Il n'y avait pas non plus de hash stable à épingler : le point de terminaison générait une réponse par requête, précisément le cas où la SRI ne s'applique pas. L'attaque était invisible pour tout outil analysant le code au repos. Quand les chercheurs ont identifié le payload en juin 2024, environ 490 000 sites web le servaient déjà à de vrais utilisateurs.
La livraison conditionnelle est ce qui rend cette classe difficile à détecter depuis l'extérieur de la session. Les attaquants conditionnent les payloads au user agent, au référent, à la géographie et à l'heure de la journée précisément pour échapper à la surveillance synthétique et aux profils de navigateur des chercheurs. Un payload qui ne se déclenche que pour des utilisateurs mobiles d'un pays un après-midi donné n'apparaît jamais dans une analyse statique et ne se reproduit pas dans un crawler.
Approches pour la protection contre le JavaScript obscurci
| Approche | Contrôle des sources | Inspection de la charge | Gère la compromission d'un hôte de confiance | Détecte l'injection dynamique à l'exécution |
|---|---|---|---|---|
| CSP | Oui | Non | Non | Non |
| Subresource Integrity (SRI) | Partiel | Hash uniquement | Partiel | Non |
| WAF ou filtrage couche réseau | Partiel | Non | Non | Non |
| Analyse statique JavaScript | Non | Partiel | Partiel | Non |
| Surveillance comportementale couche navigateur | Optionnelle par politique | Oui | Oui | Oui |
La surveillance au niveau de la couche navigateur est le seul contrôle de ce tableau qui résiste aux trois voies d'évasion décrites. Elle fonctionne aux côtés de la CSP et couvre la lacune de visibilité des charges utiles que la CSP laisse ouverte.
Ce qu'exiger d'un outil résistant à l'évasion CSP
Quatre questions avant d'établir une liste de fournisseurs:
Observation de la charge utile à l'exécution. L'outil analyse-t-il ce que les scripts exécutent dans le navigateur, pas seulement les URLs depuis lesquelles ils se chargent? Demandez au fournisseur de démontrer la détection d'un script qui se charge depuis un domaine de confiance et appelle un endpoint d'exfiltration non autorisé. Si la démonstration nécessite une URL source malveillante pour se déclencher, l'outil dépend de la source.
Détection de patterns de code obscurci. Posez des questions spécifiques sur la division de chaînes, les équivalents d'eval() et le décodage dynamique Base64. Les outils qui ne signalent que eval() littéralement manqueront la plupart des obscurcissements réels.
Surveillance comportementale post-chargement. Beaucoup d'attaques récupèrent leur vraie charge depuis un serveur C2 après le chargement initial de la page. L'outil doit continuer à surveiller au-delà de DOMContentLoaded, pas seulement lors du parsing initial.
Explicabilité des alertes. Une alerte qui dit seulement "script suspect détecté" n'est pas exploitable. Chaque constat doit identifier le script, le comportement qui a déclenché la détection et l'appel réseau tenté, pour qu'un analyste puisse trier sans deviner.
Comment cside s'inscrit dans ce tableau
cside instrumente le navigateur via un script qui s'exécute dans chaque session de visiteur. Il observe ce que chaque script tiers et propriétaire fait à l'exécution: appels réseau effectués, modifications DOM appliquées, champs de données sensibles accédés et patterns d'exécution obscurcis détectés.
Lorsqu'un CDN compromis sert une charge obscurcie à une page instrumentée par cside, la détection s'active sur ce que la charge fait à l'exécution (appel réseau non autorisé, chaîne eval obscurcie, pattern d'exfiltration de données) plutôt que sur son origine. Un échec de liste d'autorisation de sources ne peut pas produire un faux négatif dans un système basé sur le comportement.
Les exigences 6.4.3 et 11.6.1 de PCI DSS v4.0.1 (obligatoires depuis mars 2025) imposent aux marchands d'autoriser tous les scripts sur les pages de paiement et de détecter les modifications non autorisées du contenu des scripts ou des en-têtes HTTP. La surveillance comportementale au niveau de la couche navigateur fournit les preuves au niveau de l'exécution que ces contrôles attendent d'une couche de surveillance qui atteint l'intérieur du navigateur plutôt que de s'arrêter au périmètre réseau.
Pour en savoir plus sur les limites pratiques de la CSP, consultez pourquoi la CSP ne fonctionne pas. Pour une analyse technique des méthodes d'obscurcissement utilisées dans les attaques réelles, consultez le guide de désofuscation du JavaScript tiers.
