September 10, 2021 at 4:28 am #4302
It appears some hackers used my Accept Stripe Payments installation to repeatedly run multiple (hundreds) credit card transactions. It’s a form of attack where the attackers attempt many small transactions using different credit cards in an attempt to identify cards that are valid. (Most transactions failed but some succeeded). I was still left with dozens of transactions that I had to refund, not to mention risking getting the stripe account into bad standing.
I wonder if anyone has encountered this issue and whether there are any changes that the plugin authors can implement to prevent these kinds of attacks.
Also, do you have any suggestions for what I can implement to prevent these kinds of attacks or at least slow them down.
Here are some behaviors of the Stripe Payments plugin that the attackers were able to exploit:
1. Being able to override the product amount.
The product “purchased” by the attackers was £11.99.
However the attackers were able to change the amount to various amounts ranging between £2 and £5
The plugin should not allow an amount that is different from the product price.
2. Being able to run multiple transaction per minute.
Some kind of Captcha implementation, perhaps integration with Google Recaptcha can mitigate this.
3. No way to quickly disable or hide the product.
Once we discovered an attack was under way, there was no easy and quick way to disable or hide the product under attack.
We made the product private but this did not make the product purchase url private.
Our only options were either:
Delete the product
Disable the plugin entirely.
We also added an .htaccess password on the “/asp-payment-box/” URL, but this may not have been sufficient by itself.
4. Oddly, no orders were created for the few transactions that were successful.
ThanksSeptember 10, 2021 at 11:09 am #4303
You need to enable the following captcha feature asap. That will stop those spam bots:
It’s actually a recommended setup when you setup the plugin at first. However, some uses dismiss that message. So please enable that feature and let us know how it goes after that.September 10, 2021 at 8:02 pm #4304
Doh! I completely missed that setting. Thanks for pointing it out – have enabled it now.
I have also enabled Zip code validation as an extra check.
Do you have any insight into how they managed to change the product price for the transaction. Is there anything I can do to prevent it or is this something that needs a change to the plugin?
(FYI “Security Token Check” is enabled – i.e. “disable” checkbox is unchecked)September 10, 2021 at 8:03 pm #4305
Also, do you have any comments on points 3 & 4?September 11, 2021 at 12:26 am #4306
There are various different things the spammers try so I won’t be able to tell you exactly what happened in your scenario without looking at all the income server request data. The captcha will stop all of those anyway and solve the issue.
There is an additional price verification that is done by our plugin after a successful API response. The post payment processing script will look at the webhook data sent by Stripe and match the price value with the data saved in the database for that product. If that validation fails, it won’t add to the orders menu (since it is not a valid transaction).
There is a lot more technical stuff that happens underneath, if you are interested, use the contact form to email us and I will give you more info.September 12, 2021 at 9:34 pm #4307
> There is an additional price verification that is done by our plugin after a successful API response.
That may explain why I did not see any orders even for the successful transactions.
Would it make sense to do a price verification prior to making a Stripe API call?
Kind RegardsSeptember 12, 2021 at 11:33 pm #4309
We already do that. The issue is that the spammers have the ability to post the data directly to Stripe’s site (without touching your site). So you always have to do a price verification after the transaction also (for maximum protection).September 13, 2021 at 10:25 pm #4313
Hmm… ok so makes sense to do the price check both times.
In this case the spammers apparently went through my site since the attack stopped as soon as I deactivated the plugin. And despite that they were able to post a different price. So is it possible that they bypassed the pre-api-call price check on my site?September 13, 2021 at 11:55 pm #4319
Yep, that’s what it looks like from your explanation.September 16, 2021 at 2:19 am #4325
Ok, would you consider this a defect that you would look to fix if the hackers managed to bypass the pre-api-call price check?
On a related note, the Stripe developers asked me to add friction to the transaction flow which I have done by enabling Google reCAPTCHA setting. However, the Stripe developers want to know whether the reCAPTCHA “was also implemented on the server side as well as the client side”.
Can you tell me if reCAPTCHA is implemented on the server side as well or is it just on the frontend?
Thanks & RegardsSeptember 19, 2021 at 10:41 pm #4327
Hi Can you please answer my last post. Stripe is asking me this question i.e.
the Stripe developers asked me to add friction to the transaction flow which I have done by enabling Google reCAPTCHA setting. However, the Stripe developers want to know whether the reCAPTCHA “was also implemented on the server side as well as the client side”.
Can you tell me if reCAPTCHA is implemented on the server side as well or is it just on the frontend?September 20, 2021 at 11:42 pm #4328
reCAPTCHA is implemented on the server side so it can’t be tampered with.
The other issue is that there are some people out there who offers a service to solve captcha manually (a human sitting there solving the captcha). That’s not something we can handle on our end since that responsibility falls on the captcha library.
You must be logged in to reply to this topic.