You know how it is, you log into your favourite website analytics software and see the biggest website visitor spike you have ever seen!
YES! finally all those months of marketing your site have all paid off!
But, as you delve deeper into your stats you notice something strange, something no webmaster wants to see.
You think your site has been a target from a bot fishing for weaknesses on your site.
This is exactly what happened to one of my clients whereby 1000’s of bot visitors swamped the site trying to buy products using stolen credit cards.
In this post I am going to try and explain my thought process and how I stopped them from doing it again, and the best bit is I am going to give you everything you need to do the same for your own site absolutely free.
And so it starts…
After identifying that the site was getting attacked – I used the Analyse Visitors WordPress plugin to do this for me – I wanted to stop any future attempts on orders whilst I worked on a solution. You see everytime one of these orders tried to buy something it went through to the merchant (the company behind the website that handles the money side), and they were not very happy getting all these fraudulent orders. In fact they said if we didn’t do something about this they would pause the account which meant nothing gets sold.
I quickly created a button which I added to the WordPress dashboard that removes all “Add to cart” buttons from the site (here is the code for that button and where to add it). So at this point the bots couldn’t create new orders using the buttons – there are however other means they could make orders but for this attack it was enough.
I then added a message to the site that we were experiencing technical problems so that the site visitors knew something was being worked on and to come back and check later in the day (I used the WordPress plugin JG Message Manager to quickly display the message).
Although this stopped orders the server was still getting the bot traffic which was starting to slow things down. So I had to think quick and gain control of the server again.
Taking control of the site and server
Looking at the stats of the bot traffic, it was apparent that they were only using a few IP addresses, great I thought to myself, lets block those.
This stopped them in their tracks, well sort of. I knew it was only a matter of time until they start using another group of IP addresses and off they go again. So I had to think and work quick. I performed a few searches to see what other people were doing and almost everyone was using Google’s reCaptcha.
You must of seen this right? It’s the really annoying grid of boxes where you have to click on all the traffic lights or trucks in the pictures before you can continue. I hate those, I’m sure I am not alone there.
Apart from slowing down the purchase, annoying the customer the reCaptcha is actually quite bloaty. What I mean is that it takes up too much server CPU and memory to perform its task. Additional to that it is not GDPR compliant and who knows what data Google are taking from your sites most valuable page?
So reCaptcha was not the answer.
Start Recording
I knew that if I was going to beat these hackers I would need to know as much as I could about them. This included their IP addresses they use, there “false” names and email addresses, the time of the day they tried to attack the site, the country they come from, everything I could. I then started recording all this info in a database table.
Step1: Block IP addresses
Once I knew the addresses they were using I could simply block those IP addresses from using the site. Something I did try at first, I stopped visitors with these IP addresses from buying things off the site, but then later changed it to stop them altogether.
I did this as I knew what they were up to so there wasn’t any benefit to having them use any part of the site. The longer they were on the site the more data they are gathering from the site which they could use, plus they were also using valuable bandwidth.
There is a chance that a real customer was using one of the blocked IP addresses, so what I did, I sent them to a landing page which allowed them to unblock themselves by confirming their email address.
So if the IP address was blocked BUT their email address met the real customers address then I would let them order off the site. This does mean I had to let them use the site long enough to get their email address. Not perfect for the bandwidth but still stops fraudulent orders.
Additional Checks
I knew that I need more checks as just relying on blocking IP addresses won’t be enough. Here are the additional checks I added:
Rate Limiting
Rate limiting is a way of checking the amount of times a page is loaded within a certain time limit. Often if a bot or even a human might try several times to use a credit card changing the security code until they find the matching value. By adding this limit it stopped the bots from doing this (here is the code to add to your functions.php file).
Honeypot
A honeypot doesn’t have anything to do with Bees! A honeypot field is added to your form is a “fake” field which is not needed. Just under the form field “Name”, “email address” I added a hidden field called “email_check” (you can call it whatever you like). The idea is that the bot sees the field in the code of the page and adds a value, in this case an email address.
As the field is hidden from humans you now know if the field was filled in, it was from a bot, which I then block.
Disable Checkout buttons
A similar reason to rate limiting, I also implemented a delay for the “buy” buttonso that it couldn’t be used for 10 seconds. Bots tend to do things very quickly, so waiting around 10 seconds before they can proceed to the next command, can stop some of tthem. It takes more than 10 seconds for a human to fill out the form with their name, address etc so it doesn’t get noticed.
WordPress API Nonce
A nonce is a secret code that can only be used for a short amount of time, and only by the originating domain. By adding a check to ensure that this code is correct stops Cross-Site Request Forgery style attacks. Basically, helps identify if the request is coming from your website or from another one.
Everytime I discovered a fraudulent attempt I recorded all data, so in the future I can check ALL the field data not just the field that raised alarms that time.
Spread the Love
My client has many websites which could all be attacked – in fact 3 sites in all where – so it made sense to pass the fraudulent attempts data between sites so they all benefit from the checks. If you would like to know how I did this send me a message either on social media or via this website and I will share how to do it.
What I Have Learned
First off it is almost impossible to stop all hacks, all websites could get attacked. All you can do is make it as hard a possible for them to do again in the future. By implementing these checks it goes a long way to reducing fraudulent orders.
