Historique des modifications — PrestaWard Snapshot

0.1.8

Le panneau est divisé en onglets (Résumé, Modifications, Tâches, Vérifications, Configuration et Historique des modifications) et ne prend en compte que l'onglet ouvert, ce qui permet un chargement plus rapide dans les grandes boutiques. Le panneau d’assistance de GO ON Agency dispose de son propre onglet, « Assistance », toujours le dernier, et la section Integrity se trouve à la fin de tous les onglets.
Résumé minimal : la base de référence actuelle, la dernière comparaison et son résultat, une action principale et, au maximum, une ligne indiquant la tâche en cours ou l’alerte la plus importante (modifications en attente de révision, dossiers nouveaux ou non couverts nécessitant une nouvelle base de référence, une fenêtre de maintenance à fermer, une tâche cron qui ne s’est jamais exécutée ou qui est en retard, des sauvegardes dans la racine du site). S’il y a d’autres alertes, la ligne ajoute « et N autres ».
Onglet « Tâches » : la tâche en cours s’affiche sous forme de fiche indiquant ses phases (découvrir, calculer les empreintes, valider, comparer ou publier, effectuer l’attestation), le compteur de fichiers, le temps écoulé, la dernière mise à jour et qui l’exécute (Back Office, cron ou ligne de commande). Une tâche nécessitant un traitement en ligne de commande s’affiche en orange, avec la raison indiquée en langage clair et la commande exacte accompagnée d’un bouton permettant de la copier ; dans le navigateur, il n’y a pas de bouton « Reprendre ».
Historique des tâches sur 90 jours dans un seul tableau (type, origine, employé, début, durée, statut, résultat et alertes) avec des filtres par type, statut et dates, ainsi qu’une pagination, au lieu de la limite précédente des 20 dernières tâches ou des 7 derniers jours. Le résultat d’une comparaison renvoie vers les modifications détectées et une vérification des fichiers du cœur renvoie vers l’onglet « Vérifications ».
Détails de chaque tâche : chronologie, fichiers, mémoire maximale, hachage de la politique, base de référence et comparaison liées, notifications avec des dossiers d’exemple, une erreur traduite en cas d’échec et téléchargement du rapport de diagnostic. Lorsque les détails des fichiers d’une tâche terminée sont supprimés, un résumé est conservé (nombre d’alertes avec des dossiers d’exemple et des dossiers non entièrement couverts) et la page indique que les détails ont été supprimés.
La couverture par catégorie est déplacée à la fin de la section « Modifications » ; les vérifications de la boutique (sauvegardes, fichiers du cœur, audit de la configuration et état de santé des modules) sont regroupées dans la section « Vérifications » ; et les réglages relatifs à la messagerie, au cron, à la politique d'analyse, à la fenêtre de maintenance et au stockage se trouvent dans la section « Configuration ».
L'audit de configuration de sécurité passe à 14 vérifications. Nouveautés : renforcement de la sécurité PHP (allow_url_include et expose_php), dossiers de gestion de versions et fichiers d’environnement (.git, .svn, .hg, .env et variantes) à la racine du site et au sein des modules et des thèmes, clés de service Web permettant l’écriture sur de nombreuses ressources (seul leur nom est comptabilisé ; aucune clé n’est jamais lue ni affichée), vérification de l’adresse IP associée au cookie et des comptes inactifs conservant le profil SuperAdmin (ils sont simplement comptabilisés, sans nom ni adresse). Chacune fait l’objet d’une explication et d’une solution, et ce qui ne peut être lu est indiqué comme « non vérifié ». Les fichiers .git, .svn et .env situés à la racine du site web sont transférés de la vérification des fichiers d’installation et des copies vers la nouvelle vérification, afin de ne pas les compter deux fois.
Heuristiques de détection de skimming de cartes bancaires pour JavaScript : le code JavaScript nouveau ou modifié du thème actif et des modules de paiement est également analysé à la recherche de trois signaux : du code qui lit le numéro, la date d’expiration ou le code de sécurité et envoie des données vers un autre site web (risque élevé), des données envoyées vers un autre site à partir du code de commande ou de paiement (à vérifier) et du code fortement obscurci à proximité du code de commande ou de paiement (à vérifier). Les adresses de la boutique elle-même, des passerelles de paiement et, pour les indices les plus faibles, des serveurs d’analyse connus ne sont pas considérés comme un autre site. Une correspondance constitue un motif d’examen du fichier, et non une preuve de compromission, et une adresse générée par le code lors de son exécution n’est pas détectée.
Estimation du volume multimédia : pour chaque base de référence et chaque comparaison, le système comptabilise, pour chaque dossier multimédia (img, upload, uploads et download), les fichiers et les octets déjà parcourus, sans accéder à d’autres fichiers ni enregistrer de données par fichier. La section « Vérifications » affiche le total par dossier, l’augmentation par rapport à la base de référence et indique si une limite est dépassée. La section « Configuration » comporte trois limites : nombre maximal de fichiers, taille maximale en Go et augmentation maximale par rapport à la base de référence en pourcentage (50 % par défaut ; 0 désactive la limite). Tout dépassement de limite apparaît dans le « Résumé » et dans l’e-mail d’alerte, qui est également envoyé lorsqu’aucun fichier n’a suffisamment évolué pour déclencher cette alerte à lui seul.
Limite de surveillance visible : une analyse lit au maximum 250 000 noms dans les dossiers exclus, et les dossiers suivants étaient enregistrés comme non couverts mais n’apparaissaient que dans la tâche. Désormais, cela se traduit par une ligne d’alerte dans le « Résumé » et une notification dans « Vérifications » indiquant le nombre de dossiers non surveillés, et le volume multimédia est marqué comme « partiel » s’il a été mesuré en dessous de cette limite.
Corrige le problème de dégradation de la connexion avec Integrity depuis le Back Office dans le contexte « toutes les boutiques » ou lorsqu’une boutique autre que la première servait le test d’inscription : la boutique connectée passait à l’état « inscription en attente » et le test ne pouvait pas être signé. L’identité de l’installation est désormais lue comme une entité unique à partir de la portée globale (ou à partir de la boutique qui la stocke) dans n’importe quel contexte ; la mise à jour transfère vers la portée globale une identité stockée dans une boutique sans la régénérer et, si elle ne peut pas être lue, l’état d’Integrity reste inchangé.
Nouveau : barre de filtres commune. La vérification des modifications et l’historique des tâches l’utilisent : les sélecteurs sont répartis dans une grille de largeur égale, le champ de recherche et le bouton « Filtrer » se trouvent sur la même ligne et les actions secondaires, telles que l’exportation de l’audit au format CSV, sont alignées à droite. Auparavant, les filtres s’entassaient et les boutons se chevauchaient.
Les e-mails d’alerte, de résumé de maintenance et de test affichent le logo de votre boutique dans l’en-tête (avec le nom de la boutique comme texte alternatif) et un pied de page commun comportant le logo de GO ON Agency et la signature « PrestaWard by GO ON Agency », sans aucun lien ni coordonnées. Le logo du pied de page est un fichier provenant du module lui-même, mis à disposition depuis votre boutique.
Corrige le fait que l'objet des e-mails comporte deux fois le nom de la boutique.
Aspect unifié du panneau dans les quatre modules PrestaWard : en-têtes de section, fiches de formulaire aux bordures neutres et blocs repliables communs, statistiques sur une seule ligne et un logo GO ON Agency plus grand dans l’en-tête. Le bouton principal adopte désormais une couleur unie conforme à l’identité visuelle de la marque, sans dégradé.
Corrige le fait que, dans PrestaShop 9, le thème d'administration affichait les onglets soulignés comme des liens et les titres de section en majuscules. Les styles communs neutralisent cet effet uniquement au sein du panneau PrestaWard ; ainsi, PrestaShop 1.7 et 8 s'affichent comme auparavant.
Corrige le fait que, dans PrestaShop 1.7, la feuille de style du module était ignorée lorsqu’elle était enregistrée avec le numéro de version dans l’adresse. Désormais, le fichier est vérifié et enregistré sans paramètres, de sorte que le nouveau thème s’affiche dans les versions 1.7, 8 et 9.
Corrige le fait que, dans PrestaShop 9, les actions du panneau (les requêtes pour des tâches et le téléchargement du rapport d’assistance, ainsi que la synchronisation avec Integrity) vérifiaient le jeton de sécurité à l’aide d’une méthode que PrestaShop 9 n’utilise pas, ce qui pouvait entraîner leur rejet. La validation s'effectue désormais via le service de PrestaShop 9 ; dans PrestaShop 1.7 et 8, la vérification reste inchangée.
Lorsque la connexion à Integrity ne peut pas être mise à jour pour le moment, le panneau affiche un seul message : la connexion enregistrée reste valide et une nouvelle tentative sera effectuée automatiquement. Les libellés de tous les onglets sont traduits dans les neuf langues.
L’en-tête du produit affiche à nouveau le logo de GO ON Agency et la signature « PrestaWard by GO ON Agency », sans liens. Le format de la base de référence, les octets du manifeste et le contrat avec l’API Integrity restent inchangés ; la mise à jour ajoute des colonnes (deux au tableau des tâches et celles relatives au volume multimédia par dossier, par tâche et par base de référence).

