Jump to content

Recommended Posts

Posted (edited)

Merci @Eolia et @doekia Les overrides fonctionnent très bien. J'a pu testé la création d'un compte sans url et la création bloquée d'un compte avec URL.

Pour info, ça prend max 15mn la mise en place du patch (en manuel) + les tests

Edited by Cloud Nine

Share this post


Link to post
Share on other sites
4 hours ago, La vie en Rose said:

@passicool

Par curiosité j'ai testé, mais soit t'as beaucoup de chance soit ma boutique est pourrie, en tout cas j'ai laissé le type de création de compte avec l'option compte et adresse toute la nuit, et résultat, quelques vingtaines d'inscriptions bidon du même type, et plus bizarre encore, inscription sans adresses...

Bref, je pense que dans tous les cas il vaut mieux prévenir que guérir, et prendre 5 minutes pour appliquer la solution si gentiment donné.

Edit : J'allais remettre le type d'enregistrement sur simple, et je viens de m'apercevoir en virant les clients bidons que si, ils ont entrés une adresse.. bidon, forcément

      Capture.thumb.png.93eb16d77a7f3de933ef67fce57a7832.png

Bonjour,

Oui des adresses bidon sont entré mais pays=Royaume unis, si ton prestashop est limité à la France comme moi bin les adresses dans les autres pays passent pas et du coup l'inscription est invalide. C'est pas de la chance j'ai bien précisé pour ceux qui vendent uniquement en France dans le sens qui est limité à la France.

Share this post


Link to post
Share on other sites

Petit retour d'expérience . J'ai patché le module Sendinblue comme expliqué par @Eolia et depuis maintenant 9h, je n'ai plus de spam dans ma liste de contact Sendinblue.

Grand grand merci @Eolia 👍

Je suis sous prestashop 1.6.1.18 et mon module SendinBlue v2.7.8

Share this post


Link to post
Share on other sites
8 hours ago, Eolia said:

Rajoutez ceci

image.thumb.png.1634ddd58b3421bb3de3a89de9f9dd8f.png

Petit retour par rapport à cette ligne de code : MERCI !

Depuis qu'elle est installée, plus d'inscriptions de fake contact dans ma base de mailing SendInBlue.

Donc un très grand merci à toi @Eolia

Share this post


Link to post
Share on other sites

Merci pour le patch, appliqué avec succès en automatique sur un 1.6.1.20

Share this post


Link to post
Share on other sites
1 hour ago, passicool said:

Bonjour,

Oui des adresses bidon sont entré mais pays=Royaume unis, si ton prestashop est limité à la France comme moi bin les adresses dans les autres pays passent pas et du coup l'inscription est invalide. C'est pas de la chance j'ai bien précisé pour ceux qui vendent uniquement en France dans le sens qui est limité à la France.

Ce que je ne comprends pas c'est pourquoi mettre du sparadrap sur une fuite de gaz. ça tiens peut-être un moment mais ça va finir par te péter à la figure.

Vous prennez vraiment les hacker pour des enfants de coeur doublé d'imbécile? Ils ont réussit a réunir un catalogue de boutique prestashop qui couvre le monde entier mais seraient incapable d'ajuster un bot sur la liste des pays? c'est vraiment ridicule

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Merci doekia

Implémenté sur un Prestashop v1.4.8.2 par surcharge de classe (override)

/override/classes/Customer.php

<?php
class Customer extends CustomerCore
{
	protected	$fieldsValidate = array('secure_key' => 'isMd5', 'lastname' => 'isCustomerName', 'firstname' => 'isCustomerName', 'email' => 'isEmail', 'passwd' => 'isPasswd',
		 'id_gender' => 'isUnsignedId', 'birthday' => 'isBirthDate', 'newsletter' => 'isBool', 'optin' => 'isBool', 'active' => 'isBool', 'note' => 'isCleanHtml', 'is_guest' => 'isBool');
}
?>

 

/override/classes/Validate.php

<?php
class Validate extends ValidateCore
{
    public static function isCustomerName($name)
    {
            if (preg_match('/www|http/ui',$name))
        {
                return false;
        }
            return preg_match('/^[^0-9!\[\]<>,;?=+()@#"°{}_$%:\/\\\*\^]*$/u', $name);
    }
}
?>

 

Edited by cmak
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

@Jean André

Citation

J'ai raté quelque chose? 

 

Oui, dans votre cas: 

A partir de la version 1.5, comme toujours en cas d'erreur 500 et pour en savoir plus, il faut modifier cette ligne au début du fichier config/defines.inc.php sur votre ftp :

