Les entreprises sont toujours plus nombreuses à créer leurs applications publiques avec des composants et/ou des scripts tiers, en raison de l'agilité qu'offrent ceux-ci durant le processus de développement. Parallèlement à cela, nous avons constaté qu'un nombre croissant d'attaques ciblent les utilisateurs de ces applications.
Dans l'envers du décor, ce phénomène est dû au fait qu'au fil du temps, une partie du code des applications web est désormais chargée dans le navigateur de l'utilisateur, plutôt que côté serveur. Cette évolution expose désormais les utilisateurs à ces composants tiers, et les entreprises qui les utilisent n'ont aucun contrôle direct sur leurs mesures de sécurité. Cette relation entre les scripts tiers, les propriétaires d'applications et les utilisateurs est exploitée pour lancer des attaques contre la chaîne logistique des appareils des utilisateurs.
Dans cet article, nous allons explorer ces nouvelles vulnérabilités et la manière dont les entreprises peuvent y remédier afin de protéger leurs utilisateurs.
Dès 2018 ou peu après, plusieurs attaques très médiatisées contre le client-side d'applications ont causé des préjudices considérables aux entreprises. L'un des cas les plus notables a été celui d'une attaque lancée ciblant les clients de British Airways, au cours de laquelle l'acteur malveillant a non seulement exfiltré des informations de cartes de paiement, mais également les noms et les adresses de 500 000 clients de la compagnie aérienne. L'acteur malveillant a dérobé ces informations en compromettant la sécurité de JavaScript.
Les entreprises qui traitent les paiements de clients sont soumises aux exigences de conformité à la norme Payment Card Industry Data Security Standard (PCI DSS), conçues pour protéger et sécuriser les données des comptes associés aux cartes de paiement.
Souvent, comme dans le cas de British Airways, ces attaques se déroulent à l'insu du propriétaire du site web. Pour remédier à ce problème, la dernière version de la conformité à la norme PCI DSS reconnaît que la menace émergente des attaques client-side nécessite une protection active afin de protéger les détenteurs de cartes de paiement contre le vol des informations de leur carte. La norme PCI Data Security Standard (DSS) 4.0 introduit de nombreuses nouvelles exigences auxquelles tous les commerçants acceptant des règlements par carte de paiement doivent satisfaire, comparée à la version précédente de PCI ; aujourd'hui, toutefois, nous allons nous concentrer sur deux nouvelles exigences liées à la sécurité client-side.
Ces deux nouvelles exigences, 6.4.3 et 11.6.1, peuvent être résumées comme suit :
L'exigence 6.4.3 exige des commerçants qu'ils assurent le suivi et l'inventaire correct des scripts (par exemple, le code JavaScript) utilisés sur les pages de paiement, qu'ils justifient les raisons pour lesquelles ces scripts sont nécessaires et qu'ils assurent que le comportement de leur code est conforme aux attentes.
Pour satisfaire à l'exigence 6.4.3, un en-tête Content Security Policy (CSP) peut être déployé. Les en-têtes CSP constituent une forme de modèle de sécurité positive, qui peut être défini afin d'autoriser l'exécution de certains scripts JavaScripts sur les pages de paiement et de refuser par défaut tout code JavaScript non explicitement autorisé. Un service de surveillance de la page continuellement exécuté peut aider à générer un en-tête CSP et à assurer la vérification continue du contenu de ces scripts, afin de détecter toute menace malveillante.
L'exigence 11.6.1 concerne la notification aux propriétaires de sites web des modifications apportées aux scripts (JavaScript, par exemple) utilisés sur les pages de paiement, comme nous l'avons indiqué ci-dessus, ainsi qu'aux en-têtes HTTP utilisés pour protéger ces scripts, tels que l'en-tête CSP. Selon la manière dont l'en-tête CSP est déployé, les fournisseurs de proxy inverse ou de réseau CDN peuvent détecter les modifications apportées à celui-ci et informer le propriétaire du site web en conséquence. L'association de ces solutions permet de satisfaire à l'exigence 11.6.1.
En répondant à ces deux exigences, les propriétaires de sites web peuvent protéger les données de cartes de paiement enregistrées dans les comptes de leurs utilisateurs contre le vol par des acteurs malveillants, et ainsi, préserver la confiance de leurs utilisateurs et réduire les risques.
Les dépendances JavaScript tierces, ou attaques contre la chaîne logistique, ne constituent pas les seuls vecteurs d'attaque client-side. Certaines dépendances tierces peuvent également faire appel à leurs dépendances, parfois appelées dépendances extérieures (« fourth-party dependency »), qui peuvent être compromises à leur tour.
Ces dernières années, le secteur a pris des dispositions afin de se protéger autant que possible contre les attaques contre la chaîne logistique, et la prise de conscience générale concernant les risques liés à la chaîne logistique est plus importante qu'elle ne l'était il y a cinq ans. Cependant, il existe également d'autres risques client-side auxquels on accorde moins d'attention, et qui ouvrent une surface d'attaque plus vaste.
L'un de ces risques réside dans l'environnement de l'utilisateur, le navigateur utilisé et le système d'exploitation dans lequel s'exécute le navigateur. Lorsqu'un utilisateur consulte un site web, les extensions de navigateur ou tout autre logiciel peuvent injecter directement du code JavaScript dans le site web, et ainsi, modifier les pages web. Bien que toutes ces injections de code JavaScript ne soient pas malveillantes, leurs effets vont de l'injection de publicités au vol potentiel d'informations sensibles.
Un autre exemple est celui des attaques de type Cross-Site Scripting (XSS), lors desquelles un acteur malveillant injecte, dans un site web légitime, du code qui s'exécutera lorsque la victime chargera le site. Du point de vue de la protection client-side, ces injections peuvent ressembler à du code JavaScript servi directement par le propriétaire ou le site web lui-même, où la confiance est supposée par défaut.
Cette liste n'est pas exhaustive, et pour garantir une protection réellement complète, une solution de sécurité client-side doit être en mesure de surveiller tous les scripts de manière égale, quelle que soit leur source, afin d'aider le propriétaire du site web à prendre des décisions bien informées.
En tant que commerçant, si vous acceptez des paiements par carte, vous avez jusqu'au 31 mars 2025 pour mettre en œuvre votre approche de sécurisation de votre environnement client-side conformément à la norme PCI DSS v4.0. Page Shield, la solution de sécurité client-side de Cloudflare, peut faciliter le processus de conformité à ces nouvelles exigences et aux exigences futures.
Au-delà de la protection des pages de paiement, la solution Page Shield de Cloudflare surveille également continuellement l'ensemble de votre site web, en inspectant chaque script par rapport à un modèle d'apprentissage automatique développé et formé en interne, spécialisé dans la catégorisation des attaques Magecart. Elle protège ainsi vos utilisateurs, indépendamment de la manière dont ils interagissent avec votre site web et de l'endroit où ils se trouvent.
Cet article fait partie de notre série consacrée aux nouvelles tendances et évolutions susceptibles d'affecter les décideurs en matière de technologies d'aujourd'hui.
Pour plus d'informations sur la manière de répondre stratégiquement à l'ensemble des exigences de la norme PCI, consultez le livre blanc Une approche stratégique du respect de la conformité PCI DSS 4.0.
Cet article vous permettra de mieux comprendre les points suivants :
Principaux vecteurs d'attaque ciblant l'environnement côté client
Deux nouvelles exigences de conformité PCI
Comment sécuriser les environnements côté client et protéger vos clients
Une approche stratégique du respect de la conformité PCI DSS 4.0
Rationalisez la conformité des données avec des contrôles composables
Page Shield : préservez la sécurité de l'e-commerce et des activités face aux attaques Magecart