0.1.7

Analyse le code suspect des fichiers PHP et JavaScript nouveaux ou modifiés (jusqu’à 512 Ko chacun) à la recherche de motifs caractéristiques des web shells et du code obscurci, et explique le résultat en langage clair. Une correspondance signifie « vérifiez ce fichier », et non pas une preuve d’attaque ; un fichier ne présentant aucune correspondance n’est pas pour autant considéré comme sûr, et un fichier dépassant la limite est marqué comme n’ayant été vérifié que partiellement.
Détecte les images déguisées (avec un en-tête incorrect ou contenant du code PHP) dans tous les dossiers : inclus, exclus et, dans la limite du temps et de la taille alloués, les dossiers temporaires tels que img/tmp, que l’analyse ne parcourt toujours pas.
Attribue un niveau de risque à chaque modification (élevé, à vérifier ou faible), visible et filtrable dans la vérification des modifications, et inclus dans le CSV d'audit ainsi que dans les e-mails d'alerte.
Regroupe les mises à jour des modules et des thèmes en un seul élément, en indiquant la version précédente et la nouvelle. Le code PHP modifié dans le cadre d’une mise à jour détectée présente un faible risque et ne génère plus d’e-mails d’alerte. Nécessite une base de référence créée avec cette version.
Nouveau panneau de fichiers du cœur : il les compare à la liste officielle des sommes de contrôle de votre version de PrestaShop, par lots reprenables. Une différence ne prouve pas une intrusion ; si la liste n'existe pas ou ne peut pas être téléchargée, le panneau indique que le cœur n'a pas été vérifié et ne le présente jamais comme validé.
Nouvel audit de la configuration de sécurité avec un score de 0 à 100 (mode débogage, dossier d’administration, droits d’accès à la configuration, dossiers d’installation, dumps et archives compressées à la racine du site, version de PHP, HTTPS et erreurs PHP visibles, entre autres points). Chaque point est accompagné d’une explication et d’une solution ; ce qui ne peut être vérifié est indiqué comme « non vérifié » et n’est pas pris en compte dans le score.
Signale une tâche cron qui ne s’est jamais exécutée et, via une alerte distincte, les dossiers et les copies de sauvegarde des modules présents à la racine du site.
Les nouvelles installations excluent par défaut les sauvegardes des modules et le dossier « Téléchargements ». Dans les installations existantes, ces exclusions sont proposées dans le panneau de configuration et ne s’appliquent que si vous les activez, ce qui crée une nouvelle base de référence.
Fenêtre de maintenance de 1 à 4 heures : met en sourdine les e-mails d’alerte mais continue d’enregistrer les modifications ; à la fermeture, elle envoie un récapitulatif regroupant les actions « Accepter ces modifications » ou « Fermer sans accepter ». L’option « Accepter » se contente de les marquer comme vérifiées ; Snapshot ne crée jamais de base de référence de lui-même.
Lorsque la couverture de l'analyse augmente d'une version à l'autre, les fichiers des dossiers qui n'étaient pas couverts par l'ancienne base de référence sont signalés comme une nouvelle couverture et non comme des milliers de fichiers ajoutés accompagnés d'alertes critiques.
La vérification des modifications prend en charge des volumes de résultats très importants : pagination avec accès direct à une page, résumé regroupé par dossier, statut et risque, et modifications en attente provenant de bases de référence antérieures marquées comme remplacées.
Réduit le temps nécessaire à la création de la base de référence et à la validation des répertoires dans les grandes boutiques comportant des tâches antérieures conservées (quelques minutes au lieu de plusieurs dizaines de minutes) et supprime par lots délimités les lignes temporaires des tâches terminées.
Corrige plusieurs avertissements : Snapshot ne détecte plus ses propres fichiers comme présentant un risque élevé ; le fichier index.php, fichier de Protection standard de PrestaShop, n’est plus signalé comme exécutable suspect ; la rubrique « Modifications récentes » affiche les totaux de la dernière comparaison et, après la création d’une base de référence, le tableau de bord ne présente plus la comparaison précédente comme étant actuelle.
Le Back Office affiche « Traitement en cours depuis la console » pendant que le traitement par console est en cours ; le rafraîchissement de la page après avoir cliqué sur un bouton ne relance plus le processus, et un « démarrage rejeté » indique quelle tâche est en cours. Le traitement par console affiche une brève ligne de progression au lieu d’une ligne par étape.
Cohérence du Back Office : le panneau des tâches et ses boutons ont le même aspect que le reste du panneau, et les messages d'état du cron et du journal d'activité s'affichent dans la langue du Back Office, et ce dans les neuf langues.
Le panneau d’assistance et de diagnostic est placé juste avant la section Integrity, comme dans les autres modules PrestaWard, et dans le contexte « toutes les boutiques », il ne disparaît plus : cela indique qu’il faut sélectionner une boutique.
Les feuilles de style sont chargées avec la version du module, de sorte que le nouveau design s'affiche après la mise à jour sans qu'il soit nécessaire de vider le cache du navigateur.
Se synchronise avec Integrity à chaque ouverture du tableau de bord, via une requête en arrière-plan qui ne ralentit jamais le chargement de la page, à raison d’au maximum une fois par minute et par boutique.