define('_PS_MODE_DEV_', false);

en remplaçant false par true, ce qui donne:

define('_PS_MODE_DEV_', true);

Et donnez-nous l'erreur après avoir enregistré le fichier et rafraîchi la page

Edited by Eolia
  • Thanks 1

Share this post


Link to post
Share on other sites
4 hours ago, Eolia said:

@Jean André

 

Oui, dans votre cas: 

A partir de la version 1.5, comme toujours en cas d'erreur 500 et pour en savoir plus, il faut modifier cette ligne au début du fichier config/defines.inc.php sur votre ftp :

define('_PS_MODE_DEV_', false);

en remplaçant false par true, ce qui donne:

define('_PS_MODE_DEV_', true);

Et donnez-nous l'erreur après avoir enregistré le fichier et rafraîchi la page

Merci pour l'astuce du define.inc cela ma permis de trouver le BOM que j'avais raté. dans mon cas en effet c'était les BOM j'en avais a 2 endroits j'ai nettoyé et j'ai testé sur la 1ere boutique ça a fonctionné du coup j'ai recopié les 2 petits bouts de codes pour la seconde boutique.

Je les ai modifié y a quelques minutes donc je vais voir si ça fonctionne pour contrer notre ami commun

par contre petit point de détail en testant si ça fonctionnait j'ai noté que:

effectivement www.ndd.fr est bien bloqué en nom et en prénom

par contre si le petit emmerdeur s'amuse à faire: 

ndd.fr dans nom ou prénom ça passe comme avant. si d'aventure ça venait à l'esprit d'un emmerdeur je sais pas si cela a été mentionné dans le sujet. 

Share this post


Link to post
Share on other sites

sans http:// et/ou sans www ca ne devient plus des liens cliquables^^

Share this post


Link to post
Share on other sites

C'est moi ou le PR empêchera tous les clients avec un . de mettre à jour leur profil ?

Ce n'est pas terrible comme solution ... ou je me trompe ?

Share this post


Link to post
Share on other sites
il y a 49 minutes, okom3pom a dit :

C'est moi ou le PR empêchera tous les clients avec un . de mettre à jour leur profil ?

Ce n'est pas terrible comme solution ... ou je me trompe ?

. suivi d'un ou plusieurs espace ok cutt.us refusé

Par contre comme mentionné sur github avoir changé la fonction isName pose des problème avec les adresses utilisé par certains modules pickup

  • Like 1

Share this post


Link to post
Share on other sites

Merci pour la précision sur une boutique comme la mienne avec 300K clients j'ai pas mal d'occurrences avec point sans espace

Share this post


Link to post
Share on other sites

Bonjour,


Tout d'abord merci d'avoir exposé la solution, je suis comme les autres membres touché par cette vague de spam sur prestashop et cela m'empêche de me connecter à mon ftp via filezila. Je passe du coup direct par le ftp accessible depuis ovh pour effectuer les modifications.

J'ai effectué les modifications gentiment proposées par Doekia, lorsque j'essaye de supprimer un client via mon interface prestashop j'obtiens le message suivant :
"
Property Customer->lastname is not valid "

J'ai sans doute fait quelque chose de travers, je précise que je suis relativement une bille en php :) !
Merci d'avance pour vos conseils !

Share this post


Link to post
Share on other sites
il y a 2 minutes, Djoul84 a dit :

Bonjour,


Tout d'abord merci d'avoir exposé la solution, je suis comme les autres membres touché par cette vague de spam sur prestashop et cela m'empêche de me connecter à mon ftp via filezila. Je passe du coup direct par le ftp accessible depuis ovh pour effectuer les modifications.

J'ai effectué les modifications gentiment proposées par Doekia, lorsque j'essaye de supprimer un client via mon interface prestashop j'obtiens le message suivant :
"
Property Customer->lastname is not valid "

J'ai sans doute fait quelque chose de travers, je précise que je suis relativement une bille en php :) !
Merci d'avance pour vos conseils !

Bonjour,

J'espère ne pas me tromper, mais il aurait fallu supprimer ces clients avant de faire les modifs. Du coup, deux options :

- soit modifier les noms des clients pour ensuite pouvoir les supprimer
- soit revenir sur les modifs, supprimer les clients, puis remettre les modifs

Et je crois même qu'il y a une troisième option, avec le script mis à dispo, mais à confirmer par un expert.

  • Thanks 1

Share this post


Link to post
Share on other sites

