Le rôle de la politique de sécurité du contenu : pourquoi le CSP est-il si important ?

La politique de sécurité du contenu (CSP) est une norme de sécurité qui permet de dissuader les attaques de cybersécurité. Pourquoi les développeurs Web devraient-ils s’en soucier ? Apprenez-en davantage dans cet article.

Depuis 19 ans maintenant, octobre est connu comme le Mois de la sensibilisation à la cybersécurité, un mois dédié aux secteurs public et privé pour souligner collectivement l’importance de la cybersécurité. Cela me rappelle qu’à l’aube de son 20e anniversaire, la Cybersecurity and Infrastructure Security Agency (CISA) a annoncé un nouveau programme durable de sensibilisation à la cybersécurité, Sécurisez notre monde.

Cependant, octobre 2023 est révolu depuis longtemps et je préfère que chaque mois soit considéré comme un mois de sensibilisation à la cybersécurité. Non seulement je parle d’être extrêmement prudent lorsqu’on reçoit un email inattendu contenant un appel à l’action ou de faire référence aux failles de sécurité majeures des réseaux sociaux, mais Hé, c’est la cybersécurité : faites-en simplement une habitude. Période.

Mais tout d’abord : revenons à quelques notions de base sur le sujet de cet article de blog. Dans le monde du cyberespace, où l’information circule en permanence, renforcer la sécurité de votre environnement numérique est crucial. Parmi la myriade d’outils utilisés pour renforcer les défenses des sites Web et des applications, la politique de sécurité du contenu (CSP) se démarque comme l’unique gardien, travaillant en coulisse pour aider à se protéger contre un éventail de menaces multiples.

Le CSP existe depuis 2004 (quand on l’appelait Restrictions de contenu) et a actuellement un actif document de travail du niveau 3. Pour faire court, CSP est une norme de sécurité qui permet de contrecarrer les activités malveillantes telles que scripts intersites (XSS), détournement de clic et injection de données attaques. Mais pourquoi devrions-nous, en tant que développeurs sur le Web, prêter attention à cet aspect apparemment technique de la sécurité Web ?

Se défendre contre les attaques par injection

Les attaques XSS réussissent si une application Web ne dispose pas d’une validation ou d’un encodage suffisant. Le navigateur ne peut pas détecter si le script malveillant n’est pas digne de confiance et lui accorde l’accès aux cookies, jetons de session, etc. De plus, le script malveillant peut manipuler et réécrire le HTML contenu sans détection.

À la base, CSP est une norme de sécurité du navigateur qui aide à lutter contre de telles attaques par injection. Alors que les attaques XSS compromettent les données des utilisateurs et compromettent l’intégrité de l’application, CSP agit comme un gardien, dictant quelles sources de scripts et de contenu sont jugées fiables et doivent être exécutées. Cela permet uniquement aux scripts autorisés de s’exécuter. Comme niveau de protection ultime, les sites qui visent à ne jamais autoriser les scripts peuvent interdire globalement l’exécution de scripts.

Restreindre le chargement des ressources

L’un des principaux atouts de CSP réside dans sa capacité à contrôler et à restreindre le chargement des ressources externes, contribuant ainsi à atténuer les risques associés à l’injection de données et à la diffusion de contenu non autorisé. Le HTTP Content-Security-Policy l’en-tête de réponse permet aux administrateurs du site Web de contrôler les ressources que l’agent utilisateur est autorisé à charger sur une page.

À quelques exceptions près, les politiques impliquent principalement la spécification des origines des serveurs et des points de terminaison des scripts. Pensez à une page qui télécharge et affiche des images : elle pourrait autoriser des images de n’importe où mais limiter une action de formulaire à un point de terminaison spécifique. En définissant et en appliquant des politiques sur les types de ressources qu’une page Web peut charger, le CSP réduit la surface d’attaque, rendant plus difficile pour les acteurs malveillants d’exploiter les vulnérabilités liées au chargement des ressources.

Naviguer dans les directives politiques

CSP fonctionne via un ensemble de directives, chacune servant un objectif spécifique dans la définition de la posture de sécurité d’une application Web. Depuis script-src à style-srcces directives permettent aux développeurs d’affiner les origines à partir desquelles différents types de contenu peuvent être chargés en toute sécurité.

L’élaboration d’une politique CSP bien définie implique un équilibre méticuleux, permettant la fonctionnalité nécessaire tout en interdisant les risques de sécurité potentiels. Une politique solide devrait englober soit un default-src ou script-src directive pour contrecarrer l’exécution de scripts en ligne et empêcher l’utilisation de eval().

De même, incorporer un default-src ou style-src est cruciale pour limiter l’application des styles en ligne, qu’ils proviennent d’un <style> élément ou un attribut de style. Pour lire plus loin, consultez cette liste complète des directives politiques.

Atténuer les risques de violation de données

