Corriger un jQuery ou une autre bibliothèque JavaScript obsolète qui fait échouer votre scan ASV PCI
CentralCSP Team ·
Dernière mise à jour:
Votre scan PCI trimestriel revient en échec, et le constat porte sur un jQuery obsolète, ou une autre bibliothèque JavaScript, sur une page que vous pensiez à jour. La correction est en général rapide une fois que vous savez quelle copie la page charge et d'où elle vient. Cet article explique pourquoi le scan échoue, comment trouver la copie, vers quelle version passer, comment relancer le scan et quand une contestation est la bonne réponse.
Pourquoi une bibliothèque JavaScript obsolète fait échouer un scan ASV PCI
PCI DSS impose à de nombreux commerçants un scan de vulnérabilités externe trimestriel par un Approved Scanning Vendor (ASV), une société référencée par le PCI Security Standards Council. L'ASV Program Guide fixe la règle : tout composant portant une vulnérabilité notée CVSS 4.0 ou plus fait échouer le scan, sauf si vous la corrigez ou si l'ASV accepte une contestation.
C'est pour cela que jQuery revient si souvent. Les avis jQuery courants sont tous notés 6.1 sur la National Vulnerability Database (NVD) :
| CVE | Score CVSS de base NVD | Corrigée en |
|---|---|---|
| CVE-2020-11022 | 6.1 | 3.5.0 |
| CVE-2020-11023 | 6.1 | 3.5.0 |
| CVE-2019-11358 | 6.1 | 3.4.0 |
| CVE-2015-9251 | 6.1 | 3.0.0 |
Chacun dépasse 4.0, donc une page qui charge un jQuery antérieur à 3.5.0 échoue au scan pour ces seuls avis. La même règle vaut pour toute autre bibliothèque : une vieille copie de Bootstrap, Lodash, Moment.js ou AngularJS avec une CVE notée 4.0 ou plus échoue de la même façon. Pour le détail de chaque avis jQuery et des versions concernées, lisez Quelles versions de jQuery sont vulnérables.
Le Program Guide liste aussi des conditions qui font échouer un scan quel que soit leur score, dont les systèmes d'exploitation qui ne sont plus pris en charge. La façon dont votre ASV traite une branche de bibliothèque en fin de vie dépend de chaque prestataire : demandez au vôtre, et prévoyez de toute façon de quitter les branches en fin de vie comme jQuery 1.x et 2.x ou AngularJS.
Trouver la copie chargée par la page
Le constat cite un hôte et souvent une URL. Avant de mettre à jour quoi que ce soit, identifiez la copie de la bibliothèque que cette page charge, car la version de votre propre bundle n'est souvent pas celle que le scanner a vue. Les vieilles copies viennent :
- D'un plugin ou d'un thème qui embarque son propre jQuery, courant sur WordPress et les autres CMS.
- D'un widget fournisseur (chat, avis, paiement, analytics) qui charge sa propre copie.
- D'une ligne CDN dans un vieux template qui fige une version que personne n'a mise à jour.
- D'une deuxième copie chargée à côté de la version actuelle, si bien que mettre à jour la première ne change rien.
Passez la page citée par le constat dans l'analyseur de technologies. Il liste chaque bibliothèque avec sa version, les CVE connues qui touchent cette version, la version qui corrige chacune, et l'endroit où la bibliothèque a été détectée, ce qui vous dit qui est responsable du correctif. Vérifiez aussi les autres pages concernées, en commençant par le paiement et la connexion, car l'ASV analyse plus que l'URL citée dans le constat.
Mettre à jour ou supprimer la copie
Traitez chaque copie trouvée :
- Votre propre copie. Passez à la version actuelle de la bibliothèque. Pour jQuery, c'est une version 3.x actuelle ; jQuery Migrate rétablit les API supprimées pendant la migration, mais ne corrige pas les CVE, donc le cœur de jQuery doit quand même changer.
- La copie d'un plugin ou d'un thème. Mettez d'abord à jour le plugin ou le thème. Si sa version actuelle embarque toujours la vieille copie, retirez-la de la file de chargement et laissez la copie du cœur du CMS servir, ou remplacez le plugin.
- La copie d'un widget fournisseur. Demandez au fournisseur une balise à jour. S'il ne la met pas à jour, le widget est le constat, et le retirer des pages concernées est le correctif.
- Une copie que rien n'utilise. Supprimez la balise script.
Vérifiez ensuite de nouveau la page et confirmez que la version servie est la nouvelle. Les couches de cache et les CDN continuent de servir l'ancien fichier un moment après un déploiement.
Relancer le scan avec votre ASV
Demandez un nouveau scan à votre ASV une fois la version corrigée en ligne sur toutes les pages concernées. Un rapport réussi n'a plus aucun constat à 4.0 ou plus, donc corrigez chaque bibliothèque listée par le premier scan avant de le relancer, pas seulement la première.
L'analyseur est une vérification préalable, pas un scan. Il montre quelles versions de bibliothèques une page charge et quels avis s'appliquent, mais une vérification propre ne prouve pas un scan ASV réussi : l'ASV utilise sa propre détection, analyse tous les composants du périmètre, et seul son rapport compte pour PCI DSS.
Quand une contestation est légitime
Tous les constats ne demandent pas une mise à jour. Les ASV acceptent des contestations, dans ces catégories habituelles :
- Faux positif. Le constat est faux : la bibliothèque n'est pas chargée, ou la version lue par le scanner n'est pas celle servie. Certains éditeurs rétroportent aussi un correctif de sécurité sans changer le numéro de version. La preuve est un fichier de configuration, une capture d'écran ou un avis de l'éditeur confirmant le rétroportage, avec la date et la façon dont vous l'avez obtenue.
- Contrôle compensatoire. Le chemin de code vulnérable est bloqué par un autre contrôle qui répond à l'intention de l'exigence, documenté avec la fiche de contrôles compensatoires de l'annexe C de PCI DSS.
- Exception. L'échec ne touche pas l'environnement des données de titulaires de carte, par exemple un score contesté ou un composant hors périmètre.
Un export de l'analyseur de technologies (le PDF daté, ou le fichier CycloneDX) peut appuyer une contestation pour faux positif en montrant quelles versions une page chargeait à une date donnée. Considérez-le seulement comme une preuve complémentaire. L'ASV décide de ce qu'il accepte, et une contestation sans vraie raison ne fait que repousser le problème au trimestre suivant.
Éviter que le problème revienne
La bibliothèque revient quand une mise à jour de plugin la réintroduit, qu'une nouvelle balise arrive sur une page de paiement, ou qu'une CVE est publiée pour la version que vous venez d'adopter. Un scan trimestriel le découvre trois mois plus tard.
Une détection continue le découvre le jour même. Le signalement des hashes de Content Security Policy (CSP) fait signaler par les navigateurs de vos visiteurs chaque script qu'ils exécutent, et CentralCSP tient l'inventaire de chaque version de bibliothèque sur vos pages, avec une alerte quand une version obsolète ou vulnérable apparaît. Construire un inventaire de scripts avec le signalement des hashes CSP explique le mécanisme, et la page chaîne d'approvisionnement présente le produit. Le même inventaire sert de preuve pour les exigences côté client de PCI DSS v4, que CentralCSP vous aide à respecter ; lisez CSP et PCI DSS v4 et Les exigences côté client de PCI DSS v4 expliquées.
FAQ
Quelle est la version minimale de jQuery pour réussir un scan PCI ?
Aucun document PCI ne fixe de version minimale. La règle est le score CVSS : une version avec une vulnérabilité connue notée 4.0 ou plus échoue. En pratique, jQuery 3.5.0 et les versions suivantes n'ont aucun des avis courants listés plus haut, donc une version 3.x actuelle est la cible.
Puis-je réussir le scan en masquant le numéro de version ?
Non. Retirer la bannière de version du fichier ne retire pas la vulnérabilité, et les ASV peuvent identifier une bibliothèque à partir de son contenu, pas seulement de son numéro de version. Mettez-la à jour.
L'analyseur de technologies remplace-t-il mon scan ASV ?
Non. Seul un ASV référencé par le PCI Security Standards Council produit un rapport de scan qui compte pour PCI DSS. Utilisez l'analyseur avant le scan pour trouver et corriger les bibliothèques obsolètes, et après un correctif pour confirmer que la nouvelle version est servie.
Pourquoi le scan échoue-t-il encore après la mise à jour de jQuery ?
En général parce qu'une deuxième copie est encore chargée : un plugin, un thème, un widget fournisseur ou un fichier en cache. Vérifiez de nouveau la page et regardez chaque ligne que l'analyseur liste pour la bibliothèque, pas seulement la première.
Articles liés
- Quelles versions de jQuery sont vulnérables
- À quoi sert un détecteur de technologies, des notes de sécurité aux scans PCI
- Comment détecter les bibliothèques JavaScript vulnérables sur un site en production
- Construire un inventaire de scripts avec le signalement des hashes CSP