Enfin, nous avons trouvé un moyen d’empêcher la création de toutes les formes de comptes clients spam dans la dernière version de Magento.

Nous avions initialement mis GoGles Recaptcha sur tous nos formulaires, y compris le formulaire de création de client. Nous avons donc été surpris lorsque nous avons été frappés par des tonnes de comptes de spam.

La première approche que nous avons essayée était de vérifier que l’en-tête du référent indiquait l’URL correcte, ce qui a arrêté les robots pendant quelques jours jusqu’à ce qu’ils commencent à usurper le référent.

Il s’avère que ces robots envoyaient simplement des demandes à / customer / account / createpost / directement sans jamais accéder directement au site. Il y avait toujours 2 demandes pour chaque client de spam, une requête GET (je suppose qu’il enregistrait le champ de la clé de protection) et une requête POST. Comme aucun javascript ne fonctionnait, il était simplement en train de contourner notre vérification si le recaptcha était correctement vérifié et envoyait la demande de toute façon.

Ce qui a fini par le résoudre n’est pas aussi net que le recaptcha invisible, mais a empêché les bots depuis plus d’une semaine maintenant …

Activer le captcha par défaut de Magentos.

Système -> Configuration -> Configuration client -> CAPTCHA

Réglez-le sur Oui pour Activé et sélectionnez uniquement le formulaire Créer un utilisateur, puis définissez le mode d’affichage sur Toujours. Cette dernière partie est très importante car c’est la seule chose qui arrête TOUTES les requêtes POST directes vers / customer / account / createpost / qui n’incluent pas la réponse correcte du captcha. Si vous ne définissez pas le mode d’affichage sur toujours, les robots pourront toujours créer des clients en masse. Comme personne n’est pas un bot, il est préférable que des demandes directes soient envoyées sans utiliser le formulaire, cela n’empêchera aucune inscription légitime.

Nous avons laissé tous les formulaires à côté de “Créer un utilisateur”, car c’est la seule option de formulaire qui reçoit vraiment le spam. Il n’y a aucune raison de mettre un captcha sur la création d’un utilisateur tout en vérifiant qu’il dépense de l’argent.

Il est regrettable que nous ne puissions pas utiliser le reCaptcha invisible de Google, mais celui intégré dans Magento est le seul suffisamment intégré pour empêcher toutes les requêtes POST directes.

J’ai donc créé un fichier php simple avec une déclaration echo. Puis ajouté un .htaccess avec le contenu ci-dessous

 RewriteEngine On RewriteBase / RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} ^/customer/account/createpost/$ RewriteCond %{HTTP_REFERER} !^http://dev\.tarunlalwani\.com:8088/customer/account/create/$ RewriteRule ^.* - [F,L] 

Maintenant quelques tests

Mauvais référant

 $ curl -X POST -H "Referer: http://dev.tarunlalwani.com:8088/customer/account/creates/" dev.tarunlalwani.com:8088/customer/account/createpost/     
Forbidden
 
You don't have permission to access /customer/account/createpost/ on this server.
 
 
 
Apache/2.4.18 (Ubuntu) Server at dev.tarunlalwani.com Port 8088
  

Référer correctement

 $ curl -X POST -H "Referer: http://dev.tarunlalwani.com:8088/customer/account/create/" dev.tarunlalwani.com:8088/customer/account/createpost/ Tarun here 

Comme vous pouvez le faire à tout moment, le référent n’est pas exactement http://dev.tarunlalwani.com:8088/customer/account/create/ la demande POST est refusée. Je pense que même devrait travailler pour vous. N’oubliez pas de mettre à jour le nom de domaine et de supprimer le port. Changer http en https si nécessaire

Votre première question, oui, les deux URL dans les journaux sont l’URL demandée et, si le navigateur l’a fourni, l’URL de référence pour cette demande. Conventionnellement, ils sont dans cet ordre; les autres informations sont des choses comme le code de retour HTTP, la chaîne User-Agent, etc.

Si vos demandes de spam actuelles sont si prévisibles, vous pouvez simplement les bloquer en fonction de leur agent utilisateur et / ou de leur plage IP d’origine, car ces deux éléments semblent cohérents dans vos exemples. Par exemple, en utilisant user-agent:

 # in .htaccess RewriteCond %{USER_AGENT} ^Mozilla/5.0.+WOW64.+Gecko/20100101$ RewriteRule ^.* - [G,L] 

Évidemment, cela ne sera pas infaillible mais peut être utile.

Ou, en bloquant sélectivement ce spammeur à partir de ce script spécifique, à moins qu’ils ne viennent du bon endroit, en s’appuyant sur ce champ référent (fourni par le client ) est l’autre voie et l’autre solution. Ma préférence est de jeter des clowns si possible, à moins qu’il y ait des raisons valables de les laisser sur votre site.

J’ai trouvé ce guide https://perishablepress.com/protect-post-requests/ très utile. Bien que n’étant pas particulièrement centré sur Magento, il montre plusieurs méthodes de défense raisonnables. Malheureusement, mod_rewrite est limité à des règles relativement simples.

Si les problèmes persistent, vous pouvez utiliser mod_security (ou un autre pare-feu applicatif), mais il existe un bon ensemble de règles générales disponible dans https://github.com/SpiderLabs/owasp-modsecurity-crs . Bien sûr, cela doit être déployé côté serveur et nécessite quelques ajustements pour qu’il fonctionne correctement, mais c’est une très bonne protection et cela en vaut la peine.