Nouveautés & évolutions

Huit onglets dans votre back-office, menu PrestaShop compris : Vue d'ensemble, Scan, Pare-feu, Connexions, Historique, Paramètres, Rapport et Aide. La note, les failles et les constats sont calculés par PrestaSecure : le module et votre espace client affichent les mêmes chiffres et proposent les mêmes actions. La Vue d'ensemble classe ce qu'il faut faire, du plus urgent au moins urgent.

Qu'elle soit lancée depuis le module, votre espace PrestaSecure ou notre équipe, l'analyse en cours s'affiche avec sa progression et les menaces trouvées, la plus grave en premier. Un fichier signalé s'ouvre avec les lignes en cause surlignées, un fichier du cœur se compare à l'original de votre version, et les fichiers ajoutés ou modifiés d'une analyse se lisent aussi. Les fichiers qui contiennent les accès de la boutique ne s'affichent jamais.

Un fichier du cœur de PrestaShop se restaure depuis l'original, jamais en quarantaine. Pour les autres fichiers, la quarantaine passe par un avertissement : retirer un fichier utilisé peut casser le site. Vous pouvez demander l'avis de PrestaSecure, offert sans délai ni obligation (3 demandes par mois) ; avec Serenity, vous signalez le fichier à notre équipe. Un fichier ignoré réapparaît si son contenu change, et toute quarantaine se restaure.

Après le nettoyage de la base, l'alerte restait affichée jusqu'à ce que quelqu'un la marque corrigée à la main. Le module indique désormais à PrestaSecure s'il a bien lu la base pendant le scan : si c'est le cas et que la table n'est plus touchée, l'alerte se ferme. Si la lecture a échoué, l'alerte reste ouverte, car un scan qui n'a rien pu lire ne prouve rien.

Un code malveillant peut être écrit directement dans la base de données, par exemple dans la note d'une fiche client. Il s'exécute alors dans le navigateur de l'employé qui ouvre la fiche ou la commande, et peut transmettre l'adresse de votre back-office à un tiers. Aucun fichier n'étant modifié, ni le scan des fichiers ni celui des pages de la boutique ne pouvait le voir. Le scan contrôle désormais les notes clients, les compléments d'adresse et les messages de commande et du service client. PrestaShop refuse ce type de contenu à la saisie : sa présence signale une écriture directe en base. L'alerte s'affiche dans votre espace PrestaSecure, avec le nombre de fiches concernées, et notre équipe est prévenue.

Sur une boutique dont la tâche planifiée tourne toutes les quinze minutes, un nouveau scan complet démarrait dès que le précédent était fini, jusqu'à plusieurs dizaines par jour : une charge inutile pour votre serveur. La tâche planifiée termine toujours un scan en cours, mais n'en lance un nouveau que si le dernier date de plus de vingt heures. Les scans que vous lancez vous-même ne changent pas.

Le widget de l'accueil liste chaque correctif disponible avec le module concerné, la nature de la faille en mots simples et le nombre de jours depuis son signalement. Un clic suffit pour l'appliquer, après une sauvegarde automatique ; le retour arrière reste possible. La note de sécurité montre aussi la note qu'aurait la boutique une fois les correctifs posés, et le pare-feu affiche les requêtes refusées sur les dernières 24 heures.

Quand un correctif ne s'applique pas, votre boutique n'est pas modifiée et le module vous l'indique clairement, avec une référence de suivi. Notre équipe est prévenue et vérifie le correctif ; vous recevez un e-mail dès qu'il est réparé, et le bouton d'application revient de lui-même.

Une adresse qui enchaîne les attaques est bannie 15 minutes à la troisième tentative, 2 heures à la cinquième et 24 heures à la dixième. Le compteur se remettait à zéro à chaque requête : chaque attaque était bien refusée, mais l'attaquant pouvait insister sans limite et essayer des variantes. Le compteur est désormais conservé, et une adresse déjà bannie qui recommence est bannie plus longtemps.

Des robots enchaînent les pages de catégories avec des filtres empilés ou des listes de centaines de produits. Le pare-feu les refusait déjà, mais seulement une fois la boutique chargée, après des centaines de requêtes en base : sur un hébergement mutualisé limité, cela suffisait à mettre le site en erreur. Ces requêtes sont désormais refusées par le serveur web lui-même, avec une page légère, sans toucher à la base. Ce filtrage suit votre licence et se retire de lui-même si le module est désactivé.

Après chaque correctif, le module relit le fichier et ne valide le succès que si son contenu a réellement changé. Chaque fichier modifié est vérifié, et en cas d'erreur la version d'origine est remise automatiquement. Un code déjà neutralisé par votre développeur est reconnu et laissé tel quel.

