Prestashop 1.7 – Spam compte client (ép. 75)

Après une première grande vague de SPAM sur les formulaires de contact de Prestashop, c’est à présent le formulaire de création de compte client qui est touché… Je vous explique comment rectifier le problème, pour éviter ces intrusions.

Attaque massive de SPAM sur Prestashop

Ces derniers jours j’ai de multiples clients qui me contactent parce qu’ils ont remarqué que des faux comptes clients inondent le back-office. Récemment on avait déjà vu des attaques sur les formulaires de contact Prestashop avec du SPAM de Russie… mais là c’est encore différent. Le problème c’est que cette intrusion vient salir votre base de données et pourrait même ternir à votre réputation (vous allez comprendre pourquoi).

Quel est le but du hacker ?

Il est toujours difficile de répondre précisément… parfois c’est simplement de nuire sans objectif précis. Le danger pour vous c’est que vous risquez de stocker des mails obsolètes et que si vous liez tout ça à un outil de mailing, vous pourriez être blacklisté. Si vous utilisez un service de mailing et que ces mails sont détectés comme frauduleux, la notoriété de votre domaine pourrait être remis en cause.

Prestashop est-il fiable et sécurisé ?

Oui, la solution Prestashop est robuste, mais doit aussi parfois subir des patchs de sécurité. Avant de faire une mise à jour complète de Prestashop, je vous conseille plutôt d’effectuer la mise en place d’overrides comme présenté dans le tutoriel ci-dessous. Plus un outil est populaire, plus celui-ci est exposé à des tentatives de hacking, on voit régulièrement cette problématique par exemple avec WordPress… aucune solution n’est invulnérable.

Comment bloquer l’intrusion du hacker ?

Les comptes clients qui sont créés contiennent en principe le nom d’un site web douteux dans le prénom ou le nom. Le principe est donc assez simple, on va vérifier le contenu de ces deux champs au moment de la validation du formulaire et afficher une erreur en retour si celui-ci contient une url. Chez les clients où le patch a été appliqué les intrusions ont cessées immédiatement.

Est-ce que ce correctif est durable ?

Oui pour le moment… cela dépendra si le hacker va améliorer sa méthode d’intrusion. Son but reste quand même d’injecter l’url d’un site web malicieux (pour tenter de faire du phishing ou autre). A mon avis il est possible que si le hacker utilise un nom / prénom classique, l’insertion fonctionne. Si cela arrive, il faudra passer au niveau supérieur avec une sécurité de plus du type reCatpcha (mais ça c’est encore une autre histoire).

Pour ce tutoriel vous avez à disposition :

  • 1 x fichier « Customer.php » (pour modifier la règle de contrôle)
  • 1 x fichier « Validate.php » (pour vérifier la présente d’urls)
  • 1 x fichier « customers_clean.php » (pour nettoyer les comptes clients)

Télécharger

Résumé de la vidéo : Stoppez les intrusions dans Prestashop

  • Pour commencer il suffit simplement d’ajouter les deux fichiers d’overrides sous « override/classes/ ».
  • Ensuite, il faut vider le cache de Prestashop, afin que les nouveaux comportements puissent s’appliquer.
  • Je vous montre aussi comment supprimer massivement l’ensemble des comptes clients obsolètes grâce au script de suppression.
  • Par la même occasion je prends un peu de temps pour vous expliquer les processus pour vous montrer comment fonctionne le code que l’on a mis en place (cela vous permet aussi de mieux comprendre le mécanisme).
  • Sur le forum Prestashop on retrouve le topic dédié au SPAM des comptes clients, avec les explications.
Notez mon billet, Google va adorer :
1 étoiles - J'aime pas !2 étoiles - Bof !3 étoiles - Bien !4 étoiles - Très bien !5 étoiles - Génial ! (17 votes, moyenne : 4,82 sur 5)
Loading...