0.1.6

Un lien symbolique n'interrompt plus l'analyse : il est ignoré sans être suivi ni faire l'objet d'un calcul d'empreinte (il ne fait donc pas partie de la base de référence) et est signalé dans le tableau de bord, avec une alerte lorsqu'il pointe vers l'extérieur de la boutique ou vers une destination inexistante.
Écarte, lors de l'analyse, les fichiers qui ne peuvent pas faire partie du manifeste.
Ne parcourt jamais les dossiers temporaires de PrestaShop (img/tmp) ni les caches de ressources combinées du thème, qui sont constamment régénérés et pourraient interrompre une analyse avec directory_changed.
Applique les exclusions avant d’accéder à chaque dossier : les dossiers exclus ne font plus partie de l’analyse d’intégrité et ne sont surveillés que pour détecter la présence de fichiers exécutables, lors d’un passage distinct qui n’interrompt jamais la tâche et qui est limité à 250 000 noms par tâche.
Il relit jusqu’à trois fois un dossier inclus qui change au cours de l’analyse. S’il continue à changer, les dossiers du cœur, de la configuration, de l’administration, des modules de paiement et du thème actif interrompent la tâche comme auparavant ; les autres sont ignorés avec un avertissement et la tâche s’achève.
Le cron traite plusieurs lots consécutifs par appel (jusqu’à environ 20 secondes) et signale, avec le statut cli_required et la réponse HTTP 409, lorsqu’une tâche nécessite le processus en ligne de commande. Un outil de surveillance qui considère toute réponse autre que 2xx comme une erreur le signalera, comme on peut s’y attendre. Ce processus est exécuté manuellement par l’administrateur du serveur : le module ne le lance jamais de lui-même.
Renforce le verrouillage qui empêche les exécutions simultanées du cron, même si les deux premières exécutions coïncident.
Déplace les fichiers temporaires du manifeste vers un répertoire privé au sein de la boutique, compatible avec open_basedir et avec le nettoyage du répertoire temporaire du système. Dans Nginx, il est recommandé de bloquer l'accès à var/prestaward-snapshot/.
Détecte les tables qui n'utilisent pas InnoDB, affiche un message clair dans les neuf langues et convertit les tables du module lors de la mise à jour, en enregistrant chaque conversion.
Ajoute un panneau de vérification de l'état dans le Back Office, en lecture seule : dossier privé de préparation, moteur de stockage de la base de données, fréquence du cron et tâches en attente de traitement par la ligne de commande.
Corrige les totaux du rapport des tâches : les liens sont comptabilisés séparément des fichiers exclus.
Chaque module n'est analysé qu'une seule fois, soit dans le cadre des paiements, soit dans celui des modules ; ainsi, un module qui n'est pas une passerelle de paiement et qui subit des modifications pendant l'analyse ne bloque plus la tâche.
Si une tâche ne peut pas couvrir entièrement un dossier, l’instantané s’affiche avec une couverture partielle et la comparaison marque les fichiers de ces dossiers comme « non vérifiés », plutôt que comme supprimés.
Le tableau de bord des tâches indique les dossiers concernés par chaque type d’alerte et les actions à entreprendre, dans les neuf langues. La désinstallation supprime également les tables de tâches.
PrestaShop 9 : le processus en ligne de commande et le cron ne rencontrent plus d'erreur lorsqu'ils confondent le dossier « admin-api » du cœur avec celui du Back Office.
Lorsque le processus en ligne de commande échoue, il se termine par une ligne de diagnostic comportant un code de motif fixe, sans chemins d'accès ni messages internes.
Réduit le coût de l'analyse dans les boutiques comportant de nombreux fichiers.
PHP 7.1 et 7.2 : l'inscription, l'attestation et le « heartbeat » d'Integrity ne sont plus bloqués par une erreur de syntaxe.
Corrige la mise à jour depuis la version 0.1.5 lorsque la table des instantanés est absente.
Testé en laboratoire sur PrestaShop 1.7, 8 et 9, y compris un test portant sur 300 000 fichiers modifiés au cours de l'analyse.