Il faut supprimer les clients indésirables avant de lancer le patch

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Je vais l'écrire en gros parce qu'après l'avoir dit 20x personne ne le lit

 

Supprimez intégrale le compte client - permettez qu'il se réinscrive

Edited by doekia
  • Thanks 1
  • Haha 1

Share this post


Link to post
Share on other sites

Au top ! Tout fonctionne et l'accès FTP est revenu.
Merci à tous pour la réactivité et bonne fin de semaine ;)

Share this post


Link to post
Share on other sites
Posted (edited)
8 minutes ago, P i l o u said:

Il faut supprimer les clients indésirables avant de lancer le patch

Cela me semble faux car j'ai appliqué le patch manuellement, testé la création d'un compte (sans url dans le nom) que j'ai ensuite supprimé et ça fonctionne bien.

Edited by Cloud Nine

Share this post


Link to post
Share on other sites
Posted (edited)
20 minutes ago, Djoul84 said:

je suis comme les autres membres touché par cette vague de spam sur prestashop et cela m'empêche de me connecter à mon ftp via filezila.

(---)
J'ai sans doute fait quelque chose de travers, je précise que je suis relativement une bille en php :) !
 

- Je pense qu'il n'y a aucun rapport entre ces faux comptes et le ftp.

- Pas besoin d'être une bête en php pour appliquer le patch mais sans connaissance, je recommande de passer par un développeur web sinon vous prenez le risque de faire n'importe quoi. Je vous donne une image : je n'y connais rien en mécanique auto. Je démonte quand même mon moteur en ne sachant pas vraiment ce que je fais et après viens sur le forum expliquer que ma voiture ne roule plus et que je n'y connais rien. Ça vous parait absurde ? C'est la même chose pour le php et autres langages.

Edited by Cloud Nine

Share this post


Link to post
Share on other sites

Il y a forcément un rapport puisque dès l'application du patch de Doekia cela a été résolu, sachant que cela fait plusieurs jours que le souci était présent. Le robot spam les inscriptions sur le site et surcharge. Avec ce patch il n'y a plus de surcharge donc le ftp redevient accessible via filezila.

Pour ce qui est de mes compétences, j'ai tout de même les bases pour ajouter un code correctement ;) mais je ne saurai faire un site en php à moins de me baser sur de l'existant. Bonne journée

Share this post


Link to post
Share on other sites
il y a 9 minutes, Cloud Nine a dit :

- Je pense qu'il n'y a aucun rapport entre ces faux comptes et le ftp.

 

il y a 3 minutes, Djoul84 a dit :

Il y a forcément un rapport puisque dès l'application du patch de Doekia cela a été résolu,

Je confirme aucun rapport entre les 2, sauf a avoir un serveur vraiment mou du sifflet qui pédalait à gérer sa mail queue, d'ailleurs si tu n'arrivais pas a faire de FTP, comment donc as-tu pu appliquer le patch?

 

Share this post


Link to post
Share on other sites

Via l'accès ftp ovh SSH. OVH m'a clairement dit que l'accès au FTP depuis filezila était bloqué à cause du spam de mail. Comme si il y avait trop de connexion simultanée. Depuis ton patch, plus rien. ;)

Share this post


Link to post
Share on other sites

Ca devient subliminal ici... :blink:

Share this post


Link to post
Share on other sites
On 4/25/2019 at 3:44 PM, Jpc_des_dombes said:

Petit retour d'expérience . J'ai patché le module Sendinblue comme expliqué par @Eolia et depuis maintenant 9h, je n'ai plus de spam dans ma liste de contact Sendinblue.

Grand grand merci @Eolia 👍

Je suis sous prestashop 1.6.1.18 et mon module SendinBlue v2.7.8

Bonjour Jpc

Même soucis que vous dans Sendinblue, ça continue à spammer mon dossier "contacts prrestashop" et pourtant je n'ai plus de créations de nouveaux compte "spams" dans Prestashop

Pourriez vous SVP me donner le nom du fichier à modifier dans le module sendinblue ?

D'avance merci

Share this post


Link to post
Share on other sites

sendinblue.php^^

Share this post


Link to post
Share on other sites

@Eolia est plus rapide que moi...⛷️

Il faut effectivement modifier le fichier sendinblue.php dans le répertoire modules/sendinblue/

Bonne soirée

Share this post


Link to post
Share on other sites
Posted (edited)
On 4/25/2019 at 12:27 PM, Eolia said:

Je vous conseille aussi de patcher le module sendinblue hein^^

