DataFirefly Skimming Guard : anti-skimming et intégrité des fichiers

Présentation

DataFirefly Skimming Guard surveille le code servi aux clients de votre boutique PrestaShop 8 ou 9 : les fichiers, la base de données, le HTML envoyé sur les pages de paiement et ce que fait le navigateur au checkout. Il détecte les scripts injectés qui copient les numéros de carte (attaques de type Magecart), les fichiers modifiés ou ajoutés et les fichiers du cœur PrestaShop qui diffèrent de la version officielle. Il complète DataFirefly Admin Shield, qui protège la connexion au back-office.

Installation

1. Dans le back-office, ouvrez Modules > Gestionnaire de modules > Installer un module et envoyez le fichier dfskimguard-1.2.1.zip.
2. Ouvrez le module. Il est aussi accessible dans Paramètres avancés > Skimming Guard.
3. Cliquez sur Scanner maintenant. La première analyse enregistre la référence de vos fichiers : une empreinte SHA-256 par fichier, et une copie des fichiers du thème, des vues de modules et des points d’entrée.
4. Configurez la tâche planifiée (voir plus bas).
5. Envoyez une alerte de test depuis la vue d’ensemble pour vérifier la réception.

Tâche planifiée

Les analyses tournent en tâche de fond, jamais pendant la visite d’un client. Trois options :

• URL cron : copiez l’URL affichée dans le bloc Tâche planifiée et appelez-la toutes les 15 minutes depuis le gestionnaire cron de votre hébergement. L’URL contient un jeton secret.
• Ligne de commande : avec un accès SSH, lancez php modules/dfskimguard/cli.php. L’option --full fait une analyse complète en une fois, sans limite de temps.
• Module cronjobs de PrestaShop : si vous l’utilisez, la tâche s’exécute toutes les heures.

Chaque exécution reprend ou lance l’analyse des fichiers, analyse la base de données une fois par heure, vérifie le cœur PrestaShop une fois par semaine et le contenu des scripts tiers une fois par jour.

Vue d’ensemble

Le bandeau en haut de chaque onglet affiche un score de sécurité de 0 à 100 et une phrase qui résume la situation, avec des raccourcis vers ce qui reste à traiter. La vue d’ensemble liste deux séries de contrôles, les points en échec en premier :

• Configuration de la protection : référence récente, tâche planifiée active, destinataires des alertes, fin de l’apprentissage, blocage des données de carte, Content Security Policy, vérification du cœur, justification des scripts de paiement.
• Durcissement de la boutique : mode debug, dossier d’installation, nom du dossier admin, fichiers dangereux accessibles (sauvegardes SQL ou ZIP, phpinfo, adminer, .git, .env, eval-stdin.php de PHPUnit), SSL sur toutes les pages, version de PHP, permissions des fichiers de configuration.

Chaque point en échec indique comment le corriger.

Protection du checkout

Inspection du HTML servi

Sur le panier, le checkout et les pages de paiement des modules, le module lit le HTML produit par PrestaShop. Il inventorie chaque script externe, iframe, cible de formulaire et domaine cité dans un script inline, et applique des signatures de code obfusqué (eval(atob(...)), new Function, chaînes fromCharCode, chargeurs de scripts, détection des outils de développement). Par défaut, chaque page est inspectée au plus une fois toutes les 5 minutes. Réglez l’intervalle dans les paramètres, ou choisissez de surveiller toutes les pages de la boutique.

Sentinelle navigateur

Un script de 5,5 Ko est injecté en premier dans le <head> des pages surveillées. Il signale les domaines inconnus contactés par la page et, sur les pages de paiement, repère un numéro de carte valide envoyé vers un domaine non approuvé, même encodé en base64. Le numéro n’est jamais transmis au serveur. Pour filtrer les extensions de navigateur, un domaine inconnu n’alerte qu’après 3 visiteurs distincts (réglable) ; une tentative d’envoi de carte alerte dès la première fois.

Blocage des données de carte

Option Bloquer les données de carte envoyées à des domaines inconnus : la requête est annulée quand elle contient un numéro de carte et vise un domaine non approuvé. Activez-la une fois la période d’apprentissage terminée et vos prestataires de paiement approuvés.

Content Security Policy

Le module peut envoyer une CSP construite à partir des domaines approuvés sur les pages surveillées. Commencez en mode Rapport uniquement, puis passez en Appliquer quand aucun domaine inattendu n’apparaît.

Période d’apprentissage

Pendant 48 heures après l’installation, les scripts et domaines tiers à faible risque sont approuvés sans alerte. Les éléments suspects alertent quand même. Relancez l’apprentissage après un changement de thème ou de moyen de paiement avec le bouton Apprendre pendant 48 heures.

Domaines de confiance

Une liste intégrée couvre les prestataires courants (Stripe, PayPal, Braintree, Adyen, Mollie, Klarna, Checkout.com, Worldpay, PayPlug, Stancer, Lyra, PayZen, Systempay, Monetico, Alma, Scalapay, SumUp, Redsys, HiPay, Apple Pay, Google Pay, reCAPTCHA, hCaptcha, Turnstile, Google Analytics, Tag Manager, Meta). Ajoutez vos propres domaines dans les paramètres, un par ligne ; les sous-domaines sont inclus.

Onglet Scripts et domaines

L’onglet liste chaque élément vu sur vos pages avec son type, son domaine, la page, un score de risque et le nombre de passages. Trois actions :

• Approuver : l’élément et son domaine rejoignent la liste de confiance (sentinelle et CSP). Pour un script des pages de paiement, une fenêtre demande la justification.
• Malveillant : le domaine est bloqué par la sentinelle et exclu de la CSP. Sa réapparition déclenche une alerte critique.
• Supprimer : retire l’élément de l’inventaire.

