Risques de sécurité liés aux scripts JavaScript tiers

Lors de leur présentation sur la sécurité web à SnykCon 2020, Liran Tal et Eric Graham ont abordé les enjeux de sécurité frontend liés à la surface d’attaque frontend. Ils ont présenté les risques découlant des vulnérabilités de sécurité présentes dans les dépendances tierces, puis ont élargi la réflexion aux risques potentiels liés aux scripts tiers ajoutés à des fins marketing, comme Google Tag Manager.

Dans cet article, nous examinons les risques de sécurité liés aux scripts marketing ajoutés à un site web, comme les services de tests A/B, Google Analytics et d’autres, et présentons des solutions pour les atténuer.

Play Video: Securing Front-end Attack Surfaces - Eric Graham and Liran Tal

Quels sont les risques liés aux scripts tiers pour la sécurité web ?

Pour répondre à cette question, Eric Graham examine dans la vidéo, étape par étape, l’ajout de code tiers aux applications web et aux sites web statiques. Il montre dans quelle mesure ceux-ci intègrent du code source provenant de différents fournisseurs et responsables de projets open source.

Comme vous pouvez le constater, le code écrit par les développeurs de votre équipe ne représente qu’une petite partie de l’ensemble du code fourni à vos clients. À côté, on trouve des scripts dédiés aux tests A/B ou aux tests d’ergonomie, ainsi qu’au marketing et aux ventes, par exemple pour segmenter les utilisateurs ou optimiser le tunnel de vente.

Comment et pourquoi ajoute-t-on des scripts tiers à un site web ?

Pour ne rien arranger, ces scripts sont le plus souvent ajoutés par les équipes marketing et les responsables web, en dehors du cycle de développement logiciel et du pipeline CI/CD. Ils échappent ainsi complètement aux revues de code et aux tests des développeurs. Les logiciels utilisés à cette fin sont appelés gestionnaires de balises. Google (GTM) et Adobe, avec Launch (qui a succédé à Dynamic Tag Manager ou DTM), comptent parmi les fournisseurs les plus connus.

Ces gestionnaires de balises chargent à leur tour d’autres scripts, ouvrant ainsi encore plus de connexions HTTP vers différents domaines. Ces domaines pourraient être piratés et servir à déployer des logiciels malveillants. C’est ce qu’on appelle le malvertising.

Les spécialistes du marketing et les ingénieurs en analytique utilisent régulièrement des scripts JavaScript tiers pour étendre les fonctionnalités d’un site web, favoriser la croissance, segmenter les utilisateurs et optimiser le tunnel de vente. GTM et l’outil Launch d’Adobe en sont des exemples populaires, et constituent une nette amélioration par rapport à leur prédécesseur, Dynamic Tag Manager (DTM).

Compte tenu de l’impact de ces scripts sur les activités marketing, les équipes marketing produit et analytique privilégient l’expérimentation rapide et l’injection de scripts supplémentaires dans un site web ou une application web.

Ces scripts marketing tiers font-ils l’objet d’un audit de sécurité ?

Ces équipes pensent-elles à supprimer les scripts tiers de l’application web une fois qu’elles n’en ont plus besoin ? Ce n’est souvent pas garanti, et cette étape peut passer entre les mailles du filet. Vous risquez donc d’exécuter du code non fiable sans même le savoir !

L’ajout de scripts JavaScript tiers à une page web contourne entièrement le pipeline DevOps ainsi que les processus et les consignes de sécurité mis en place pendant le développement.

De plus, puisqu’ils sont injectés directement dans le DOM, ces tiers ont accès à toutes les fonctionnalités dont disposent également vos développeurs. Ils peuvent ainsi causer des dégâts considérables chez vos clients.

Les médias ont fait état de plusieurs incidents de sécurité liés à l’injection malveillante de scripts JavaScript tiers dans des applications web, et ont même révélé comment des pirates dissimulent un script de vol de données dans les fichiers CSS d’un site web. Ces affaires font suite à d’autres incidents de sécurité liés à des scripts Magecart intégrés dans des favicons, des messages de chat en direct et des boutons de partage sur les réseaux sociaux.

Peut-on résoudre les problèmes de sécurité liés au JavaScript tiers ?

Pour répondre à nos enjeux de sécurité JavaScript, explorons de meilleures façons d’intégrer du JavaScript tiers dans le code d’un site web afin d’atténuer ou de réduire les risques de sécurité.

Approches techniques

Une option consiste à intégrer le JavaScript tiers dans un iFrame, puis à le verrouiller à l’aide des attributs allow et/ou sandbox. Attention : cela peut empêcher le fonctionnement prévu.

Une autre solution consiste à appliquer l’intégrité des sous-ressources (SRI), mais le fournisseur des scripts doit alors communiquer les valeurs de hachage de leurs bibliothèques. Or, le contenu est souvent personnalisé et donc dynamique.

Le groupe de travail du W3C a proposé une norme pour la collecte de mesures sur le comportement des utilisateurs et d’autres besoins dans le document suivant : Customer Experience Digital Data Layer 1.0. La section 6.11 précise quels groupes de scripts tiers peuvent accéder aux différents types de données. Toutefois, l’application de ces règles est laissée à la partie responsable de la couche de données.

Approches culturelles

Les approches techniques ayant leurs limites, examinons les approches culturelles.

Le marketing devrait-il être intégré au cycle de développement logiciel et être tenu de soumettre ses modifications via un pipeline DevOps ? Une collaboration avec les ingénieurs est idéale, mais les priorités métier et la communication entre les services compliquent sa mise en place.

Surveillez-vous activement toutes les requêtes HTTP effectuées par votre application web ou votre domaine ? Vous pouvez utiliser des outils comme Page Integrity Manager d’Akamai ou l’outil web gratuit et open source WebPageTest pour surveiller les requêtes HTTP et même intégrer cette surveillance à votre pipeline d’intégration continue (CI).

Enfin, la culture d’entreprise peut contribuer à renforcer la sensibilisation à la protection de la vie privée chez les ingénieurs et les spécialistes du marketing qui mettent en place des outils d’analytique et d’autres widgets JavaScript tiers.

Conclusion

La surface d’attaque frontend est vaste. Elle englobe le code source de votre application web et ses dépendances, mais aussi les scripts tiers ajoutés en dehors du processus de développement.

En complément des approches techniques, faites évoluer la culture de votre organisation pour renforcer votre sécurité sur Internet.

Pour en savoir plus, consultez ces ressources :

1. Découvrez la tendance de l’architecture événementielle dans l’article de blog de Jim Gordon : https://jimalytics.com/tag-management/the-event-driven-data-layer.

2. Consultez le blog de Jan Exner à l’adresse https://webanalyticsfordevelopers.com, où il explique l’analytique web aux développeurs, dans des termes qui leur parlent.

3. Regardez la présentation Securing Frontend Attack Surfaces de SnykCon, qui détaille l’ampleur de ce risque de sécurité.