La protection résistante à l'évasion CSP désigne des contrôles de sécurité qui détectent et bloquent le JavaScript malveillant même lorsque ce code utilise l'obscurcissement, le chargement dynamique ou l'injection depuis des hôtes de confiance pour contourner la Content Security Policy. La CSP impose une liste d'autorisation de sources de scripts approuvées mais ne peut pas inspecter ce que ces sources approuvées exécutent. Les contrôles résistants à l'évasion observent le comportement à l'exécution de chaque script dans la session du navigateur, détectant les menaces qui passent les vérifications de liste d'autorisation sans déclencher aucune violation de politique.
L'attaque de la chaîne d'approvisionnement de Polyfill[.]io en juin 2024 a montré cette faille. Plus de 490 000 sites web avaient cdn.polyfill[.]io dans leur liste CSP autorisée. Lorsque le domaine a changé de propriétaire et que le nouvel opérateur a remplacé la bibliothèque légitime par des malwares obscurcis, chaque site affecté a chargé et exécuté la charge malveillante tandis que la CSP ne signalait aucune violation. (Recherche Sansec, juin 2024)
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.
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.