Un dossier de module présent sur le serveur mais désinstallé de la boutique peut contenir une faille exploitable. Ces dossiers orphelins étaient cachés et impossibles à retirer lorsqu'il s'agissait d'un module fourni avec PrestaShop. Ils sont désormais listés comme tels et peuvent être supprimés, après une sauvegarde mise en quarantaine. Un module installé dans votre boutique n'est jamais touché.

Sur PrestaShop 8 et 9, le code saisi sur l'écran de validation n'atteignait pas notre service depuis certaines pages du back-office : l'employé retombait sur l'écran de saisie en croyant le code faux. C'est corrigé. Une adresse validée depuis votre espace client ou par nos équipes est désormais appliquée dans la minute, au lieu d'attendre le passage de la tâche planifiée de votre boutique ; il en va de même pour la désactivation de la protection. Enfin, quand un code ne peut pas être émis, la porte reste fermée et l'écran indique le délai à attendre : plus aucun passage sans validation.

Une connexion à votre administration depuis une adresse que votre boutique n'a jamais utilisée peut désormais être mise en attente, le temps qu'un code envoyé par e-mail soit saisi. La protection démarre en observation : pendant les premiers jours, elle recense simplement les adresses dont votre équipe se sert, sans jamais bloquer personne ni envoyer quoi que ce soit. C'est vous qui décidez ensuite du moment où elle s'active, une fois la liste constituée. Offre Advance et supérieure.

Derrière Cloudflare ou un répartiteur de charge, toutes les connexions semblaient venir de la même adresse, ce qui rendait toute distinction impossible. Nous lisons désormais l'adresse d'origine, mais uniquement lorsque la requête provient d'un intermédiaire que nous reconnaissons : un en-tête fabriqué par un attaquant ne peut donc pas usurper une adresse de confiance.

Quand un correctif de sécurité ne trouvait pas le fichier visé, nous en concluions que la faille avait disparu. C'est vrai la plupart du temps, mais pas toujours : le fichier peut aussi être ailleurs que là où nous le cherchions, et la faille toujours présente. Nous distinguons désormais les deux cas, et aucune boutique n'est plus considérée comme à l'abri sans preuve.

Nos correctifs de sécurité remplacent un bloc de code à l'octet près, pour ne jamais toucher autre chose que ce qui doit l'être. Or un même fichier ne s'écrit pas de la même façon selon qu'il a été enregistré depuis Windows ou depuis un serveur : les fins de ligne diffèrent, invisibles à l'œil. Sur ces boutiques, le correctif ne reconnaissait plus le bloc visé et s'abstenait, par prudence. Le moteur ré-exprime désormais le motif recherché dans le style du fichier qu'il a devant lui : la protection s'applique partout, sans jamais rien réécrire au hasard.

Déposer du code malveillant dans un fichier qui se présente comme une image est une technique éprouvée : le fichier porte l'extension d'une photo, mais le serveur y trouve des instructions. Nous les cherchions là où des fichiers arrivent de l'extérieur — les dossiers d'envoi et de téléchargement. La difficulté n'est pas de regarder ailleurs, elle est de le faire sans relire les centaines de milliers d'images légitimes de votre catalogue à chaque analyse. Nous reniflons désormais l'en-tête de chaque image partout, y compris sous vos thèmes, vos modules et vos bibliothèques, et n'examinons en profondeur que celles qui contiennent réellement du code. Le scan reste aussi rapide, il ne laisse plus ce recoin de côté.

Dès qu'un fichier est repéré, notre système l'analyse en profondeur. Vous voyez maintenant dans votre tableau de bord vers quoi penche cette analyse, probable fausse alerte ou menace réelle, avec son niveau de confiance, sans attendre qu'on intervienne derrière. De quoi savoir tout de suite ce qui mérite votre attention.

Certains marchands hébergent aussi un WordPress sur leur boutique PrestaShop. C'est déconseillé, mais ça existe, et son cœur déclenchait parfois des alertes à tort. Pareil pour les bibliothèques de test livrées avec certains modules et pour les fichiers JavaScript compressés. Le scanner reconnaît maintenant ces composants normaux et les laisse de côté, sans rien relâcher sur les fichiers réellement à risque. Vos rapports de scan gagnent en lisibilité.

Certains pirates greffent un script invisible sur la page de connexion de votre back-office pour capter votre identifiant et votre mot de passe à chaque connexion, puis se réinstallent tout seuls après un simple changement de mot de passe. C'est ce qui leur permet de revenir jour après jour. Nous repérons maintenant ce type de greffe : un script chargé en douce dans l'administration et un marquage caché du navigateur, y compris quand le pirate renomme ses fichiers pour brouiller les pistes. Repéré sur une vraie boutique, ce piège passait jusqu'ici inaperçu et déclenche désormais une alerte critique.