L’un des principaux rôles du CSP est d’agir en tant que gardien contre les tentatives d’exfiltration de données. En aidant à empêcher l’exécution de scripts non autorisés et en contrôlant le chargement des ressources, CSP constitue une barrière contre les tentatives de siphonnage d’informations sensibles. Cela inclut une assistance pour la protection des informations d’identification des utilisateurs, des données personnelles, des activités financières et d’autres informations critiques qui, si elles sont compromises, pourraient entraîner de graves violations de données, envoyant une onde de choc dans tous les secteurs.

CSP style-src La directive étend sa portée protectrice en restreignant l’application de styles en ligne à partir des attributs de style. Cela permet d’empêcher les attaquants de manipuler la présentation visuelle du contenu pour dissimuler ou modifier des données. En contrôlant la manière dont les styles sont appliqués, CSP contribue à l’intégrité globale de la page Web, contribuant ainsi à minimiser le risque de falsification des données.

Adopter l’évolution de la sécurité

Dans le paysage en constante évolution de la cybersécurité, où de nouvelles menaces font surface avec une créativité constante, le CSP s’impose comme un mécanisme de défense adaptatif. Sa nature évolutive le maintient à l’avant-garde de la protection des applications Web contre les menaces émergentes.

CSP est conçu pour prendre en charge les mises à jour dynamiques de ses politiques. Cette flexibilité permet aux développeurs Web et aux professionnels de la sécurité de s’adapter rapidement à l’évolution des paysages de menaces en intégrant des renseignements sur les menaces en temps réel et en ajustant les directives politiques en conséquence. CSP intègre les dernières normes de sécurité et les meilleures pratiques, aidant ainsi à faire face aux nouvelles menaces à mesure qu’elles émergent.

Les mesures de protection appliquées par CSP sont synchronisées avec les dernières capacités de sécurité des navigateurs, créant ainsi un écosystème de défense amélioré, mais le plus grand aspect positif de CSP réside dans les efforts de collaboration de la communauté de sécurité Web.

Les développeurs Web, tout en reconnaissant les avantages du CSP en matière de sécurité, seront probablement confrontés à plusieurs défis (comme cela se produit dans la vraie vie de programmation) lors de sa mise en œuvre et de son utilisation.

Équilibre: L’élaboration d’une politique CSP offrant le bon équilibre entre sécurité et fonctionnalité peut s’avérer délicate. Des politiques trop restrictives peuvent entraver l’exécution de scripts légitimes, affectant ainsi la fonctionnalité de l’application Web. Il est impératif d’analyser et de comprendre soigneusement les exigences de l’application pour créer des politiques qui autorisent les scripts essentiels tout en préservant la sécurité.

Refactorisation : De nombreuses applications Web existantes s’appuient fortement sur des scripts et des styles en ligne, d’où la nécessité de refactoriser le code. Autoriser tous les scripts en ligne est considéré comme un risque de sécurité, il est donc recommandé d’utiliser plutôt une source occasionnelle ou une source de hachage. Néanmoins, utilisez nonce uniquement dans les cas où il n’existe aucun autre moyen d’utiliser un script en ligne ou un contenu de style non sécurisé.

Compatibilité du navigateur : La prise en charge du navigateur pour CSP peut varier, ce qui entraîne des incohérences dans la manière dont les stratégies sont appliquées. Il est plus que recommandé de tester que les politiques CSP sont compatibles avec les principaux navigateurs et disposent d’un mécanisme de secours pour les navigateurs avec une prise en charge CSP limitée.

Dépendances tierces : L’intégration de bibliothèques ou de dépendances tierces est toujours un défi, surtout si elles utilisent des scripts en ligne ou violent la politique CSP définie. Vérifiez-les pour la compatibilité CSP et/ou recherchez des alternatives avec des modifications par cas. L’utilisation de noms occasionnels ou de hachages peut également aider à gérer ces dépendances.

Débogage : Plus une bonne pratique qu’un défi, utilisez les messages de la console du navigateur et les en-têtes de sécurité pour déboguer les violations CSP.

Éducation: Permettre à l’ensemble de l’équipe de développement de comprendre l’importance du CSP et de suivre les meilleures pratiques peut s’avérer un obstacle, tout comme l’adaptation des politiques CSP à l’évolution des menaces de sécurité. Proposer des formations complètes, procéder à des révisions de code, intégrer les pratiques CSP dans le flux de développement et réviser et mettre à jour régulièrement les politiques CSP peuvent favoriser une culture axée sur la sécurité.

Progress donne la priorité à la politique de sécurité du contenu

Citant Richard Barretto, responsable de la sécurité de l’information de Progress :

Progress accorde la plus haute importance à la sécurité de nos produits afin de mieux protéger nos clients et leurs systèmes ; et tu peux en savoir plus sur notre processus de correction des vulnérabilités et de notification aux clients [here]. Nous utilisons une variété de procédures et d’outils pour identifier rapidement les vulnérabilités, y remédier dès que possible et communiquer l’urgence aux clients d’appliquer des mises à niveau logicielles.