Merci beaucoup à tous les deux et à Deokia. J'espère voir la fin de ce cauchemar avec ce dernier patch sur sendinblue :) 

Bon week-end !

Je remets le code à modifier donné par Eolia :

patch du module sendinblue.jpg

Edited by ikaris

Share this post


Link to post
Share on other sites
Posted (edited)

Sinon,

J'ai le "patch + recaptcha" et le robot spam encore les créations de compte, puisque je retrouve ses spams dans sendinblue. (et plus de nouveaux comptes clients dans l'admin)

Que faire de plus ? Il va me spammer mon site à vie ce con ?

C'est quand même une sacrée attaque...car je pense que nous sommes des milliers à avoir été touchés en même temps dimanche dernier. 

D'ailleurs, comment ils trouvent les sites presatshop ? J'ai un second site avec une url en .ovh et là par miracle il a pas été touché comme le .fr. 

Bon WE

 

Edited by ikaris

Share this post


Link to post
Share on other sites

Vous avez du rater quelque chose alors car sur les sites que je gère nous n'avons plus une seule inscription depuis dimanche dernier

PS: trouver un site sous Prestashop est très facile^^

Share this post


Link to post
Share on other sites
Posted (edited)

Je me suis mal exprimé, je n'ai plus non plus de création de faux comptes dans prestashop :)

Je parlais des créations de comptes mails qui continuaient dans sendinblue (avant que je le patch le module sendinblue sur vos instructions), et  c'est ce qui me faisait dire que le robot continuait à s'acharner sur mon site "vacciné" contre lui...

Mais on peux sans doute rien faire, tant qu'il me spam une fois par heure, ça va encore...

Edited by ikaris

Share this post


Link to post
Share on other sites
Posted (edited)

Alors relis ce topic, a peine quelques post plus haut il est expliqué qu'il faut aussi patcher sendinblue (avec le code)

Edited by doekia

Share this post


Link to post
Share on other sites
Posted (edited)

@Doekia

Oui, j'ai patché sendinblue.php, mais ça continue quand même :(

oaed.jpg

Ci-dessous le fichier modifié dans le module sendinblue (ligne 283)  : [fichier supprimé car comportant une erreur vue par Eolia]

 

Edited by ikaris

Share this post


Link to post
Share on other sites

Ben... 

!Validate::isCustorrmerName

ça ne risque pas de fonctionner...

  • Haha 1

Share this post


Link to post
Share on other sites
Posted (edited)

Bonjour Eolia et merci beaucoup d'avoir jeté un oeil sur mon fichier sendinblue. 

J'avais bien une erreur de syntaxe.... A priori c'est ok, ton morceau de code fonctionne bien depuis cette nuit :)

En fait JPC m'avait envoyé son propre fichier sendinblue.php vers 23 h hier soir (sans faute de syntaxe, voir ligne 283) que j'avais mis sur le FTP avant de me coucher cette nuit à 1 h du mat :) 

Et ce matin pas de nouveau spam dans sendinblue, un grand bravo pour avoir trouvé le problème chez eux et un grand merci pour autant d'implication.

