Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Le nom de ma boutique affiche du texte que je n’ai pas écrit

Un fragment de code apparaît dans le pied de page, dans l’onglet du navigateur ou dans les e-mails de commande : la valeur de configuration qui porte le nom de la boutique a été modifiée directement en base de données, et elle sert de véhicule.

Décrire mon problème Discuter sur WhatsApp

Un bug d’affichage qui n’en est pas un

Le symptôme est presque toujours décrit de la même façon : « il y a du charabia dans le pied de page », « l’onglet du navigateur affiche du code », « le nom de ma boutique est cassé dans les e-mails de commande ». Le réflexe habituel est de chercher une mauvaise traduction, un thème mal configuré, un caractère parti de travers pendant un import. Ce n’est presque jamais cela.

Le nom de la boutique n’est pas un texte du thème. C’est une valeur de configuration stockée en base de données, sous la clé PS_SHOP_NAME. La boutique la relit et la réaffiche à des dizaines d’endroits : en-tête, pied de page, titre de la page dans l’onglet du navigateur, e-mails transactionnels, factures, notifications internes. Une seule ligne en base, servie partout, et pas toujours traitée de la même manière selon l’endroit où elle réapparaît.

C’est ce qui en fait une cible utile pour un attaquant. Il n’a pas besoin de modifier un fichier du thème, ni de toucher au tunnel de commande, ni de laisser un fichier sur le serveur. Il écrit une fois dans une valeur de configuration, et son contenu est ensuite servi sur toutes les pages, à tous les visiteurs, y compris ceux qui sont en train de payer. Le texte bizarre que vous voyez dans le pied de page n’est pas le problème : c’est la partie visible d’une chaîne dont le reste est silencieux.

Ce qui doit vous alerter

  • Un fragment de balise ou de code visible dans le pied de page, là où le nom de la boutique s’affiche normalement.
  • Le titre de l’onglet du navigateur qui contient un texte que vous n’avez jamais saisi.
  • Le nom de la boutique déformé dans les e-mails de confirmation de commande ou sur les factures.
  • Un champ « Nom de la boutique » qui paraît normal dans le back-office alors que le site public affiche autre chose.
  • Un script que vous ne reconnaissez pas dans le code source des pages, y compris sur le tunnel de commande.
  • Des clients qui signalent qu’on leur a demandé deux fois leurs informations de paiement.

Ce que PrestaShop a documenté en janvier 2025

Le 22 janvier 2025, PrestaShop a publié une alerte officielle sur une vague d’attaques exploitant des failles d’injection SQL présentes dans des modules tiers, et non dans le cœur. Le mode opératoire décrit est exactement celui-ci : les attaquants insèrent du contenu malveillant dans la valeur de configuration PS_SHOP_NAME stockée en base ; cette valeur sert ensuite à charger du JavaScript non autorisé qui capture les saisies des clients. La vérification recommandée par PrestaShop est simple à énoncer : chercher un script ou un contenu inattendu dans la valeur PS_SHOP_NAME, en base de données.

Ce JavaScript n’est pas là pour dégrader l’affichage. Il est là pour lire ce que vos clients tapent dans le tunnel de commande : coordonnées, adresse, informations de paiement. Dans les campagnes les plus abouties, la surcouche est soignée : un faux formulaire de paiement s’affiche d’abord, le client saisit sa carte, puis le vrai formulaire lui redemande les mêmes informations. La plupart des clients acceptent cette double saisie et terminent leur commande sans se douter que les données ont déjà été volées. C’est pour cela que ce symptôme ne peut pas être traité comme un défaut cosmétique.

Côté correctifs, PrestaShop a publié une version corrigée du module officiel ps_contactinfo, la 3.3.3, compatible PrestaShop 1.7.2 et plus, avec l’avis GitHub GHSA-35pq-7pv2-2rfw. Les recommandations officielles ne s’arrêtent pas là : mettre à jour l’ensemble des modules natifs et tiers, utiliser un préfixe de base de données personnalisé plutôt que le préfixe par défaut, déployer un pare-feu applicatif, faire des sauvegardes régulières et suivre les avis de sécurité PrestaShop.

Lecture seule : valeur réellement stockée en base
SELECT name, value FROM ps_configuration WHERE name = 'PS_SHOP_NAME';

Pourquoi lire la valeur en base et pas seulement dans le back-office