0.1.5

Réinitialise les tentatives automatiques d’attestation d’Integrity, les heartbeats en attente et la conservation après les réponses du cron asynchrone. La maintenance s’exécute par lots délimités et est coordonnée indépendamment de l’avancement de l’analyse.
Si une base de référence antérieure comprenait plusieurs dossiers d'administration, la comparaison suivante peut afficher des entrées supplémentaires : vérifiez les différences et créez une nouvelle base de référence le cas échéant, sans supprimer automatiquement la précédente.
Autorise les noms de fichiers valides comportant des points consécutifs et maintient la Protection contre les chemins d'accès non sécurisés.
Conserve tous les fichiers des dossiers d'administration supplémentaires sans les confondre avec ceux du Back Office actif.
Enregistre l'avancement des bases de référence et des comparaisons afin de pouvoir reprendre après avoir fermé le panneau ou interrompu une requête.
Traite et vérifie les fichiers par lots ; les résultats ne s’affichent qu’une fois la tâche terminée et la dernière base de référence valide est conservée en cas d’annulation ou d’échec.
Corrige la comparaison des fichiers d'administration par rapport aux bases de référence antérieures et conserve les exclusions des dossiers décochés.
Ajoute un rapport de diagnostic téléchargeable afin de le joindre manuellement à une demande d’assistance, sans envoyer de données automatiquement. Ce rapport n’est téléchargé que par un employé disposant d’une autorisation de modification et ayant sélectionné une boutique ; il ne contient ni chemins d’accès, ni contenu de fichiers, ni identifiants.
Complète les états du tableau de bord, les notifications et les modèles d'alerte en neuf langues.
Conserve les corrections d'inscription et de mise à jour de la version 0.1.4.

