Content Security Policy : sécurité pour votre site, mais pas seulement

La politique de sécurité des contenus vous permet de protéger votre site web des effets de nombreuses vulnérabilités en lien avec l’injection de contenus. Découvrons pourquoi et comment utiliser ce simple en-tête HTTP, pourtant très puissant, et aujourd’hui largement supporté par les navigateurs web.

Un peu de contexte

Les failles XSS (Cross-Site Scripting), qui permettent à un attaquant l’injection de scripts malicieux sur une page web, figurent à la troisième position du top 10 des vulnérabilités les plus critiques édité par l’OWASP (Open Web Application Security Project), communauté de référence dans le domaine de la sécurité informatique.

Ces failles permettent à un attaquant l’injection de scripts malicieux sur une page web, avec des risques qui peuvent aller de l’usurpation de session au défaçage du site  (modification de l’apparence par un attaquant) par exemple.

Pour se prémunir d’une telle attaque, il est de rigueur de contrôler toutes les données qui peuvent provenir d’un utilisateur, potentiellement malveillant, avant de les stocker ou de les utiliser sur une page web.

Même en supposant, que toutes les protections sont en place de ce côté, vous resterez dépendant des contenus de tierces parties, car vos prestataires ou partenaires pourraient eux-même être victimes d’une attaque !

Heureusement, la Content Security Policy vous permettra d’ajouter une couche supplémentaire de sécurité à ce niveau, en vous permettant de contrôler de manière très précise ce que vous autorisez sur vos pages web !

Pour finir de vous convaincre de l’intérêt de ce sujet, voici quelques sites qui utilisent CSP en production : Facebook, Twitter, Github, toysrus.com, nouvelobs.com, ou encore letsencrypt.org.

Comment fonctionne la Content Security Policy

Ce n’est ni plus ni moins qu’un en-tête HTTP que votre serveur web va envoyer à tous les internautes. Comme son nom l’indique, cet en-tête va permettre de définir la politique de sécurité régissant les contenus de votre page.
C’est le navigateur web qui se chargera ensuite de l’application de cette politique de sécurité, en refusant éventuellement ce qui ne serait pas autorisé (ce qui se traduira également par une erreur dans la console du navigateur).

Une violation de la CSP se traduit par une erreur en console. Le code concerné n'est pas téléchargé/exécuté

Voici sans plus attendre un exemple simple de configuration CSP :

Content-Security-Policy: "default-src 'self'; script-src 'self' https://ajax.googleapis.com"

Quelle lecture en faire ?  
default-src” indique la politique commune pour tous les types de contenus (toutes les directives xxx-src), sauf éventuelle surcharge. La valeur “self” ici autorise tous les contenus qui proviennent du même domaine (et même port et schéma).

script-src” nous permet ensuite d’affiner cette politique, en autorisant les scripts qui proviennent du CDN de Google, sans oublier d’autoriser également les scripts du domaine avec “self”.  

Dans le cas présent, une feuille de style provenant de https://ajax.googleapis.com serait par exemple refusée par le navigateur, car c’est la politique default-src qui s’appliquera pour les styles.
Vous retrouverez  dans la deuxième partie de ce dossier (Comment implémenter Content Security Policy) une liste des directives disponibles, ainsi que les valeurs possibles pour les plus courantes.

Des limitations à prendre en compte

Malheureusement la CSP n’est pas la panacée : elle empêche les effets d’une attaque, mais n’empêche pas l’attaque en elle-même ! (un script pourrait être injecté sur votre page, mais il ne sera pas exécuté par le navigateur web).

Pour que la politique de sécurité soit efficace, il faut qu’elle soit appliquée par le navigateur web, et donc que ce dernier supporte CSP. Ce n’est pas le cas des anciens navigateurs, sur lesquels elle n’aura aucun effet, comme Internet Explorer 8 par exemple.
Toujours concernant le support, il faut noter que plusieurs versions de CSP existent : attention donc à vérifier la compatibilité des instructions que vous serez à même d’utiliser.
Vous pouvez retrouver les informations sur le support de CSP par les navigateurs sur cette page Can I Use.

La  3ème version de CSP est en préparation (voir le document de travail), et l’on remarque à travers ces 3 versions des changements qui ne sont pas rétro-compatibles. Même si dans la grande majorité des cas cela ne posera pas problème, il faut garder en tête que cette technologie est récente, son utilisation est encore relativement restreinte, et cela peut être un frein si vous souhaitez en faire un usage avancé.

Enfin, une CSP n’est réellement efficace que si elle est fortement restrictive. Dans la mesure où votre site est complexe et fréquemment mis à jour, ou qu’il repose sur des contenus de tierces parties nombreux et/ou volatiles, il faudra probablement arbitrer entre difficulté de maintenance et permissivité de la politique.

CSP, bien plus loin que la sécurité de votre site

CSP vous permet d’autoriser les contenus que vous explicitez, le reste étant prohibé. C’est donc également un excellent outil pour vous assurer de rester maître des contenus de votre page.
Même sans parler de vulnérabilité, cela peut-être un bon moyen de vous assurer qu’une tierce partie ne viendrait pas à charger d’un coup des dizaines de fichiers supplémentaires sur vos pages web !

Avec une politique restrictive vous empêchez probablement chez certains de vos internautes d’éventuels malwares ou FAIs indélicats d’injecter des contenus lors de la visite de vos pages web (exemple ici d’un Hotspot wifi) ! Et qui sait, vous protégerez peut-être aussi les internautes d’eux mêmes, comme a pu nous le rappeler la communication de Facebook sur le Self-XSS.

Un autre effet de bord inattendu peut également se produire, cette fois-ci avec certains bookmarklets ou extensions navigateur ‘bienveillants’, qui auraient besoin d’interagir avec la page protégée via CSP, comme a pu le remarquer Nicolas Hoffman qui regroupe ici des erreurs d’origine indéterminée avec CSP (et qui avait d’ailleurs mené une conférence sur CSP à Paris Web).

Je vous propose maintenant de passer à la deuxième partie de ce dossier :  Comment implémenter Content Security Policy

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*