En bref : risque de ne protéger que les pages de paiement sous PCI DSS
- Conformité n'est pas couverture : PCI DSS 4.0 n'impose la surveillance des scripts que sur les pages de paiement, donc les fournisseurs échantillonnent volontiers 10% des sessions sur une poignée d'URL et appellent cela de la conformité, laissant les pages de connexion, KYC et compte ouvertes à la même classe de scripts tiers.
- Chaque page, chaque session : Une dépendance hébergée sur CDN compromise a planté quatre backdoors distinctes sur environ 1 000 sites simultanément; cside s'insère entre le tiers et l'utilisateur sur chaque page, offre une visibilité complète des scripts sur 100% des sessions et améliore souvent la performance via le cache.
- Avant de signer : Avant votre prochaine signature PCI DSS 6.4.3, décidez si le XSS sur les pages hors paiement, le détournement de session d'utilisateurs authentifiés par MFA et les attaques de supply chain sur les scripts annexes entrent dans le périmètre de votre programme de sécurité web.
Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
PCI DSS 4.0 est là. D'ici mars 2025, il impose que les portails de paiement disposent d'un moyen d'autoriser chaque script sur les pages de paiement. Les sites web doivent tenir un inventaire de tous les scripts (sur ces portails de paiement au moins) et garantir leur intégrité. Vous devez désormais détecter et répondre aux modifications non autorisées sur les pages de paiement, y compris les changements d'en-têtes HTTP et de contenu de page. Les organisations doivent vérifier ces configurations au moins une fois tous les sept jours ou selon leur évaluation d'analyse de risque.
Consultez les exigences complètes ici.
Un autre point important à retenir : PCI DSS 4.0 encourage désormais un passage des audits annuels à une surveillance continue de la sécurité, ce qui implique des révisions et mises à jour régulières des composants système et des logiciels.
Enfin !
À l'heure actuelle, seuls les portails de paiement sont tenus de disposer d'un système pour contrôler les JavaScript tiers. C'est pourquoi bon nombre de nos concurrents (lisez ce que nous pensons d'eux ici) limitent leurs services à quelques pages seulement. Certains vont même jusqu'à échantillonner les sessions, de sorte que seulement 10% des sessions sont protégées.
Mais c'est chercher les ennuis.
Pourquoi vous devriez protéger toutes les pages
Il existe toujours un risque de violation de données si vous ne sécurisez pas toutes les pages.
Des acteurs malveillants pourraient utiliser des scripts compromis sur d'autres parties de votre site pour détourner des sessions utilisateur. Cela leur permettrait d'usurper l'identité d'utilisateurs légitimes et d'effectuer des actions non autorisées, pouvant même contourner certaines formes d'authentification à deux facteurs. Cela pourrait potentiellement déjouer votre protection des scripts tiers sur les portails de paiement.
Un autre domaine que vous laisseriez exposé au risque est celui des vulnérabilités de type Cross-site scripting (XSS). Elles permettent aux attaquants d'injecter des scripts malveillants dans des pages web consultées par d'autres utilisateurs. Si seul le portail de paiement est protégé, d'autres pages pourraient être exploitées pour exécuter des attaques XSS, compromettant quand même les données et la vie privée des utilisateurs.
Les attaques de la chaîne d'approvisionnement ne sont pas non plus totalement bloquées. Les scripts tiers constituent un vecteur courant pour ce type d'attaques. Si des attaquants compromettent un fournisseur ou un script utilisé sur l'ensemble de votre site, concentrer les protections uniquement sur le portail de paiement n'empêchera pas l'exploitation via d'autres intégrations tierces. Un seul script hébergé sur CDN à partir de cdn.csyndication[.]com a été utilisé pour installer quatre backdoors distinctes sur 1 000 sites web simultanément : une seule dépendance compromise, quatre points d'entrée pour l'attaquant.
Les vulnérabilités d'exécution de code à distance (RCE) et d'injection de commandes représentent des risques de sécurité importants qui soulignent davantage la nécessité de sécuriser toutes les pages, et pas seulement les zones critiques comme les portails de paiement. Le RCE permet aux attaquants d'exécuter du code arbitraire sur votre serveur, pouvant mener à une compromission totale du système. Cela peut se produire via une gestion non sécurisée des entrées utilisateur, comme l'évaluation de code téléchargé par des utilisateurs ou injecté via des champs de formulaire.
Les vulnérabilités d'injection de commandes surviennent lorsque des entrées utilisateur non sécurisées sont exécutées comme des commandes système, notamment via des entrées JavaScript mal assainies. Cela peut permettre aux attaquants de manipuler les actions du serveur ou d'accéder aux bases de données backend, entraînant des modifications non autorisées ou le vol de données.
Enfin, l'ingénierie sociale et le phishing constituent une menace bien réelle. Des attaquants pourraient modifier le contenu ou rediriger les utilisateurs vers des sites malveillants, les incitant à fournir des informations sensibles.
Autres vulnérabilités
Même si vos portails de paiement sont protégés et que la protection fonctionne, les autres pages restent exposées au risque d'être compromises.
Si cela se produit, vous courez toujours le risque de perdre la confiance des utilisateurs et de faire face à des implications juridiques ou réglementaires, notamment en ce qui concerne les lois sur la protection des données comme le RGPD ou le CCPA. Les dommages en termes d'amendes ou d'atteinte à la réputation sont difficiles à quantifier. Ils sont pourtant bien réels.
Alors faites-le bien, dès maintenant
Tout comme les règles PCI DSS 4.0, nous encourageons également tout propriétaire de site à adopter une surveillance continue de la sécurité. Et j'espère que nous avons démontré que le faire sur toutes les pages est la meilleure approche.
Le niveau gratuit de cside rend votre site conforme à PCI DSS en ce qui concerne les scripts tiers, et il fonctionne sur toutes les pages. Notre approche est toutefois différente de celle de la concurrence. Notre script réécrit les sources des autres scripts de votre site pour que cside les récupère et les analyse et effectuer certaines détections côté navigateur. cside s'insère ainsi dans le flux de la requête entre l'utilisateur et le script tiers, sans latence supplémentaire, et améliore même parfois les performances grâce à la mise en cache des scripts statiques.
Cela offre une visibilité totale sur les scripts servis, sur 100% des sessions et sur toutes les pages, vous protégeant ainsi que vos utilisateurs.
Si vous souhaitez en savoir plus sur ce qui distingue notre approche, rendez-vous ici.
