Les Qualified Security Assessors PCI DSS font déjà face à la tâche colossale de maîtriser plus de 397 pages d'un contenu dense. Pour ne rien arranger, de nombreux marchands s'empressent de trouver la solution la moins coûteuse qui leur permettra de passer l'évaluation, en repoussant les limites de ce qui constitue l'approche minimale acceptable. Si ces solutions semblent cocher toutes les cases à première vue, beaucoup d'entre elles laissent les titulaires de cartes dangereusement exposés aux attaques côté client. Dans certains cas, ces solutions se situent dans la zone grise d'une formulation vague et ne satisfont pas réellement aux normes de conformité.
Ce guide aide les QSA à identifier ces signaux d'alerte. Nous l'avons rédigé à partir de notre propre expérience de travail avec des évaluateurs, ainsi que des évaluations techniques que nous avons menées lors du développement d'une solution PCI pour nos clients.
Liste de contrôle synthétique pour les QSA :
Pour satisfaire aux exigences 6.4.3 et 11.6.1, un marchand doit être en mesure de démontrer (que la solution soit développée en interne ou via un fournisseur) :
- Un mécanisme permettant de contrôler les scripts sur la page et de les bloquer. Une CSP, un SRI ou un script côté client peuvent y parvenir. Mais un crawler seul ne le peut pas.
- Le contenu des scripts peut être analysé pour détecter des indicateurs d'intention malveillante. Pour que cela soit possible, la solution doit être capable d'afficher le contenu des scripts. Aucune capacité à afficher le contenu des scripts = aucune capacité à vérifier l'intégrité des scripts. Pas de preuve = pas de conformité.
- Un inventaire de tous les scripts (inline, first-party, tiers et dépendances des scripts) doit être maintenu avec une justification technique ou métier.
- Les en-têtes de sécurité des pages de paiement doivent être surveillés et affichés au moins une fois par semaine.
- Un mécanisme est en place pour alerter en cas de suppression de toute mesure de sécurité côté client.
- Le contenu des scripts doit être surveillé activement et des alertes doivent être déclenchées en cas de modification.
La solution d'un marchand échouerait si elle :
- Ne dispose pas d'un script côté client ou d'une CSP ou d'un SRI capable de bloquer le chargement des scripts (ne satisfait pas à 6.4.3)
- Est uniquement un crawler sans aucun ajustement de code sur la page (ne satisfait pas à 6.4.3)
- Vérifie uniquement les URL des scripts sans surveiller leur contenu (ne satisfait pas à 11.6.1)
- N'envoie pas d'alertes lorsque des en-têtes de sécurité sont supprimés ou modifiés (ne satisfait pas à 11.6.1)
- Ne suit pas et n'affiche pas les en-têtes de sécurité au moins une fois par semaine (ne satisfait pas à 11.6.1)
Pourquoi ces exigences existent :
Les exigences 6.4.3 et 11.6.1 concernent les attaques côté client — des attaques qui s'exécutent dans l'environnement applicatif sur l'appareil de l'utilisateur, mais qui résultent de vos dépendances en tant que marchand. Ce périmètre a été ajouté dans PCI DSS v4. Les émetteurs de cartes ont signalé qu'une part significative des vols de données de titulaires de cartes (CHD) se produit côté client, hors du champ de vision des autres mesures de sécurité. Un Web Application Firewall n'a aucun impact sur les exécutions côté client, en particulier celles provenant de tiers. Cette extension du périmètre était donc nécessaire. De nombreux autres référentiels de conformité emboîtent le pas en élargissant les exigences relatives à la sécurité de la chaîne d'approvisionnement pour inclure les exécutions côté client.
Les exigences PCI s'appliquent-elles aux applications monopages (SPA) ?
La spécification PCI DSS ne fait pas de distinction entre les technologies d'applications web monopages et les applications web rendues côté serveur. Cela peut prêter à confusion, car certaines exigences peuvent sembler inapplicables ou techniquement irréalisables sans surveiller l'intégralité de l'application monopage, mais les actions de sécurité demandées s'appliquent bien aux applications monopages. À bien des égards, les SPA ont largement contribué à la nécessité de renforcer les exigences de sécurité en augmentant la quantité de code qui s'exécute côté client.
Périmètre de 6.4.3 & 11.6.1 :
La spécification PCI indique que « cette exigence s'applique à tous les scripts chargés depuis l'environnement de l'entité ainsi qu'aux scripts chargés depuis des tiers et des quatrièmes parties ». Par conséquent, toute mention de « script » inclut les scripts de même origine (1re partie), les tiers et les sous-requêtes de ces tiers.
De nombreux outils traditionnels ne surveillent pas les scripts côté client provenant de la même origine ni les scripts injectés en ligne. En d'autres termes, ces outils ne surveillent pas les scripts first-party ni les extraits de code déposés directement sur la page (par exemple, les balises analytics). C'est problématique, car les attaques côté client ont fréquemment pour origine des scripts provenant de la même origine.
6.4.3 :
L'exigence stipule :
« Tous les scripts de pages de paiement qui sont chargés et exécutés dans le navigateur du consommateur sont gérés comme suit : »
1. « Une méthode est mise en œuvre pour confirmer que chaque script est autorisé. »
Cela signifie que tout script non autorisé doit être empêché d'être servi. Il n'existe que 2 façons d'y parvenir :
- Mettre en œuvre une CSP de script ou des SRI : Assurez-vous que les Content Security Policies (CSP) sont strictes et en mode blocage. Par conception, la CSP est un mécanisme permettant de faire confiance à des sources, et non aux scripts eux-mêmes. Ce sont des choses fondamentalement différentes. Si une source de confiance est compromise, des scripts malveillants peuvent passer sans qu'aucune mesure de sécurité ne les arrête.
La Subresource Integrity (SRI) opère au niveau du script et valide la charge utile réelle. Cependant, SRI n'est pas toujours une option pratique pour les scripts dynamiques qui changent fréquemment côté client.
- Utiliser un script côté client : Un script côté client qui se charge avant tous les autres scripts peut ajuster ou démonter des scripts. Il peut empêcher l'exécution de scripts non autorisés, partiellement ou totalement.
Si un marchand ne dispose pas d'une CSP, d'un SRI ou d'un script côté client sur une page pour empêcher le chargement de scripts non autorisés, l'exigence 6.4.3 n'est pas satisfaite.
Important : une solution basée uniquement sur un crawler sans CSP ne satisfait pas aux exigences PCI. Plusieurs fournisseurs proposent des crawlers qui ne répondent pas à cette exigence.
2. « Une méthode est mise en œuvre pour garantir l'intégrité de chaque script. »
Cela signifie que chaque script doit être surveillé. L'exigence 11.6.1 précise que cela inclut le contenu des scripts. Par conséquent, une solution de sécurité satisfaisant à 6.4.3 et 11.6.1 doit être capable d'afficher le contenu des scripts servis à l'utilisateur.
L'emplacement d'exécution de la solution est important : Les solutions qui s'exécutent en externe ne peuvent pas garantir que le script qu'elles ont analysé est bien celui qui est réellement servi aux utilisateurs finaux. Il est connu que des acteurs malveillants identifient les adresses IP des fournisseurs cloud utilisées par les crawlers et excluent les scripts malveillants de ce qui leur est servi. Il est donc incertain qu'une solution qui ne réside pas dans l'application au moment de l'exécution puisse satisfaire à cette exigence. La CSP seule ne peut pas vérifier l'intégrité des scripts car elle n'inspecte pas leur contenu. SRI, en revanche, valide bien le contenu des scripts par rapport à un hash.
URL de scripts + flux de menaces : Certaines solutions revendiquent la conformité en vérifiant les URL des scripts par rapport à des flux de menaces, mais cela ne vérifie que le nom du fichier et non son contenu. Puisque 11.6.1 exige spécifiquement la surveillance de la charge utile réelle du script, ces approches ne satisfont pas à la conformité. C'est la même raison pour laquelle un antivirus ne s'arrête pas aux noms de fichiers — il inspecte ce qu'il y a à l'intérieur.
En règle générale : si une solution n'affiche pas le contenu des scripts, elle ne satisfait pas aux exigences de surveillance de l'intégrité.
Test de validation : Pour déterminer si une solution peut vérifier l'intégrité des scripts, il est recommandé d'effectuer un test en implémentant un exemple de script « malveillant » dans un environnement de staging.
3. « Un inventaire de tous les scripts est maintenu avec une justification écrite, métier ou technique, expliquant pourquoi chacun est nécessaire. »
Les marchands peuvent utiliser des tableurs ou des tableaux de bord fournis par des fournisseurs pour satisfaire à cette exigence. L'IA est souvent utilisée pour rédiger les justifications. Certaines solutions ne proposent pas cette fonctionnalité nativement ; dans ce cas, un tableur peut être utilisé. Il est cependant important que ce tableur soit à jour. Un export du tableau de bord Google Tag Manager ne suffit pas, car l'application elle-même peut contenir des scripts côté client injectés en dehors de Google Tag Manager.
Inventaires obsolètes ou incomplets : Il est conseillé qu'un QSA vérifie la solution en question pour s'assurer que tous les scripts figurent dans l'inventaire et que celui-ci est à jour.
Utilisation d'une approche « sans agent » : La documentation PCI DSS v4 fournit des orientations et suggère d'utiliser une CSP, un SRI ou un script propriétaire ou un système de gestion de balises capable d'empêcher l'exécution de scripts malveillants. Il n'est fait aucune mention d'un outil d'observabilité passif tel qu'un scanner, un crawler ou un agent. L'exigence d'empêcher le chargement d'un script malveillant ne peut pas être satisfaite sans ajouter un script ou un en-tête CSP à une page web.
11.6.1
Un mécanisme de détection des modifications et des altérations est déployé comme suit :
1. « Pour alerter le personnel en cas de modification non autorisée (y compris les indicateurs de compromission, les modifications, les ajouts et les suppressions) des en-têtes HTTP ayant un impact sur la sécurité et du contenu des scripts des pages de paiement tels que reçus par le navigateur du consommateur. »
Cette exigence concerne la surveillance de tous les en-têtes de sécurité côté serveur susceptibles d'être modifiés dans la période précédant une attaque, ainsi que l'obligation de surveiller les charges utiles des scripts.
La charge utile du script doit être analysée et des alertes doivent être envoyées rapidement en cas de compromission. Bien entendu, une alerte sans indication de la raison pour laquelle elle a été déclenchée est inutile ; pour être exploitable, le contenu des scripts doit être stocké et affiché à des fins d'investigation.
Exemples de modifications nécessitant des alertes : « Du code ou des techniques de skimming e-commerce ne peuvent pas être ajoutés aux pages de paiement tels que reçus par le navigateur du consommateur sans qu'une alerte rapide soit générée. Les mesures anti-skimming ne peuvent pas être supprimées des pages de paiement sans qu'une alerte rapide soit générée. »
Il est également nécessaire de disposer d'un mécanisme permettant de surveiller toute altération de la solution de sécurité elle-même. Si elle est supprimée, cela doit déclencher une alerte.
Pour satisfaire à ces exigences, la liste des en-têtes de sécurité ci-dessous doit être surveillée :
| En-tête de sécurité | Description |
|---|---|
| Content Security Policy | Également connu sous le nom d'en-tête CSP. |
| Content Security Policy Report Only | L'en-tête CSP en mode rapport uniquement, sans blocage. |
| Report To | Point de terminaison de rapport suivant la spécification héritée. |
| Reporting Endpoints | Point de terminaison de rapport alternatif suivant la spécification plus récente. |
| Strict Transport Security (HSTS) | Contraint le navigateur à se connecter uniquement via HTTPS. |
| X-Frame-Options | Permet de définir si des iframes peuvent être injectées dans la page web. |
| Cross-Origin Resource Policy (CORP) | Permet à la page web de définir quelles ressources peuvent être chargées et depuis où. Lié à CORS et à la Same-Origin Policy. |
| Cross-Origin Opener Policy | Permet à la page web de définir comment le navigateur doit interagir avec différents contextes tels que les onglets, les iframes et les fenêtres. |
| Cross-Origin Embedder Policy | Permet de contrôler quels composants cross-origin le navigateur peut charger. |
| Permissions Policy | Permet de définir quelles API d'appareil peuvent être accessibles par les applications web et leurs dépendances. |
| X-Content-Type-Options | Force strictement le navigateur à vérifier les types de contenu. Les navigateurs pourraient sinon autoriser des injections malveillantes via des types de contenu non prévus. Une méthode très courante utilisée dans les exécutions côté client et les attaques de type MIME. |
| X-Permitted-Cross-Domain-Policies | Est un en-tête de sécurité plus ancien définissant depuis quels domaines Flash Player et les lecteurs PDF étaient autorisés à récupérer du contenu. |
| Referrer Policy | Anecdote : il y a une faute de frappe dans la spécification HTTP pour « referer ». Cet en-tête permet de définir la quantité d'informations transmises par le référent, la page précédente ou la page parente. |
| X-XSS-Protection | Est un en-tête de sécurité hérité permettant d'activer ou de désactiver les fonctionnalités natives de détection XSS du navigateur. |
2. « Le mécanisme est configuré pour évaluer les en-têtes HTTP reçus et les pages de paiement »
Cela reprend les points mentionnés ci-dessus concernant la surveillance de tous les en-têtes de sécurité HTTP ayant un impact sur la sécurité de la page de paiement.
3. « Les fonctions du mécanisme sont exécutées comme suit : Au moins une fois par semaine OU périodiquement (à la fréquence définie dans l'analyse de risque ciblée de l'entité, réalisée conformément à tous les éléments spécifiés dans l'exigence 12.3.1). »
Cette section indique que ces vérifications doivent avoir lieu au moins une fois par semaine ou selon le délai imposé par 12.3.1. Un échantillonnage peut être autorisé pour les en-têtes HTTP et le contenu des scripts, mais ceux-ci doivent être examinés au moins une fois par semaine. Une semaine est une longue période ; il est recommandé de conseiller aux marchands d'adopter une perspective de sécurité plus proactive.
AOC et ROC pour les fournisseurs
Les fournisseurs qui proposent des solutions de sécurité pour 6.4.3 et 11.6.1 ne sont pas des TPSP dans le contexte des paiements (Third-Party Service Provider) et n'ont pas besoin d'un SAQ, d'un AOC ou d'un ROC sur leur propre produit de la part d'un QSA. Certains fournisseurs de plus grande taille détiennent ces certifications pour d'autres parties de leur activité, et les mentionnent parfois dans ces rapports pour leurs outils liés à PCI. Cela ne signifie pas pour autant que ces outils ont été testés ou validés. Le marchand reste en définitive responsable de la preuve de sa conformité au PCI DSS. Certains fournisseurs rémunèrent des QSA pour examiner leurs solutions et publier des livres blancs, mais même cela ne garantit pas entièrement la conformité pour les marchands individuels.
Applications web rendues côté serveur vs applications monopages :
Les applications rendues côté serveur traditionnelles chargent une nouvelle page depuis le serveur à chaque clic sur un élément. Par exemple : un portail bancaire en ligne où chaque clic (par exemple, consulter son solde) recharge une nouvelle page complète depuis les serveurs de la banque.
Les applications monopages (SPA), quant à elles, se chargent une seule fois et s'appuient sur JavaScript pour mettre à jour le contenu de manière dynamique. Par exemple : un tunnel de commande e-commerce développé en React où la page ne se recharge jamais complètement ; à la place, les formulaires, les détails des produits et les champs de paiement se mettent à jour dynamiquement dans le navigateur. Les applications monopages sont en plein essor, à mesure que davantage de sites web sont construits avec des frameworks de développement web comme React, Angular et Vue.
