En janvier 2022, la boutique en ligne de Segway a subi une attaque sur la chaîne d'approvisionnement web — souvent appelée attaque Magecart. Dans ce type d'attaque, du code JavaScript malveillant est injecté et se charge côté client, sous forme de scripts tiers.
De nombreux outils courants fonctionnent comme des scripts tiers : analytics, captchas, et bien d'autres. Mais ce vecteur peut aussi être exploité à des fins malveillantes, comme ce fut le cas ici.
Dans cette attaque contre Segway, leur boutique est hébergée sur Magento. Les attaquants ont ciblé des vulnérabilités dans le CMS lui-même ou dans l'un des plugins installés sur le site Segway. Après avoir compromis le système, ils ont ajouté du JavaScript qui semblait afficher le copyright du site, mais qui servait en réalité à charger un favicon externe.
À l'intérieur de ce fichier favicon se trouvait un domaine malveillant : booctstrap[.]com. Comme on peut le voir sur cette image publiée par Malwarebytes, qui a révélé l'attaque :
Ce domaine chargeait le code JavaScript tiers malveillant, dont l'objectif était de capturer les données de carte bancaire des utilisateurs.
Comme on l'a vu plus récemment avec l'attaque Polyfill de 2024.
La mauvaise approche pour se protéger
Les flux de menaces (threat feeds) restent la solution la plus utilisée pour répondre à ce problème, mais ce n'est pas l'approche idéale selon nous. Par nature, ils ne peuvent pas détecter ce qu'ils ne connaissent pas encore. Les attaquants enregistrent un nouveau domaine et, sans modifier une seule ligne de code, l'attaque reprend. Pendant des jours, voire des semaines, jusqu'à ce qu'elle soit à nouveau détectée et que les registres des flux de menaces soient mis à jour.
cside a été conçu pour stopper ces attaques sur la chaîne d'approvisionnement web avant qu'elles ne se produisent.
En faisant transiter ces scripts tiers par un proxy et en analysant l'intégralité du code avant son chargement, nous détectons les codes malveillants comme dans cet exemple. Nous les bloquons, empêchant ainsi tout impact sur l'utilisateur, et alertons le propriétaire du site d'une attaque potentielle.
De plus, nous sauvegardons le code des scripts afin que le propriétaire du site puisse le consulter après l'incident et résoudre le problème à la source.
Ces attaques côté client sont encore trop peu prises au sérieux. Si d'autres mesures de sécurité échouent, comme ce fut le cas chez Segway, cette attaque aurait pu être détectée à temps. En surveillant précisément ce qui se passe dans le navigateur de l'utilisateur, l'exfiltration de données aurait dû être identifiée et bloquée.
Réglementation
Comme le montre ce cas, le e-commerce est souvent une cible de choix. La réglementation rattrape son retard : PCI DSS 4.0 impose désormais la surveillance des scripts tiers sur les pages de paiement (depuis mars 2025). Si nous saluons cette avancée, nous vous encourageons à étendre cette surveillance à toutes les pages de votre site. En avril 2024, nous avons expliqué en détail pourquoi ne pas le faire expose encore votre site à des risques significatifs.
Outre les autres problèmes évoqués dans cet article, des acteurs malveillants pourraient exploiter des scripts compromis sur votre site pour détourner des sessions utilisateur, usurper des identités et effectuer des actions non autorisées — contournant potentiellement l'authentification à deux facteurs et, par ce biais, la protection de votre portail de paiement.
Vous pouvez utiliser cside pour surveiller les scripts sur toutes vos pages et être en conformité avec cette partie de PCI DSS 4.0. Et vous pouvez protéger votre site contre ce type d'attaques grâce à cside.