0.1.4

Corrige les erreurs d'inscription d'Integrity dans PrestaShop 9 et conserve l'inscription existante lors de la mise à jour des boutiques sans mode multiboutique.
Réinitialise les tentatives automatiques d'inscription et enregistre la cause réelle des échecs.
Mise à jour de la présentation générale du Back Office et ajout d'informations sur le traitement des données.
Adapte les formats des nombres et des durées à la langue de l'administrateur et traduit les états et les libellés du panneau de configuration.
Corrige la version installée lors de la mise à jour.
Prépare le paquet AFL-3.0 pour Addons : supprime le vérificateur de mises à jour et calcule l'identité à partir des fichiers installés.

0.1.3

Correctif de sécurité : l'analyse couvre désormais l'ensemble de l'installation de PrestaShop, y compris les dossiers override, src, vendor, upload, download, img, js ainsi que les fichiers à la racine.
Correctif de sécurité : les fichiers présentant un risque pour la sécurité sont toujours surveillés, quelle que soit leur extension.
Correctif de sécurité : renforce la vérification des attestations à distance et interrompt les nouvelles tentatives automatiques lorsque la clé d'enregistrement de la boutique change.

0.1.2

Heartbeat automatique sans cron, activé de manière non bloquante par le trafic normal de la boutique.
La requête du navigateur reste sur le même domaine et les identifiants Integrity sont utilisés uniquement sur le serveur.
Blocage par boutique, intervalle de six heures et délai d’attente après les échecs pour éviter les doublons.
La synchronisation manuelle d’Integrity met également à jour la présence de l’installation.