La requête ci-dessus est une lecture, elle ne modifie rien. Le préfixe ps_ doit être remplacé par celui de votre installation : si vous avez suivi la recommandation d’un préfixe personnalisé, le nom de la table est différent chez vous.

Pourquoi passer par la base plutôt que par le champ du back-office ? Parce que le back-office affiche la valeur dans un formulaire, et qu’un formulaire échappe, tronque ou masque une partie de ce qu’il reçoit. Une valeur qui paraît normale dans un champ de saisie peut contenir bien autre chose une fois servie dans une page. La lecture en base vous donne la valeur brute, celle qui est réellement enregistrée, sans intermédiaire d’affichage. C’est la seule vérification qui tranche.

Le préfixe par défaut joue un rôle direct dans ce scénario. Une écriture qui vise une table doit connaître son nom. Avec le préfixe standard, ce nom est identique sur des centaines de milliers de boutiques : il n’y a rien à deviner, et une attaque écrite une fois s’applique partout sans adaptation. Changer le préfixe ne corrige aucune faille, ce n’est pas une protection en soi ; c’est ce que PrestaShop recommande précisément parce que cela supprime une facilité gratuite offerte aux attaques automatisées.

Ce que je fais dans cet ordre

  1. Lire la valeur brute en base

    Avec la requête de lecture ci-dessus, adaptée à votre préfixe. Vous cherchez la présence d’un script ou d’un contenu inattendu dans la valeur, pas seulement un nom mal orthographié.

  2. Comparer avec ce que sert réellement la page publique

    Affichez le code source d’une page du site et regardez les endroits où le nom de la boutique est réaffiché : en-tête, pied de page, titre du document. Un écart entre la base et la page indique où la valeur est réinterprétée.

  3. Vérifier les fichiers du thème

    La valeur de configuration n’est pas le seul véhicule possible. Des balises de script peuvent aussi être injectées directement dans les fichiers du thème, en particulier dans les gabarits chargés sur toutes les pages. Comparez le thème avec une copie saine.

  4. Corriger la valeur, puis chercher l’écriture

    Rétablir un nom de boutique propre fait disparaître le symptôme en quelques minutes. Cela ne dit rien sur la façon dont la valeur a été écrite. Tant que le module qui a permis cette écriture est en place, la valeur peut être réécrite.

  5. Mettre à jour l’ensemble des modules

    C’est la première recommandation officielle : les modules natifs comme les modules tiers. Le module officiel ps_contactinfo dispose d’une version corrigée en 3.3.3, compatible PrestaShop 1.7.2 et plus.

  6. Traiter l’incident comme une possible violation de données

    Si du JavaScript non autorisé a été servi sur le tunnel de commande, des données clients ont pu être capturées. Cela relève des obligations de notification, et cela se documente : dates, pages concernées, durée d’exposition.

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Quelle plateforme ?
Depuis quand le problème est-il constaté ? (facultatif)

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?

Une sauvegarde antérieure à l’infection change complètement la méthode de remise en état.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Le champ paraît normal dans le back-office, est-ce que c’est bon signe ?
Non, ce n’est pas concluant. Le back-office affiche la valeur dans un formulaire qui peut l’échapper ou la tronquer. Seule une lecture directe en base vous donne la valeur brute, telle qu’elle est servie aux visiteurs.
Je remets le bon nom de boutique et tout redevient normal, c’est réglé ?
Le symptôme disparaît, pas la cause. Le mode opératoire décrit par PrestaShop en janvier 2025 passe par une faille d’injection SQL dans un module tiers. Si ce module est toujours là dans une version vulnérable, la valeur peut être réécrite.
Pourquoi viser le nom de la boutique plutôt qu’une page précise ?
Parce qu’il est réaffiché partout : en-tête, pied de page, titre de l’onglet, e-mails transactionnels, factures. Une seule écriture en base suffit pour que le contenu soit servi sur l’ensemble du site.
Changer le préfixe de base de données protège-t-il vraiment ?
Ce n’est pas une protection en soi, aucune faille n’est corrigée par ce changement. C’est une recommandation officielle de PrestaShop parce que le préfixe par défaut rend le nom des tables identique partout, ce qui facilite les attaques automatisées.
Mes clients sont-ils concernés ?
Si du JavaScript non autorisé a été chargé sur les pages de commande, il faut partir du principe que des saisies ont pu être capturées. C’est à traiter comme une possible violation de données, avec le registre et les notifications qui vont avec.

Pages liées