Les entreprises savent qu’elles doivent sécuriser leurs scripts côté client. Les politiques de sécurité du contenu (CSP) sont un excellent moyen de le faire. Mais les CSP sont lourds. Une erreur et vous avez une faille de sécurité côté client potentiellement importante. Trouver ces lacunes signifie de longues et fastidieuses heures (ou jours) de révision manuelle du code à travers des milliers de lignes de script sur vos applications Web. Les politiques de sécurité de contenu automatisées peuvent aider à rationaliser le processus de révision du code en identifiant d’abord tous les scripts propriétaires et tiers et les actifs auxquels ils accèdent, puis en générant une politique de sécurité de contenu appropriée pour aider à mieux sécuriser la surface d’attaque côté client.
Il y a peu de développeurs ou de professionnels AppSec qui prétendent aimer déployer des CSP. Tout d’abord, le CSP doit fonctionner pour l’application Web spécifique. Ensuite, l’équipe doit s’assurer qu’elle fournit le niveau de protection approprié. Le CSP ne peut pas non plus entrer en conflit avec des widgets ou plugins existants (ou la décision doit être prise de ne pas déployer le CSP ou de désactiver ces plugins, ce qui peut causer des problèmes dans d’autres domaines, tels que l’engagement client, le marketing et les ventes).
Et puis, lorsqu’un CSP échoue, il y a l’audit redouté pour déterminer le pourquoi et le où.
Le problème d’évitement d’audit CSP (c’est-à-dire éviter les révisions manuelles de code ou la mort par mille scripts) est assez courant. Aujourd’hui, les applications Web côté client contiennent des milliers de scripts, assemblés à partir de plusieurs bibliothèques open source ou d’autres référentiels tiers et de quatrième partie. Peu d’équipes de développement ou de sécurité prennent le temps de conserver un enregistrement détaillé de tous les scripts utilisés dans l’assemblage d’applications Web, y compris leurs fonctions, leurs sources et s’ils ont été mis à jour ou corrigés pour résoudre les problèmes de sécurité connus.
Même lorsque les équipes identifient toutes les sources de scripts tiers, cela ne garantit pas que les scripts sont sûrs. Des problèmes persistants surviennent toujours avec les gestionnaires de packages contenant du JavaScript obfusqué et malveillant utilisé pour collecter des informations sensibles à partir de sites Web et d’applications Web. Dans un exemple récent, des chercheurs ont découvert que des packages malveillants avaient été téléchargés 27 000 fois par des développeurs sans méfiance.
Malheureusement, le problème d’évitement d’audit CSP étend une surface d’attaque déjà importante côté client.
Les problèmes avec les CSP n’ont rien à voir avec leur valeur. Les CSP sont excellents pour fournir des rapports de violation et une optimisation des politiques et aident à découvrir les scripts vulnérables qui conduisent à des attaques par injection JavaScript, des scripts intersites (XSS) et des attaques par écrémage, comme Magecart. Les politiques de sécurité de contenu manuelles sont simplement pénibles à gérer, ce qui signifie que les développeurs peuvent éviter les processus CSP critiques, ce qui entraîne un risque de sécurité accru.
Politiques de sécurité de contenu automatisées aider à gérer les CSP pour mieux protéger la surface d’attaque côté client et supprimer le risque associé à la surveillance manuelle des CSP. En identifiant tous les scripts propriétaires et tiers, les actifs numériques et les données auxquelles ces actifs accèdent, les entreprises peuvent rationaliser le processus de création et de gestion du CSP et améliorer la sécurité globale côté client. Les CSP automatisés sont gérés au niveau du domaine pour un meilleur reporting et un meilleur contrôle des versions.
Les CSP automatisés fonctionnent en explorant un site Web ou une application Web et en initiant des utilisateurs synthétiques pour évaluer comment les scripts fonctionnent sur l’application Web et à quel type de données le script peut accéder. Le système génère ensuite le CSP pour l’aligner sur les besoins de sécurité du site Web ou de l’application Web. Les CSP automatisés fonctionnent également dans l’environnement de production réel, pour émuler des politiques pour des tests rapides (et éviter le déploiement constant de CSP dans un environnement de développement) et se concentrer sur la réduction des violations de politique aussi près que possible de zéro.
Les fonctionnalités supplémentaires d’un CSP automatisé incluent la création de nouvelles politiques après une violation détectée pour permettre des mises à jour rapides et traiter les menaces de sécurité actuelles et l’ingestion de données de journal dans la gestion des incidents et des événements de sécurité (SIEM) et d’autres systèmes de collecte de données basés sur des journaux pour une intégration dans les pratiques de sécurité actuelles. et flux de travail.
Avec des rapports de violation entièrement intégrés, une solution CSP automatisée complète les processus et workflows de sécurité actuels. Il fournit également une prise en charge essentielle des normes réglementaires et de conformité telles que PCI DSS 4.0, HIPAA et autres.
Sécurité Feroot propose DomainGuard, un CSP automatisé et spécialement conçu qui aide les organisations à gérer leur surface d’attaque côté client en simplifiant le processus de gestion des politiques de sécurité du contenu. DomainGuard intègre le signalement des violations aux outils de sécurité existants pour compléter les processus et flux de travail de sécurité actuels et réduire considérablement le temps nécessaire à la création et à la gestion des CSP entre les équipes, les sites Web et les applications Web.