Je mets le bon fichier sendinblue ci-dessous (j'ai supprimé celui du post au-dessus).

Bon week-end et merci

sendinblue.php

Edited by ikaris

Share this post


Link to post
Share on other sites

Bonjour

J'ai applique les modification de Doekia... pas d'erreur et ce matin encore des isncriptions pourries...
J'ai  captcha au formulaire de création de compte et j'ai interdit l’accès au serveur de cette adresse IP via Htacces

je seche... que faire ??? si qq peux m'aider je ne vois plus comment eradiquer cela...
merci

Share this post


Link to post
Share on other sites
il y a 1 minute, val a dit :

Bonjour

J'ai applique les modification de Doekia... pas d'erreur et ce matin encore des isncriptions pourries...
J'ai  captcha au formulaire de création de compte et j'ai interdit l’accès au serveur de cette adresse IP via Htacces

je seche... que faire ??? si qq peux m'aider je ne vois plus comment eradiquer cela...
merci

Bonjour,

Tu as supprimé class_index.php ?

Share this post


Link to post
Share on other sites

Si c'est le module eicaptcha, autant ne rien mettre il ne bloque aucun robot^^

Bloquer les adresses IP ne sert à rien, celles-ci changent constamment.

Si vous avez utilisé le système d'override:

- Il faut effectivement supprimer le fichier /cache/class_index.php 

- Il faut également contrôler qu'elles sont activées dans Paramètres avancés -> Performances

Share this post


Link to post
Share on other sites

Et par inscription pourries, nous parlons du même pattern? cutt.us/XYZ dans le nom?

Share this post


Link to post
Share on other sites

oui cutt.us
je n'ai pas utiliser un systeme d'overide mais j'ai modifier le fichier les deux fichiers php directement...

que faut il verifier dans performance ?

Share this post


Link to post
Share on other sites
il y a 9 minutes, val a dit :

oui cutt.us
je n'ai pas utiliser un systeme d'overide mais j'ai modifier le fichier les deux fichiers php directement...

que faut il verifier dans performance ?

Post ici ou sur pastebin tes 2 fichiers

Share this post


Link to post
Share on other sites

oui j'ai supprime cacheindex

non pas de module de ce type..

Share this post


Link to post
Share on other sites

quelqu'un a t il une idee ???, merci de votre aide !!!

Share this post


Link to post
Share on other sites
1 minute ago, val said:

quelqu'un a t il une idee ???, merci de votre aide !!!

Réponds à la question posé au dessus on est pas devin.

Share this post


Link to post
Share on other sites
Posted (edited)

Non quand l'encéphalogramme est plat, plus d'idée.

PS: Je réponds tout de suite a @ttoine qui va venir me vendre ça morale du CoC en me disant que je ne dois pas faire de cynisme. Commençons pas punir, banir les usages toxiques de phrases se terminant par triple point d'interrogation et dénonçons à l'inquisition les post avec les phrases "merci de votre aide <point d'exclamation>". Nous ne sommes les esclaves de personne. Nous ne somme pas payé. Nous n'avons à obéir à personne. Encore moins: "schnell", j'attends, merci de vous manier les fesses! ! ! !

Edited by doekia
  • Haha 1

Share this post


Link to post
Share on other sites

j'ai repondu aux questions je ne comprend pas ?

Share this post


Link to post
Share on other sites

ah je post mes deux fichiers customer et validate c'est ca ?

Share this post


Link to post
Share on other sites

Ce serait un bon début, oui...

Share this post


Link to post
Share on other sites
Posted (edited)
il y a 5 minutes, val a dit :

            'lastname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32),
            'firstname' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isName', 'required' => true, 'size' => 32),

ça ne risque pas de marcher

Edited by doekia

Share this post


Link to post
Share on other sites

pourquoi ca ?

Share this post


Link to post
Share on other sites

parce que les ordinateurs sont comme ça

Share this post


Link to post
Share on other sites

oui ca j'imagine mais du coup je dois modifier quoi dans ces deux lignes ?

Share this post


Link to post
Share on other sites

ce qui est précisé au premier post du topic.

Share this post


Link to post
Share on other sites

Non mais sérieux ???

Il y a 4 heures, val a dit :

J'ai applique les modification de Doekia... pas d'erreur et ce matin encore des isncriptions pourries...

Vous avez appliqué quoi ? Où ?

Share this post


Link to post
Share on other sites

Merci mille fois @doekia pour ton aide précieuse qui rend la vie de prestashopeur vivable !

C

Share this post


Link to post
Share on other sites

j'ai transmis les mauvais fichiers.... erreur reparé, plus d'inscription intempestives !!!
merci de votre aide et heureusement que ce forum existe !!!

Share this post


Link to post
Share on other sites

Ouf... j'avais cru à un micro-coma^^

  • Haha 1

Share this post


Link to post
Share on other sites
Posted (edited)

Bonjour Val

Ce serait bien d'éditer tes 2 grand messages ci-dessus et de supprimer tes deux fichiers recopiés intégralement et qui  encombre 80 % de cette page pour rien ;)  Merci pour les autres :)

Edited by ikaris
  • Like 2

Share this post


Link to post
Share on other sites

Jusqu'à présent, je luttais après-coup contre ces inscriptions.

C'est-à-dire qu'une fois l'inscription faite, je récupérais son adresse IP, soit dans la base de données dans la table ps_customers > ip_registration_newsletter, soit dans la fiche du client si elle apparaît (elle n'apparaît pas toujours)
et je la rajoutais dans le .htacces :

RewriteEngine on

RewriteCond %{REMOTE_ADDR} ^85\.10\.56\.3 [OR]
RewriteCond %{REMOTE_ADDR} ^37\.235\.49\.244 [OR]
RewriteCond %{REMOTE_ADDR} ^151\.236\.24\.142
RewriteRule .* /1ndex.php [R=500,L]

