Preventing spam direct POST request customer registrations in Magento

Question

I've begun to have some issues with spam POST requests on a Magento site where a bot is making spam users (this is even with the action attribute being removed, captcha, etc) as these bots I believe are just making direct POST requests to the standard Magento account url.

Here's 3 examples of valid POST requests I've seen in the log:

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"

I've anonymized the IP addresses at the beginning, as well as the url. However, notice that the 2nd url is /customer/account/create/ while the first url is /customer/account/createpost/

Here's 3 examples of spam POST requests:

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"

As far as I can tell on every single spam request, both the first and second url are /customer/account/createpost/

What is the 2nd url in this, compared to the first? Is one where the request was sent and the other where it came from?

/customer/account/createpost/ should probably never be the origin, since that's where the form is actually sent, and visiting it directly redirect /customer/account/create/

My main question is, how do I reliably block the second set of POST requests?

Answer 1

Finally found a way to prevent all forms of spam customer accounts from being created in the latest version of Magento.

We initially had put Googles recaptcha on all of our forms including the customer create form so we were surprised when we were suddenly being hit with tons of spam accounts.

The first approach we tried was verifying that the referrer header showed the correct URL, which stopped the bots for a few days until they started spoofing the referrer.

Turns out these bots were just sending requests to /customer/account/createpost/ directly without ever accessing the site directly. There were always 2 requests for each spam customer, a GET request (I'm assuming it was recording what the formkey field was) and then a POST request. As no javascript was running it was just bypassing our check for if the recaptcha was correctly verified and sending the request anyways.

What actually ended up solving it isn't nearly as clean as the invisible recaptcha, but has prevented bots for over a week now...

Enable Magentos default captcha.

System -> Configuration -> Customer Configuration -> CAPTCHA

Set it to Yes for Enabled, and select just the Create User form, then you have to set the Displaying Mode to Always. This last part is very important because this is the only thing that will stop ALL direct POST requests to /customer/account/createpost/ that don't include the correct captcha response. If you don't set displaying mode to always, then the bots will still be able to just mass make customers. As nobody that is not a bot should be submitting direct requests without using the form anyways, this won't prevent any legitimate registrations.

We left it off all the forms besides "Create user" since that's the only form option that really gets spam. No reason to put a captcha on creating a user while checking out since they're spending money.

It's sad that we couldn't use Google's Invisible reCaptcha, but the built in Magento one is the only one integrated enough to prevent all direct POST requests.

Answer 2

So I created a simple php file with a echo statement. Then added a .htaccess with below content

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]

Now some tests

Wrong Referer

$ 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>

Correct Referer

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

As you can anytime the referer is not exactly http://dev.tarunlalwani.com:8088/customer/account/create/ the POST request is denied. I think same should work for you. Just remember to update the domain name and remove the port. Change http to https if needed

Answer 3

Your first question, yes the two URLs in the logs are the URL being requested, and, if the browser provided it, the referring URL for that request. Conventionally they're in that order; the other information are things like HTTP return code, the User-Agent string, etc..

If your current spam requests are so predictable, then you might want to just block them on the basis of their user agent and/or originating IP range, as both of those look consistent in your examples. For example using user-agent:

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

Obviously that won't be foolproof but can be useful.

Or, selectively blocking that spammer from that specific script, unless they come from the right place, by relying on that referrer field (which the client provides) is the other route & the other solution. My preference is to throw out clowns altogether if possible, unless there are valid reasons for letting them into your site at all.