Progrès Bibliothèques d’interface utilisateur Telerik et Kendo aider les développeurs à créer des expériences utilisateur plus sécurisées, destinées aux organisations qui doivent suivre des normes de sécurité strictes. Que ce soit pour le domaine de développement .NET ou JavaScript, les bibliothèques de composants d’interface utilisateur respectives sont conformes au CSP, fournissant des mises à jour régulières et une prise en charge de la configuration.

Interface utilisateur Telerik pour Blazor

Ces directives politiques du CSP permettent au Interface utilisateur Telerik pour Blazor les composants doivent ressembler et fonctionner comme prévu. Vous pouvez supprimer le domaine Telerik ou font-src si vous n’utilisez pas notre CDN ou nos icônes de police :

<meta http-equiv="Content-Security-Policy" content="
  script-src 'self' https://blazor.cdn.telerik.com;
  style-src 'self' 'unsafe-inline' https://blazor.cdn.telerik.com;
  img-src 'self' data:;
  font-src 'self' data:;
" />

Dans l’amélioration la plus récente, les styles d’icônes de police et la police personnalisée WebComponentsIcons sont déplacés vers deux fichiers distincts supplémentaires. Cela évitera d’avoir à définir font-src data: même lorsque vous utilisez des icônes de police. Apprenez-en plus sur CSP dans Blazor ici.

Interface utilisateur Kendo pour jQuery

Avec le mode CSP strict activé dans Interface utilisateur Kendo pour jQueryces fonctionnalités du navigateur sont désactivées par défaut :

• JavaScript en ligne, tel que <script></script>ou les attributs d’événement DOM, tels que onclick, sont bloqués. Tout le code de script doit résider dans des fichiers distincts servis à partir d’un domaine répertorié en toute sécurité.
• Évaluation dynamique du code via eval() et des arguments de chaîne pour les deux setTimeout et setInterval sont bloqués.

Depuis début 2023, les composants Kendo UI pour jQuery ont résolu (réécrit pour abandonner l’utilisation du eval() et new Function() appels) le unsafe-eval directif. À la seule exception du tableur.

En savoir plus sur le CSP dans Kendo UI pour jQuery ici. Et le guide de démarrage montre comment définir des modèles CSP fonctionnels sur une seule ligneaussi spécifier des modèles CSP avec des opérations simples et logique complexeainsi que convertir les modèles existants en modèles compatibles CSP.

Interface utilisateur Telerik pour ASP.NET Core et ASP.NET MVC

Le code suivant montre comment activer le mode CSP strict pour Interface utilisateur Telerik pour ASP.NET Core et Interface utilisateur pour ASP.NET MVC:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src 'self'; script-src 'self' https://kendo.cdn.telerik.com https://code.jquery.com/; style-src 'self' https://kendo.cdn.telerik.com;" />

Dans l’amélioration la plus récente, le unsafe-inline le mot-clé n’est plus requis dans le style-src sauf dans les composants Editor, ReponsivePanel, GridLayout et StackLayout. Le rendu de ces composants sera amélioré pour assurer la compatibilité avec une politique stricte de sécurité du contenu. En savoir plus sur CSP pour l’interface utilisateur Telerik pour ASP.NET Core et sur CSP pour Telerik UI pour ASP.NET (Telerik UI pour ASP.NET MVC) respectivement..

KendoReact, Kendo UI pour Vue et Kendo UI pour Angular

Ces directives politiques du CSP permettent au KendoRéagir et Interface utilisateur Kendo pour Vue les composants doivent ressembler et fonctionner comme prévu. Plus d’informations sur le sujet peuvent être trouvées ici pour KendoReact et ici pour Kendo UI pour Vue.

Interface utilisateur Kendo pour angulaire propose un exemple d’application sur le dépôt public GitHub:

<meta http-equiv="Content-Security-Policy" content="
  style-src 'self' 'unsafe-inline' https://kendo.cdn.telerik.com;
  style-src-elem 'self' 'unsafe-inline' https://kendo.cdn.telerik.com;
  img-src 'self' data:">

Plus récemment, à titre d’amélioration, les icônes de police qui étaient auparavant disponibles immédiatement sont désormais accessibles via le lien CDN. Avec cela, toutes les icônes utilisées dans les composants sont des icônes SVG. Si une mise à jour de version n’est pas possible et que vous utilisez des icônes de police, vous devez ajouter la configuration CSP suivante :

font-src 'self' data:;

Interface utilisateur Telerik pour ASP.NET AJAX

Pour Interface utilisateur Telerik pour ASP.NET AJAXje suggère de revoir notre une documentation complète sur le sujet ici.

Conclusion

C’est ça. N’oubliez pas : améliorez votre cybersécurité un clic à la fois ! Bon codage !

Ce message a été préparé par Petar Grigorov à titre personnel. Les opinions ou représentations exprimées ici appartiennent à l’auteur et ne reflètent pas nécessairement les vues de Progress Software Corporation, ou de l’une de ses sociétés affiliées ou filiales. Toute responsabilité concernant les actions prises ou non sur la base du contenu de cet article est expressément déclinée. Le contenu de cette publication est fourni « tel quel », sans aucune garantie que le contenu est exempt d’erreurs.