le R=500 sert à afficher l'erreur correspondante si l'une des adresses ci-dessus tente de se connecter
 

puis dans la base de données, j'ai bricolé une commande pour les supprimer tous, proprement, complètement.
 

DELETE FROM ps_address WHERE id_customer > 80;DELETE FROM ps_cart WHERE id_customer > 80;DELETE FROM ps_cart_rule WHERE id_customer > 80;DELETE FROM ps_customer WHERE id_customer > 80;DELETE FROM ps_customer_group WHERE id_customer > 80;DELETE FROM ps_customer_thread WHERE id_customer > 80;DELETE FROM ps_guest WHERE id_customer > 80;DELETE FROM ps_message WHERE id_customer > 80;DELETE FROM ps_mr_selected WHERE id_customer > 80;DELETE FROM ps_orders WHERE id_customer > 80;DELETE FROM ps_specific_price WHERE id_customer > 80;DELETE FROM ps_wishlist WHERE id_customer > 80;ALTER TABLE ps_customer auto_increment = 81;

 Les '80' et '81' sont évidemment à remplacer par vos valeurs.

 

 

Share this post


Link to post
Share on other sites
il y a une heure, mikae a dit :

Jusqu'à présent, je luttais après-coup contre ces inscriptions.

C'est-à-dire qu'une fois l'inscription faite, je récupérais son adresse IP, soit dans la base de données dans la table ps_customers > ip_registration_newsletter, soit dans la fiche du client si elle apparaît (elle n'apparaît pas toujours)
et je la rajoutais dans le .htacces :


RewriteEngine on

RewriteCond %{REMOTE_ADDR} ^85\.10\.56\.3 [OR]
RewriteCond %{REMOTE_ADDR} ^37\.235\.49\.244 [OR]
RewriteCond %{REMOTE_ADDR} ^151\.236\.24\.142
RewriteRule .* /1ndex.php [R=500,L]

le R=500 sert à afficher l'erreur correspondante si l'une des adresses ci-dessus tente de se connecter
 

puis dans la base de données, j'ai bricolé une commande pour les supprimer tous, proprement, complètement.
 


DELETE FROM ps_address WHERE id_customer > 80;DELETE FROM ps_cart WHERE id_customer > 80;DELETE FROM ps_cart_rule WHERE id_customer > 80;DELETE FROM ps_customer WHERE id_customer > 80;DELETE FROM ps_customer_group WHERE id_customer > 80;DELETE FROM ps_customer_thread WHERE id_customer > 80;DELETE FROM ps_guest WHERE id_customer > 80;DELETE FROM ps_message WHERE id_customer > 80;DELETE FROM ps_mr_selected WHERE id_customer > 80;DELETE FROM ps_orders WHERE id_customer > 80;DELETE FROM ps_specific_price WHERE id_customer > 80;DELETE FROM ps_wishlist WHERE id_customer > 80;ALTER TABLE ps_customer auto_increment = 81;

 Les '80' et '81' sont évidemment à remplacer par vos valeurs.

Sans vouloir te vexer tu as inventé la pire solution de l'univers.

Non seulement tu vas vite te retrouver avec un .htaccess gigantesque (n'oublions pas que celui-ci est relu, re-analysé pour chaque appel - ce qui dégrade fortement les performances), mais en plus dans ton scénario si un vrai client s'inscrit, tu vas soit le perdre soit devoir faire des bouts de requêtes pénible.

 

IMPORTANT: régler un problème d'attaque par filtrage IP est TOUJOURS la plus mauvaise solution possible (surtout en .htaccess), et ce quelque soit le scénario de l'attaque

Share this post


Link to post
Share on other sites
Posted (edited)

Bonjour,

Pour les clients de Sendinblue qui utilisent le service SMTP, vérifiez qu'ils ne vous l'on pas désactivé. 

Ils m'ont dit l'avoir fait pour des clients qui ont été victimes de Spams via prestashop :

"Nous avons constaté que quelques sites Prestashop ont été attaqués par de fausses inscriptions, ce qui a généré des mauvais résultats entraînant le blocage de plusieurs comptes, ce qui est le cas du vôtre, comme vous pouvez constaté à l'aide de l'image du lien ci-dessous:"

Bonne journée

Edited by Jpc_des_dombes

Share this post


Link to post
Share on other sites

 

20 hours ago, mikae said:

C'est-à-dire qu'une fois l'inscription faite, je récupérais son adresse IP, soit dans la base de données dans la table ps_customers > ip_registration_newsletter, soit dans la fiche du client si elle apparaît (elle n'apparaît pas toujours)
et je la rajoutais dans le .htacces :