Intégrité des fichiers

Ce qui est surveillé

Extensions par défaut : php, phtml, php5, php7, phar, inc, js, mjs, tpl, twig, html, htm, htaccess, ini, svg, ico. Chemins exclus par défaut : var, cache, img, upload, download, .git, node_modules, les caches de thème et les sauvegardes du dossier admin. Le jeton {admin} est remplacé par le nom de votre dossier d’administration.

Un fichier est considéré inchangé si sa taille, sa date de modification et sa date de changement d’inode n’ont pas bougé. La date de changement d’inode ne se falsifie pas avec touch. Un recalcul complet des empreintes a lieu tous les 7 jours (réglable).

Signatures

Chaque fichier nouveau ou modifié passe les signatures : web shells connus, eval sur des données décodées ou sur la requête, commandes système issues de la requête, PHP caché dans une image ou un .ico, include d’un fichier média, auto_prepend_file ajouté dans .htaccess ou .user.ini, fichiers média exécutés comme PHP, champs de carte lus et envoyés sur le réseau. Un fichier à risque 70 ou plus déclenche une alerte critique immédiate ; les autres changements sont regroupés dans un récapitulatif par analyse.

Onglet Fichiers

• Voir les changements : diff ligne à ligne entre la version approuvée et le fichier actuel. Dans un JS minifié sur une seule ligne, seul le fragment inséré est affiché.
• Restaurer la version approuvée : remet la copie de référence en place. La version modifiée est conservée dans var/dfskimguard/quarantine comme preuve.
• Approuver : accepte le fichier actuel comme nouvelle référence. La sélection multiple et Approuver toutes les modifications servent après une mise à jour.
• Quarantaine : déplace un nouveau fichier suspect hors de la boutique. Il reste restaurable.

Fenêtre de mise à jour

Avant de mettre à jour un module ou le thème, cliquez sur Je mets à jour ma boutique (2 h). Pendant deux heures, les fichiers modifiés sans code suspect deviennent la nouvelle référence sans alerte. Un fichier à risque élevé alerte quand même.

Vérification du cœur PrestaShop

L’onglet Cœur PrestaShop télécharge la source officielle de votre version depuis GitHub, puis compare les fichiers PHP, TPL et Twig de classes, controllers, src, config et les fichiers PHP du dossier admin. Les fins de ligne et les réglages que le build de release et le mode debug réécrivent dans config/defines.inc.php sont ignorés. Le module signale aussi les fichiers PHP inattendus dans classes, controllers et src.

Pour chaque fichier modifié : Comparer avec l’officiel puis Restaurer la version officielle. Un fichier inattendu peut être mis en quarantaine. La vérification se relance automatiquement chaque semaine.

Analyse de la base de données

Une fois par heure, le module recherche des balises script, des gestionnaires onerror ou onload, des URL javascript: et du code obfusqué dans la configuration, les pages CMS, les descriptions de produits, de catégories, de marques et de fournisseurs, et les blocs de texte personnalisés. Un script vers un domaine inconnu ou flagué fait monter le risque.

PCI DSS 6.4.3 et 11.6.1

Pour chaque script autorisé sur les pages de paiement, le module enregistre la justification, l’employé qui l’a autorisé et la date. Le bouton Justifier complète un script déjà approuvé. Le module surveille aussi :

• le contenu des scripts tiers des pages de paiement, téléchargés et analysés chaque jour : un domaine approuvé qui se met à servir du code malveillant déclenche une alerte critique ;
• les en-têtes de sécurité des pages de paiement posés par PrestaShop et ses modules (CSP, HSTS, X-Frame-Options, Permissions-Policy). Les en-têtes ajoutés par le serveur web ne sont pas visibles depuis PHP.

Le bouton Rapport PCI DSS ouvre un rapport imprimable : inventaire justifié, mécanismes de détection actifs avec leur dernière exécution, événements des 90 derniers jours. Exporter en CSV fournit l’inventaire brut.

Alertes

• E-mail : une ou plusieurs adresses, gravité minimale réglable (information, avertissement, critique).
• Webhook : URL HTTPS qui reçoit un JSON avec un champ text compatible Slack, utilisable avec Teams ou un service maison.
• Anti-doublon : la même alerte n’est pas renvoyée pendant 60 minutes, et 20 alertes au plus partent par heure (réglable).
• Bandeau back-office : tant qu’une alerte critique n’est pas lue, un bandeau rouge s’affiche en haut du back-office.
• Rapport hebdomadaire : score, alertes de la semaine, éléments en attente et points à corriger.

Questions fréquentes

Je reçois des alertes après la mise à jour d’un module

Approuvez les changements dans l’onglet Fichiers, ou utilisez la fenêtre de mise à jour la prochaine fois.

Un domaine inconnu apparaît mais je ne le reconnais pas

Il peut venir d’une extension de navigateur d’un visiteur. Tant qu’il n’a pas été vu par 3 visiteurs distincts, il n’alerte pas. S’il s’agit d’un service que vous utilisez, approuvez-le ; sinon, marquez-le comme malveillant.

Où sont stockées les copies et la quarantaine ?

Les copies de référence sont compressées en base de données. La quarantaine et l’archive officielle de PrestaShop sont dans var/dfskimguard, protégé par un .htaccess. Le module ne scanne pas ce dossier.

Comment repartir de zéro ?

Le lien Réinitialiser la référence efface la référence des fichiers ; la prochaine analyse en crée une nouvelle. Les fichiers en quarantaine restent listés et restaurables.