Prévention du spam direct POST demander des enregistrements clients à Magento
J'ai commencé à avoir des problèmes avec les requêtes de spam POST sur un site Magento où un bot crée des utilisateurs de spam (ceci est même avec l'attribut action en cours de suppression, captcha, etc.) car ces robots, je crois, ne font que créer demandes directes POST vers l'URL du compte Magento standard.
Voici 3 exemples de demandes POST valides que j'ai vues dans le journal:
x.x.x.x - - [06/Nov/2017:13:54:47 -0500] "POST /customer/account/createpost/ HTTP/1.1" 302 - "https://www.example.com/customer/account/create/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36"
x.x.x.x - - [05/Nov/2017:11:34:42 -0500] "POST /customer/account/createpost/ HTTP/1.1" 302 - "https://www.example.com/customer/account/create/" "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"
x.x.x.x - - [05/Nov/2017:19:33:15 -0500] "POST /customer/account/createpost/ HTTP/1.1" 302 - "https://www.example.com/customer/account/create/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"
J'ai anonymisé les adresses IP au début, ainsi que l'URL. Cependant, notez que la 2ème URL est /customer/account/create/ alors que la première URL est /customer/account/createpost/
Voici 3 exemples de demandes de spam POST:
112.96.164.18 - - [05/Nov/2017:11:43:43 -0500] "POST /customer/account/createpost/ HTTP/1.1" 302 - "https://www.example.com/customer/account/createpost/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
112.96.164.18 - - [05/Nov/2017:12:03:17 -0500] "POST /customer/account/createpost/ HTTP/1.1" 302 - "https://www.example.com/customer/account/createpost/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
112.96.100.2 - - [05/Nov/2017:13:53:45 -0500] "POST /customer/account/createpost/ HTTP/1.1" 302 - "https://www.example.com/customer/account/createpost/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
Autant que je sache sur chaque demande de spam, les première et deuxième URL sont /customer/account/createpost/.
Quelle est la 2ème URL dans cela, par rapport à la première? Est-ce que l'un des pays où la demande a été envoyée et l'autre d'où il provient?
/customer/account/createpost/ ne devrait probablement jamais être l’origine, car c’est là que le formulaire est réellement envoyé et qu’il est visité directement, redirigez /customer/account/create/
Ma question principale est, comment puis-je bloquer de manière fiable le deuxième ensemble de demandes POST?
Enfin, nous avons trouvé un moyen d’empêcher la création de toutes les formes de comptes clients de spam dans la dernière version de Magento.
Nous avions initialement mis Googles recaptcha sur tous nos formulaires, y compris le formulaire de création de client; nous avons donc été surpris lorsque nous avons été subitement frappés par des tonnes de comptes de spam.
La première approche que nous avons essayée consistait à vérifier que l’entête du référent indiquait l’URL correcte, ce qui arrêtait 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 à/client/compte/createpost/directement sans jamais accéder directement au site. Il y avait toujours 2 demandes pour chaque client de spam, une demande GET (je suppose que cela enregistrait le contenu du champ formkey), puis une demande POST. Comme javascript n'existait pas, nous ne vérifions pas si notre recaptcha était correctement vérifié et nous envoyions quand même la demande.
Ce qui en fin de compte l'a résolu n'est pas aussi propre que l'invisible recaptcha, mais empêche les bots depuis plus d'une semaine maintenant ...
Activer le captcha par défaut de Magentos.
Système -> Configuration -> Configuration client -> CAPTCHA
Définissez Oui sur 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 important car c’est la seule chose qui arrêtera TOUTES les demandes directes POST à/customer/account/createpost/qui n’incluent pas la bonne réponse captcha. Si vous ne définissez pas toujours le mode d'affichage, les robots pourront toujours créer des clients en masse. Etant donné que personne qui n'est pas un bot ne devrait de toute façon soumettre de demandes directes sans utiliser le formulaire, cela n'empêchera aucun enregistrement légitime.
Nous avons laissé tous les formulaires en dehors de "Créer un utilisateur", car c’est la seule option de formulaire qui reçoit réellement du spam. Aucune raison de mettre un captcha sur la création d'un utilisateur lors de la vérification, car ils dépensent de l'argent.
Il est regrettable que nous n'ayons pas pu utiliser Invisible reCaptcha de Google, mais celui intégré à Magento est le seul qui soit suffisamment intégré pour empêcher toutes les demandes directes POST.
J'ai donc créé un simple fichier php 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/
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /customer/account/createpost/
on this server.<br />
</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at dev.tarunlalwani.com Port 8088</address>
</body></html>
Corriger le référant
$ 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érant n’est pas exactement http://dev.tarunlalwani.com:8088/customer/account/create/ la demande POST est refusée. Je pense que même devrait fonctionner pour vous. Rappelez-vous simplement de mettre à jour le nom de domaine et de supprimer le port. Remplacez http par 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 fournie, l’URL de renvoi de cette demande. Classiquement, 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 courrier indésirable actuelles sont si prévisibles, vous souhaiterez peut-être simplement les bloquer en fonction de leur agent d'utilisateur et/ou de leur plage d'adresses IP d'origine, car ces deux exemples semblent cohérents. 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 cela peut être utile.
Ou, bloquer sélectivement ce polluposteur de ce script spécifique, à moins qu’il ne vienne du bon endroit, en s’appuyant sur ce champ de référence (que le client fournit) est l’autre solution. Ma préférence est de jeter tous les clowns si possible, à moins qu'il y ait des raisons valables de les laisser entrer dans votre site.
J'ai trouvé ce guide https://perishablepress.com/protect-post-requests/ très utile. Bien que non concentré en particulier 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 envisager d’utiliser mod_security (ou un autre pare-feu d’application). Un ensemble de règles générales plutôt satisfaisant est disponible dans owasp-crs https://github.com/SpiderLabs/owasp-modsecurity-crs . Bien sûr, cela doit être déployé côté serveur et nécessite quelques ajustements pour que tout fonctionne correctement, mais c'est une très bonne avancée en matière de protection qui en vaut la peine.