RewriteEngine on

RewriteCond %{REMOTE_ADDR} ^85\.10\.56\.3 [OR]
RewriteCond %{REMOTE_ADDR} ^37\.235\.49\.244 [OR]
RewriteCond %{REMOTE_ADDR} ^151\.236\.24\.142
RewriteRule .* /1ndex.php [R=500,L]

 

 

pour apache 2.4. vous pouvez utiliser cette règle:

<RequireAll>
Require all granted
Require not ip 85.10.56.3
Require not ip 37.235.49.244
Require not ip 151.236.24.142
</RequireAll>

Dans ce cas, l'adresse IP nommée recevra automatiquement une response http 403.

Share this post


Link to post
Share on other sites
il y a 6 minutes, selectshop.at a dit :

 

pour apache 2.4. vous pouvez utiliser cette règle:


<RequireAll>
Require all granted
Require not ip 85.10.56.3
Require not ip 37.235.49.244
Require not ip 151.236.24.142
</RequireAll>

Dans ce cas, l'adresse IP nommée recevra automatiquement une response http 403.

 

A part faire du trolling inutile sur ce topic? Quel interrêt à cela?

c'est déjà assez compliqué pour les visiteurs de suivre ce topic, si c'est pour partir dans tout les sens à leur donner des conseils boiteux, on ne va pas s'en sortir

Merci de respecter le but de ce topic.

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

Bonjour JPC