0.1.1

Heartbeat d'Integrity et surveillance de l'état de santé du cron.
Hachage incrémental sécurisé avec révision complète périodique et recalcul systématique des zones critiques.
Classification des modifications de routine, suspectes et critiques.
Filtres, pagination, révision avec annotations et exportation CSV de l'audit.
Différences de métadonnées sans stockage de contenu et conservation avec nettoyage protégé.
Tableau de bord visuellement harmonisé avec l'écosystème PrestaWard.

0.1.0

Inscription automatique et non bloquante dans PrestaWard Integrity API.
File d'attente locale avec nouvelles tentatives pour attester chaque manifeste sans envoyer de fichiers ni de contenu.
Reçus à distance signés, chaînés et vérifiés au sein de la boutique.
État de la connexion et de la livraison visible depuis le tableau de bord.

0.0.9

Liens d'aide contextuelle depuis les champs de configuration vers le guide public.
Guide public réorganisé par objectif et par champ, avec une explication pratique de chaque réglage.
Suppression, dans la configuration, de l'affichage redondant de la source des mises à jour.

0.0.8

Exclusions configurables par nom exact et chemin relatif, avec une politique immuable et un hachage SHA-256.
Aperçu obligatoire avant d'activer une politique et de créer votre nouvelle base de référence.
Blocage des comparaisons entre différentes politiques.
Surveillance non configurable des exécutables et des fichiers de configuration situés dans des zones exclues.
Détection ciblée des en-têtes PHP et des interpréteurs dangereux dans les fichiers dotés d’une extension trompeuse.
Validation complète sous PrestaShop 1.7, 8 et 9, y compris un test mixte avec 100 000 fichiers.

0.0.7

L'identité complète du produit et du module technique a été renommée PrestaWard Snapshot.
Accès initial réservé au profil d'administrateur.
Autorisation explicite de profils supplémentaires via les autorisations natives de PrestaShop.
Séparation de la lecture, création d'instantanés et configuration à l'aide des droits READ, CREATE et UPDATE.
Masquage des paramètres de configuration, des jetons cron et des actions sensibles pour les profils en lecture seule.
Précision apportée à la documentation : le module assure la surveillance de l’intégrité, mais ne stocke ni ne restaure de sauvegardes.

0.0.6

Les liens vers les produits, le guide, les fournisseurs et l'assistance sont conservés après une réinstallation à zéro.
Mise à jour des métadonnées à partir du manifeste public.
Logos de GO ON Agency liés dans le Back Office et les e-mails.
URL alternative visible dans les e-mails au format HTML et en texte brut.
Action de test par e-mail et outils de mise en production reproductibles.

0.0.5

Correction du chargement automatique du contrôleur hérité.
L'accès a été déplacé vers la section racine PrestaWard Snapshot.

0.0.4

Menu du Back Office cliquable.
Validation complète du cycle d'installation et de désinstallation.

0.0.3

Contexte multiboutique explicite.
Prise en charge des propriétés dynamiques dans PHP 8.5.

0.0.2

Rôles d'autorisation et droits d'accès explicites.

0.0.1

Référence, comparaison, alertes, cron, journaux, vérification des mises à jour et tableau de bord initial.