Sur les boutiques qui comptent un très grand nombre de fichiers, ou dont les journaux d'activité sont volumineux, l'analyse pouvait s'arrêter en cours de route par manque de mémoire. Elle gère désormais sa consommation au fil de l'eau et va jusqu'au bout de son passage, quelle que soit la taille du site.

Nous avons durci la détection des skimmers de carte bancaire (type Magecart) qui cachent leur adresse de collecte sous forme encodée dans un script ou une fausse image, ainsi que des chargeurs qui exécutent une porte dérobée téléchargée depuis un serveur externe, même lorsque le code est volontairement maquillé. Repérés sur des boutiques réelles, ces schémas remontent désormais en alerte critique au lieu de passer sous le radar.

Nous traquons désormais les portes dérobées qui se camouflent, en déguisant leur code (par exemple en jouant sur la casse des mots pour tromper les antivirus) ou en se réinstallant toutes seules via un fichier téléchargé depuis l'extérieur. Repérés sur de vraies boutiques, souvent cachés dans des modules piratés, ces pièges passaient jusqu'ici en « discret » : ils déclenchent maintenant une alerte critique.

Fini la page « Accès refusé » abrupte. En cas de tentatives répétées, le client retrouve le formulaire de connexion habituel de la boutique avec un message clair : trop de tentatives, temps d'attente restant affiché et un lien direct pour réinitialiser son mot de passe. Le seuil a été assoupli pour ne plus pénaliser un client qui se trompe simplement de mot de passe, tout en bloquant immédiatement les attaques automatisées.

Consultez le contenu d'un fichier signalé, ou sa comparaison avec la version officielle PrestaShop, directement depuis votre tableau de bord PrestaSecure, sans connexion SSH ni FTP. Accès en lecture seule, strictement limité à votre boutique et à des types de fichiers sûrs.

Le scanner inspecte désormais la configuration et les contenus éditoriaux affichés sur votre boutique, pas seulement les fichiers. Cela ferme un angle mort exploité par certains attaquants pour injecter un script de vol de cartes bancaires ailleurs que dans les fichiers du site, un vecteur observé sur un incident client réel.

Catalogues de plusieurs millions de fichiers, multiboutiques : le scan analyse désormais l'intégralité du parc, sans troncature ni dépassement de mémoire, en enchaînant plusieurs passes automatiques si nécessaire. Aucune zone du site n'est laissée de côté.

Les scans récurrents n'analysent plus que les fichiers réellement modifiés depuis le dernier passage, au lieu de tout reparcourir. Le gain de temps est considérable sur les boutiques volumineuses, sans aucune perte de couverture : un seul octet modifié reste détecté.

Le rapport se construit sous vos yeux : les menaces apparaissent au fur et à mesure de l'analyse, avec leur sévérité et leur regroupement, au lieu d'attendre la toute fin du scan.

Le module analyse le journal d'erreurs PHP de votre boutique à la recherche de signatures d'attaque connues (injection de template, tentative de lecture de fichiers de configuration sensibles, inclusion de fichier distant…). Les attaquants laissent souvent des mois de tentatives ratées avant de réussir : vous êtes alerté dès les premiers signaux.

Plus aucun dossier n'est ignoré au scan (dépendances, thèmes, back-office, dossiers d'upload…). Un code malveillant peut se cacher n'importe où, y compris dans une dépendance ou un webshell glissé dans l'administration. L'analyse couvre désormais l'ensemble du site.

Corrigez en quelques clics : application des correctifs de sécurité validés, nettoyage des fichiers infectés, suppression des modules fantômes (présents sur le disque mais inconnus de PrestaShop) et mise à jour des modules vulnérables, le tout avec sauvegarde et retour arrière automatiques.

Un badge indique, pour chaque vulnérabilité détectée, si elle est déjà neutralisée par le pare-feu applicatif PrestaSecure. Vous distinguez d'un coup d'œil ce qui est protégé de ce qui nécessite une action.

Appliquez les correctifs des vulnérabilités connues du cœur PrestaShop et des modules directement depuis votre tableau de bord, avec sauvegarde préalable, vérification automatique après application et possibilité d'annuler à tout moment.

Première version : tableau de bord de protection avec score, antivirus (scan des fichiers et empreintes), pare-feu applicatif (injections SQL, XSS, force brute, traversée de répertoire), outils de remédiation, rapport de sécurité exportable et mises à jour automatiques du module.