25 commentaires sur “Prestashop 1.7 – Spam compte client (ép. 75)”

  1. Salut, et bravo pour tes tutos.

    Il me semble que c’est le même soucis pour les versions 1.5 et 1.6

    D’ailleurs, il y a une publication sur le forum avec la solution pour se 2 versions.

    Cordialement

    1. Hello,

      Merci pour le retour, oui en fin de billet j’ai posté le lien vers le forum… le concept est exactement le même (mais à vérifier dans Customer.php si la liste des champs est bien identique).

      A bientôt !

      1. Bonjour,
        j’avais ce problème depuis quelques mois j’avais réussi à bloquer par le .htaccess avec des « deny from » et l’adresse IP et l’hôte, mais là Il est revenu, j’ai remis en place des « deny from »
        mais le souci c’est que du coup j’effaçais ces « clients » en interdisant la réinscription, ce qui fait gongler ma BDD,
        Donc comment les effacer après avoir mis ta méthode en place? Directement par la Base non?
        Merci.

        1. Hello,

          Pour supprimer ces comptes clients « invisibles » qui ont déjà été supprimés… il faudra effectivement passer via la base de données et regarder sur « ps_customer », il doit y avoir des comptes avec la colonne « deleted » à « 1 »… c’est ceux-là qu’il faut retirer.

          A bientôt !

    1. Hello,

      J’ai utilisé la même méthode pour Prestashop 1.5 et 1.6 cela fonctionne… mais idéalement dans « Customer.php » il faut bien définir les champs (comme dans le fichier original de votre version « /classes/Customer.php »).

      A bientôt !

  2. Un grand merci pour ce tuto !
    Le script de nettoyage est très efficace, nous voilà débarrassé (pour le moment… ) de cette attaque.
    Fonctionne sur 1.5 et 1.6 🙂
    Bonne continuation et encore merci de partager tes connaissances

  3. bon j’ai testé la solution de germain sur les 1.6 cela ne fonctionne pas

    l’overide bloque bien la fonction url mais quand on valide l’inscription on a une erreur 500 et j’ai bien vidé le cache avant

    j’ai testé sur 2 boutiques en
    1.6.1.20
    1.6.1.18

    1. Hello,

      Il faut essayer activer le debug pour voir le message d’erreur en clair (éventuellement prendre les fichiers source sur le forum Prestashop, il me semble avoir vu passer d’autres fichiers).

      A bientôt !

      1. Pour être honnête je suis pas un cador du code j’ai grâce à ta vidéo bien compris ta procédure, le pourquoi du comment, je l’ai tenté malgré tout pour essayer parce je sais que tu es calé sur presta et que tu apportes toujours des solutions pratiques.
        J’ai finalement utilisé la méthode de doekia et eolia sur le forum de presta sur le sujet et avec patience j’ai résolu le problème. En tout cas merci à l’ensemble des protagonistes dont toi.

        1. Hello,

          Alors c’est TOP, oui sur le forum Prestashop c’est parfois plus facile car il y a de l’interaction et des échange entre les membres, ça permet parfois de mieux comprendre où l’on s’est trompé (grâce au retour d’expérience des autres).

          A bientôt !

  4. Bonjour Germain,
    Merci pour ce tuto vidéo qui éclaire le post de Doekia sur le forum.

    Pour ceux qui comme moi sont en PS 1.6, vous pouvez utiliser le validate.php donné ici mais n’ajoutez pas customer.php dans override/classes sinon vous aurez une erreur 500 à la création d’un nouveau compte sur le FO de votre boutique.

    SOLUTION : Suivez les conseils de Doekia sur le premier post du forum et remplacez ‘isName’ par ‘isCustomerName’ directement dans le fichier classes/customer.php… et là, tout fonctionne 🙂

    Grand merci à Doekia, Eolia et Webbax de nous aider à protéger nos boutiques ! Bon dimanche à tous

    1. Bonjour,

      Effectivement on peut aussi le faire comme ça en modifiant le fichier du coeur (c’est plus facile pour ceux qui ont moins l’habitude des overrides).

      A bientôt !

  5. Merci pour ce tuto !
    Cependant, lorsque je regarde les stats du module reCaptcha je remarque que toutes les 15min il y a une tentative d’inscription client ou inscription newsletter.
    Toutes les tentatives sont bien bloquées mais est-ce que ça ne surcharge pas mon serveur ? Je trouve mon site plus lent depuis quelque temps.

    Inutile de bloquer les IP, elles changent à chaque tentative. Une idée pour bloquer ces bots avant qu’ils puissent tenter de s’inscrire ? :-/

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *