Nouveautés & évolutions

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.