En bref : limites du crawler pour l'intégrité des scripts PCI DSS 4.0.1
- Les crawlers ratent le JS dynamique : Les crawlers ressemblent à d'excellents outils de conformité jusqu'à ce qu'on se rappelle que JavaScript est dynamique par conception. Un visiteur synthétique depuis une IP cloud connue qui ne clique jamais, ne scrolle pas et ne se connecte pas est la dernière personne à qui un attaquant montrera la charge malveillante.
- Trop lent, sans blocage : Lors de l'attaque Polyfill, il a fallu plus de 30 heures pour qu'un fournisseur de menaces signale le domaine, et le signalement n'est arrivé qu'après que Namecheap avait déjà retiré le domaine. Un crawler seul ne satisfait pas 6.4.3 car il ne peut pas bloquer les scripts non autorisés, et les vérifications statiques d'URL contre des flux de menaces ne satisfont pas l'exigence d'intégrité de payload de 11.6.1.
- Ajoutez le blocage ou cside : Si vous n'avez qu'un crawler aujourd'hui, ajoutez CSP ou un script côté client capable de bloquer les chargements et d'afficher le contenu, pour que 6.4.3 soit réellement respecté. Si vous voulez une seule solution plutôt que d'en assembler deux, cside analyse chaque script de notre côté et empêche les scripts malveillants d'être servis dès le départ.
Peu de temps ? Découvrez cside PCI Shield. Elle couvre tout ce qui suit en un seul déploiement.
Notre page de comparaison présente un excellent aperçu des différentes approches pour atteindre la sécurité côté client et répondre aux exigences PCI DSS (6.4.3 et 11.6.1).
Notre solution (le méthode Script) surpasse les autres approches dans diverses catégories. Comparons-la au crawler que de nombreux concurrents dans ce domaine utilisent. Les avantages, et les nombreuses lacunes qui accompagnent cette solution.
Dans cet article, nous nous concentrerons sur les sections 6.4.3 et 11.6.1 de PCI DSS 4.0.1. Visitez notre page de comparaison pour obtenir tous les avantages et inconvénients dans un contexte de sécurité complet.
"Une méthode est mise en œuvre pour confirmer que chaque script est autorisé"
6.4.3 Tous les scripts de page de paiement qui sont chargés et exécutés dans le navigateur du consommateur sont gérés comme suit :
Une méthode est mise en œuvre pour confirmer que chaque script est autorisé.
Une méthode est mise en œuvre pour assurer l'intégrité de chaque script.
Un inventaire de tous les scripts est maintenu avec une justification commerciale ou technique écrite expliquant pourquoi chacun est nécessaire.
L'exigence PCI 6.4.3 nécessite un mécanisme pour empêcher le chargement de scripts non autorisés.
Pour éviter toute confusion, la spécification PCI précise également :
Le code non autorisé ne peut pas être exécuté dans la page de paiement telle qu'elle est rendue dans le navigateur du consommateur.
Pour de nombreux GRC, c'est un défi d'allouer des efforts d'ingénierie aux exigences de conformité. Comprendre comment les exigences PCI de sécurité côté client se traduisent en implémentation pratique est souvent là où les équipes se retrouvent bloquées. Certaines solutions peuvent vous faire croire que vous pouvez répondre aux exigences sans implémenter de code ni effectuer d'ajustements. Ce n'est cependant pas correct.
Cette exigence peut être satisfaite de plusieurs façons. Un commerçant peut implémenter une Content Security Policy. La CSP est cependant connue pour être difficile à gérer et à maintenir, mais c'est une solution valide pour répondre à cette exigence.
Un commerçant peut choisir d'utiliser un agent côté client qui bloque certains comportements JS. Cependant, ce n'est pas une solution miracle. Il y a eu divers exemples d'attaques côté client qui ont essentiellement empêché l'agent de sécurité de fonctionner et ont entièrement ou partiellement désactivé sa fonctionnalité, y compris sa capacité de blocage. Par conséquent, testez toujours la solution que vous achetez avec un script côté client écrit par vous-même. Malheureusement, la plupart des ingénieurs JavaScript de niveau intermédiaire ne trouveront pas cela un défi majeur.
Ou, vous pouvez utiliser un service d'analyse de scripts comme cside pour empêcher un script malveillant d'être servi en premier lieu.
Cette ligne spécifique des exigences PCI DSS est facilement négligée mais renvoie à la nature de l'exigence : implémenter des normes de sécurité des cartes de paiement pour empêcher le vol de cartes de crédit à l'entrée.
Les crawlers ne "voient" pas la charge utile réelle et ne captureront pas une attaque sérieuse
Les crawlers fonctionnent en visitant votre site et en indexant les scripts qui se chargent. Détail important, ils agissent comme un utilisateur mais ne sont clairement pas un véritable utilisateur humain. Il existe un certain nombre d'indicateurs simples, provenir de l'adresse IP d'un fournisseur cloud en étant un. C'est un défaut de conception fondamental, car la livraison JavaScript est dynamique par conception. Elle est conçue pour servir différentes versions de scripts en fonction du temps, du user-agent, de la localisation, des plages IP…
Les acteurs malveillants exploitent bien sûr cette dynamique pour éviter la détection. Un crawler est peu susceptible de repérer l'attaque réelle de première main. Par conséquent, le renseignement sur les menaces doit provenir d'autres sources. C'est là que la plupart des solutions achètent des flux de renseignements sur les menaces auprès de fournisseurs. Ces fournisseurs ont cependant tendance à arriver tard. Lorsque l'attaque Polyfill s'est produite, il a fallu plus de 30 heures pour qu'un fournisseur de menaces la signale, même si elle avait une large couverture médiatique. Le domaine n'a été signalé que lorsque Namecheap a déjà supprimé le domaine. Les fournisseurs de flux de menaces ne sont pas non plus spécifiquement à l'affût d'attaques côté client, parfois ils les attrapent mais les acteurs malveillants savent également éviter leurs chercheurs. La plupart de leurs renseignements sur les attaques côté client proviennent des médias sociaux.
Nous avons établi qu'un crawler ne peut pas garantir que la charge utile qu'il récupère est celle que l'utilisateur a reçue, mais imaginons une seconde que c'est le cas. La plupart des scripts malveillants sont chargés en tant que sous-requêtes basées sur des déclencheurs utilisateur : l'utilisateur clique, fait défiler, se connecte ou ajoute quelque chose à un panier.
Si un script malveillant est injecté suite à une interaction utilisateur, le crawler ne verra pas le script malveillant à moins qu'il n'effectue cette interaction utilisateur. C'est assez impossible à faire car chaque page peut avoir des capacités d'interaction infinies. Exemple : ne faire la requête vers le script malveillant que si une série de boutons est pressée 5 fois, défilée d'une fenêtre complète vers le bas, le navigateur n'a pas les outils de développement ouverts… Le "crawling synthétique" prétend résoudre ce problème, mais il ne le peut vraiment pas pour des raisons techniques évidentes.
Si vous appliquez une approche d'analyse de sécurité statique à un problème dynamique, vous ne traitez pas le problème de sécurité.
Alors tous les crawlers sont-ils inutiles ?
Non. Le concept fondamental d'un crawler est défectueux mais si un fournisseur ne s'attend pas à voir la charge utile malveillante de première main via le crawler mais est capable de signaler le script parent via d'autres méthodes de détection actives en dehors du crawler, il peut toujours traiter les problèmes de sécurité à un niveau suffisamment élevé (pour certains). Par exemple : le crawler cside utilise les renseignements sur les scripts malveillants reçus via les sites web analysés d'autres clients cside. En conséquence, les charges utiles malveillantes sont détectées sur d'autres sites et les objets parents qui ont injecté ces scripts malveillants sont signalés, si le crawler a reçu la charge utile propre mais sait que ce script est compromis via d'autres sites, cela conduira à une alerte.
"Attendez, mais je vois toutes ces données intéressantes dans leur tableau de bord ?"
C'est certainement une valeur ajoutée. Les crawlers peuvent vous donner une compréhension de certains des comportements de certains des scripts sur votre site en remplissant le tableau de bord, fournissant des informations intéressantes. Mais tout script malveillant saura comment ne pas apparaître dans ces tableaux de bord. Généralement, les gens ont un biais pour les objets brillants. Un tableau de bord brillant avec beaucoup d'informations intéressantes dessus, amène les gens à penser que les mêmes informations seront disponibles un mauvais jour. Ce n'est cependant pas le cas.
Pourquoi envisager un crawler du tout ?
La sécurité consiste à superposer les couches. Ajouter plus de solutions pour surveiller les mêmes problèmes est généralement une bonne chose.
Ils sont relativement légers à déployer (généralement), et vous donnent une carte de base des scripts présents sur votre site à un moment donné. Pour une équipe de conformité effectuant des vérifications périodiques ou des audits qui ne sont pas susceptibles au PCI DSS, c'est utile.
Ils fournissent également une visibilité sur les changements statiques. Disons si une nouvelle URL de script apparaît soudainement ou si une existante disparaît. À cet égard, c'est un pas en avant par rapport à la CSP qui ne fournit aucune visibilité sur la charge utile. Lisez à propos des limitations des CSP ici. Un crawler peut vous aider à tenir un inventaire des scripts (partie de 6.4.3) et à visualiser les en-têtes de sécurité lorsqu'il crawle (PCI 11.6.1) mais il ne peut pas empêcher le chargement de scripts non autorisés. Vous devriez au moins encore ajouter une CSP ou un agent. Donc n'achetez un crawler que s'il vous donne également un point de terminaison CSP ou un agent.
Un crawler seul ne peut pas vous fournir la conformité PCI DSS.
