Ces dernières semaines, nous avons abordé sur le blog un certain nombre d’en-têtes HTTP liés à la sécurité, mais le chef de file de tous ces en-têtes est sans conteste Content-Security-Policy(CSP). Le patron, à la fois en raison du niveau de protection qu’il fournit, mais malheureusement aussi en raison de la difficulté de l’implémenter correctement dès le départ. Comme pour toutes les règles de gestion du trafic flightPATH dont nous avons parlé récemment, nous les utilisons nous-mêmes pour protéger le site web edgeNEXUS et ses visiteurs.
Nous avons fait le travail difficile et ressenti la douleur pour que vous n’ayez pas à le faire, mais il est indéniable qu’une réflexion et une planification sont nécessaires avant la mise en œuvre. Mais cela en vaut la peine. Le concept de cet en-tête est assez simple et tout aussi puissant. En bref, vous l’utilisez pour spécifier les origines autorisées du contenu qui peut être chargé sur votre site web. Il offre une protection solide contre un certain nombre d’attaques par injection de code qui sont courantes sur l’internet de plus en plus dynamique d’aujourd’hui, telles que le Cross Site Scripting (XSS) et le Clickjacking.
Les types de contenu qui peuvent être contrôlés comprennent : JavaScript, CSS (oui, CSS peut être dangereux), les cadres HTML, les polices, les images et les objets incorporables tels que les applets Java. C’est une bonne chose d’avoir autant d’options, mais c’est là que le bât blesse. Les sites web d’aujourd’hui (y compris les nôtres) contiennent une multitude de ces types de contenu provenant de nombreuses sources, et les identifier et les prendre en compte dans une politique peut s’avérer une tâche ardue.
Avant d’en arriver là, examinons les éléments de la valeur de l’en-tête et ce à quoi ressemble une politique. Comme vous le verrez, il s’agit essentiellement d’une longue liste de types de contenu (se terminant tous par -src dans cet exemple) et des sources autorisées pour chaque type. L’ensemble de ces éléments est connu sous le nom de directives de politique.
default-src « self » data: ; script-src « self » « unsafe-inline » ; connect-src « self » ; img-src « self » data: ; style-src « self » « unsafe-inline » data: ; font-src « self » data: ; child-src « self »
D’autres types de contenus peuvent être pris en considération, mais ceux présentés ci-dessus sont les directives les plus importantes (à notre avis, sur la base du risque et de la prévalence). Voici les détails concernant le contenu de chacun d’entre eux ;
- default-src – Valeurs par défaut pour la plupart des types de contenu (mais pas tous) si elles ne sont pas spécifiées ultérieurement.
- script-src – Sources autorisées pour les scripts (y compris JavaScript)
- connect-src – Sources autorisées pour les connexions (telles que WebSockets et EventSource utilisées, par exemple, dans les applications de chat).
- img-src – Sources autorisées pour les images
- style-src – Sources autorisées pour CSS
- font-src – Sources autorisées pour les polices de caractères
- child-src – Sources autorisées pour les cadres et les iframes
Ces types de contenu et leurs valeurs sont séparés les uns des autres (délimités) par un point-virgule. Chaque type peut avoir une ou plusieurs des valeurs suivantes ;
- none » – n’autorise pas ce type de contenu
- « self » – autorise ce type de contenu s’il provient directement de ce site (mais pas des sous-domaines)
- unsafe-inline » – permet l’utilisation de CSS et de JavaScript en ligne (ce qui est malheureusement très courant).
- données : – permettre des sources de données en ligne (généralement utilisées pour fournir des polices et des images en ligne afin d’améliorer les performances).
- https : – n’autorise ce type de contenu que sur HTTPS
- unsafe-eval » – permet l’analyse de texte à l’aide de méthodes potentiellement dangereuses pouvant entraîner l’exécution de code
- nom-de-domaine – autorise ce type de contenu s’il provient du nom-de-domaine spécifié (en d’autres termes, un domaine distant) – ceci peut être utilisé plusieurs fois
- * – tout domaine
Un simple espace est utilisé pour délimiter chaque valeur. Les guillemets simples ‘ sont nécessaires sauf si la valeur est un nom de domaine. Notez que les extensions de navigateur et les plugins ne sont pas concernés, car ils sont considérés comme sûrs car l’utilisateur leur fait confiance (c’est lui qui les a installés après tout).
Tout cela semble assez technique et complexe, mais si l’on procède étape par étape, il est assez rapide d’élaborer une politique. Examinons rapidement deux exemples. Tout d’abord, essayons un simple site web interne desservi par HTTP. Voici ce dont nous avons besoin ;
- default-src « self » data : – autoriser uniquement le contenu de notre propre site, y compris les objets inline
- script-src « self » « unsafe-inline » – autorise les scripts provenant de notre propre site, y compris les scripts en ligne
- connect-src « self » – autorise les connexions depuis/vers notre propre site
- img-src « self » data : – autorise les images provenant de notre propre site, y compris les images en ligne
- style-src « self » « unsafe-inline » data : – autorise les feuilles de style CSS provenant de notre propre site, y compris les styles en ligne
- font-src « self » data : – autorise les polices provenant de notre propre site, y compris les polices en ligne
La valeur totale de l’en-tête est raisonnablement courte :
default-src « self » data: ; script-src « self » « unsafe-inline » ; connect-src « self » ; img-src « self » data: ; style-src « self » « unsafe-inline » data: ; font-src « self » data :
Deuxièmement, un site internet protégé par SSL/TLS qui utilise Google Analytics (GA), des CSS en ligne, des polices et des images, des CSS provenant de votre site et des images provenant de divers autres sites web. Voyons ce dont nous avons besoin, pièce par pièce (ce n’est pas très différent) ;
- default-src « self » data : https : – autorise uniquement le contenu de notre propre site, y compris les objets en ligne, uniquement via HTTPS
- script-src « self » « unsafe-inline » https : – autorise les scripts de notre propre site, y compris les scripts en ligne, uniquement via HTTPS
- img-src « self » « unsafe-inline » \* https : – autorise les images de n’importe quel site, y compris les images en ligne de notre site, uniquement via HTTPS
- style-src « self » « unsafe-inline » https : – autorise uniquement les CSS provenant de notre propre site, y compris les CSS en ligne, uniquement via HTTPS
- font-src « self » « unsafe-inline » https: – autorise uniquement les polices provenant de notre propre site, y compris les polices en ligne, uniquement via HTTPS
Si l’on additionne tous ces éléments, on obtient cette politique un peu plus longue :
default-src « self » data : https: ; script-src « self » « unsafe-inline » *.google-analytics.com https: ; img-src « self » « unsafe-inline » * https: ; style-src « self » « unsafe-inline » https: ; font-src « self » « unsafe-inline » https :
Je dirais que c’est assez facile. Google n’était pas si « convivial » pour le CSP dans le passé (cette valeur d’en-tête était au moins deux fois plus longue), mais ils ont heureusement fait de grands progrès récemment. Vous remarquerez que nous n’avons pas eu à ajouter le domaine *.google-analytics.com au script-src en tant que valeur de type de contenu car leur code est exécuté en tant que script inline.
Idéalement, vous devriez créer une politique pour chaque page de votre site web, car les ressources chargées diffèrent sans doute d’une page à l’autre, mais cela est plutôt onéreux et il est beaucoup plus simple, tout en restant efficace, de créer une politique qui couvre toutes les sources possibles. La plupart des exemples sur notre page GitHub adoptent cette approche, mais il y en a également un si vous souhaitez fournir une protection plus importante à des pages spécifiques.
Pour les tests et le dépannage, je vous recommande vivement d’utiliser les outils de développement de Google Chrome. Allez sur le site en question, appuyez sur F12, cliquez sur Réseau, assurez-vous que l’option Désactiver le cache est cochée, puis rechargez la page. Les erreurs éventuelles seront clairement mises en évidence. Au bas de ce blog, vous trouverez un écran de ce que vous pourriez voir si votre politique bloque unsafe-inline et que vous utilisez Google Analytics ; les messages d’erreur sont très utiles.
Ajustez votre politique si nécessaire, puis rincez et répétez. Idéalement, vous devriez utiliser un service virtuel de test dédié auquel vous appliquerez la règle flightPATH que vous testez, mais qui desservira le même site, simplement par le biais d’une IP virtuelle différente afin de ne pas affecter les clients réels pendant que vous testez.
Comme toujours, l « énorme avantage de l’utilisation d’un équilibreur de charge est qu’il suffit de le faire en un seul endroit central pour protéger tous nos serveurs (et sites). Nous n’avons pas besoin de faire appel à des développeurs ou à des reconfigurations de serveurs web. Sur l » équilibreur de charge edgeNEXUS, il suffit d’importer un modèle de configuration automatique jetPACK et d’assigner une règle de trafic flightPATH au(x) service(s) virtuel(s) que nous souhaitons protéger (après les modifications appropriées).
La règle n’ajoute l’en-tête que s’il n’existe pas, de sorte qu’elle fonctionnera même si nos serveurs web l’insèrent déjà ou s’ils ne l’insèrent que pour certaines pages. Cette règle devrait faire partie de votre configuration standard de service virtuel – vous n’avez rien à perdre, quel que soit le site, même si, bien entendu, il est toujours recommandé de procéder à des essais. Vous pouvez télécharger ce jetPACK et beaucoup d’autres sur le site Github d’edgeNEXUS.
flightPATH est un moteur de règles dynamique, basé sur des événements, développé par edgeNEXUS pour manipuler et acheminer intelligemment le trafic IP, HTTP et HTTPS à charge équilibrée. Il est hautement configurable et puissant, tout en étant très facile à utiliser.
Ces liens méritent d’être consultés si vous souhaitez en savoir plus ;
http://www.html5rocks.com/en/tutorials/security/content-security-policy/
https://developer.mozilla.org/en/docs/Web/Security/CSP/CSP_policy_directives
http://content-security-policy.com/
https://www.clickintelligence.co.uk/header-response-checker/
Ces dernières semaines, nous avons abordé sur le blog un certain nombre d’en-têtes HTTP liés à la sécurité, mais le plus important d’entre eux est sans aucun doute Content-Security-Policy (CSP).