Encore une nouvelle galère potentielle :(

Merci pour ton retour. En effet, il est important que ceux qui utilisent le module sendinblue se préoccupent dare-dare d'aller voir ce qui se passe sur leur compte de mailing, car le robot continue de vous remplir vos listes de contacts chez sendinblue si vous n'avez pas fait la modif donnée par Eolia sur le module sendinblue.

Voilà 10 jours que l'attaque a commencé (ça fait potentiellement des centaines de spams dans vos listes de newsletters) et sendinblue n'a toujours pas fait de mise à jour dans leur module prestashop. Il sont bien au courant du problème mais le renvoie sur Prestashop. Voilà la réponse qu'ils m'ont fait :

Bonjour XXX

Merci pour votre retour. Pour information, Prestashop est victime d'une attaque de robots et est en train de corriger cette faille.
Cordialement.

XXX

Edited by ikaris

Share this post


Link to post
Share on other sites
il y a 6 minutes, ikaris a dit :

Bonjour JPC

Encore une nouvelle galère potentielle :(

Merci pour ton retour. En effet, il est important que ceux qui utilisent le module sendinblue se préoccupent dare-dare d'aller voir ce qui se passe sur leur compte de mailing, car le robot continue de vous remplir vos listes de contacts chez sendinblue si vous n'avez pas fait la modif donnée par Eolia sur le module sendinblue.

Voilà 10 jours que l'attaque a commencé (ça fait potentiellement des centaines de spams dans vos listes de newsletters) et sendinblue n'a toujours pas fait de mise à jour dans leur module prestashop. Il sont bien au courant du problème mais le renvoie sur Prestashop. Voilà la réponse qu'ils m'ont fait :

Bonjour XXX

Merci pour votre retour. Pour information, Prestashop est victime d'une attaque de robots et est en train de corriger cette faille.
Cordialement.

XXX

C'est en effet "amusant" et mesquin car leur module intervient même lorsque la faille est fermée. En effet le module enregistre le contenu dès le constructeur du module sans contrôle.

Share this post


Link to post
Share on other sites

Encore une petite info sur Sendinblue. Chez moi, le test d'envoi de message (SMTP) depuis le module (version v2.7.8) ne fonctionne pas. Message d'erreur SMTP non-activé.

En revanche les mails partent bien de prestashop et le test depuis  "Paramètres avancés /Emails" fonctionne

Bonne soirée

Share this post


Link to post
Share on other sites

Bonjour,

Quelqu'un peut-il m'orienter vers une solution testée pour un vieux prestashop 1.4.10.0

J'ai testé avec le module" reCaptcha v1.2.3 par Charlie" , mais ça ne suffit pas.

Merci par avance, Nicolas

Capture.JPG.175c684766e5dbd1aefacd8676730aad.JPG

Share this post


Link to post
Share on other sites

Relisez le début du post, c'est expliqué...

  • Like 1

Share this post


Link to post
Share on other sites

Prestashop 1.4.10.0 --> Grand merci à doekia.

(juste un petit pb de copier-coller du code, PS: ne pas oublier d'encoder en ANSI pour trouver les caractères fantômes...)

j'imagine qu'il faudra une extension pour gérer le spam sur prénom dès qu'ils auront compris.

Share this post


Link to post
Share on other sites

@VacarmeLe code protège nom et prénom de la même manière

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Bonjour Tout le monde, J'ai essayé de faire toutes les procédures indiquées, mais je rencontre un seul soucis.

Le champs nom et prénom sont invalides (nico / test)

J'ai utilisé les codes du 1er post, supprimer le cache_index, les comptes conflictuels ont été retiré, utilisé également le script 122, mais cette erreur reviens sans arret.

Je me demandais si c'était les 1er champs du formulaire (création du compte), ou celui de l'adresse.

Si vous avez une idée de ce que j'ai pu oublié?

Merci

Presta 1.6.1.14

Edited by lescrocs

Share this post


Link to post
Share on other sites

Le patch a justement pour but d'interdire les / dans les noms. Il est donc normal que ton nom nico / test soit rejeté.

Si j'ai mal compris ton scénario, alors PM moi ton FTP que je vienne regarder ton problème

Share this post


Link to post
Share on other sites
Posted (edited)
6 minutes ago, doekia said:

Le patch a justement pour but d'interdire les / dans les noms. Il est donc normal que ton nom nico / test soit rejeté.

Si j'ai mal compris ton scénario, alors PM moi ton FTP que je vienne regarder ton problème

enfaite Nico est le prénom et test le nom lol

Je fais vite fait le ménage chez moi (car c'est férié lol) et je vois pour les acces au ftp.

Merci

Edited by lescrocs

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, doekia said:

Le patch a justement pour but d'interdire les / dans les noms. Il est donc normal que ton nom nico / test soit rejeté.

Si j'ai mal compris ton scénario, alors PM moi ton FTP que je vienne regarder ton problème

Salut l'ami Merci encore a toi pour ce partage, doekia je joins ton patch le mettre dans le dossier Admin c'est bien ca ?

 

patch122.php

Edited by TCHOUPI

Share this post


Link to post
Share on other sites

Bonjour à tous...

j'ai un nouveau pb... j'ai applique les correctifs de validate et customer plus d'inscription de sites vaseux..

mais lorsque l'on veut modifier son identite dans son compte j'ai une erreur 500 et en mode debug ca donne ca...(voir image jointe)

une idee forcement :)

 

IMG_0852.jpg

Share this post


Link to post
Share on other sites
Posted (edited)

Tu as bien les overrides de ACTIVE

PS: merci d'éviter les capture d'écran ça n'aide pas à indexer le problème via google ou le forum

Edited by doekia

Share this post


Link to post
Share on other sites

Y a pas grand monde qui a du s'inscrire du coup^^

Share this post


Link to post
Share on other sites

non en effet pas d'inscrit...(:

du coup que dois je faire ??

Share this post


Link to post
Share on other sites

vous avez modifié les fichiers customer et validate ou utilisé les overrides ?

Car ca se trouve vous avez déjà une override sur validate ou comme le dit @doekia, les overrides ne sont pas actives.

Share this post


Link to post
Share on other sites

j'ai modifie directement les fichiers .php...

Share this post


Link to post
Share on other sites
il y a 9 minutes, Eolia a dit :

Car ca se trouve vous avez déjà une override sur validate

Vous avez controlé ce point ? Car si oui, il faut modifier l'override existante...

Share this post


Link to post
Share on other sites

je vous avoue ne pas savoir ce qu'est une override... si vous pouvez m'aiguiller...

Share this post


Link to post
Share on other sites

Ok donc vous n'avez pas lu les premiers posts...

Allez-voir dans le répertoire /overrides/classes/ et regardez ce qu'il y a dedans

Share this post


Link to post
Share on other sites

differents dossiers avec un index.php...

Share this post


Link to post
Share on other sites

et en bas de cette liste, il n'y a que index.php, rien d'autre ?

Share this post


Link to post
Share on other sites

un customer.php...

Share this post


Link to post
Share on other sites

on croirait le petit Poucet...

Et il y a quoi dedans ?

Share this post


Link to post
Share on other sites

pas faux ... :) un module sociallogin pour facebook je pense... je suppose que je dois lui ajouter qq chose :) mais quoi ???

Share this post


Link to post
Share on other sites

PM ton FTP, mais vite j'ai apéro BBQ dans 15mn

Share this post


Link to post
Share on other sites