Thousands of POST requests to /?wc-ajax=checkout

@myst3k99 (cc @riaanknoetze ) Is there a way to limit the number of processing attempts on a failed order? Does WC core store the number of attempts somewhere or is that completely up to the gateway? I would like to block processing attempts, after say, 5. This seems to be a easy way to harden WC. Allowing a free for all at processing thousands of cards on a single order is insane.

I would have liked to think this type of rate limitation for order processing would be built into WooCommerce, however I do not believe it has any. I am not an experienced WP/WC developer, so I rely on the scripts of others. There may be a way to do it. Maybe a hook into ajax order call which stores the count of order calls which were received, and then a check to see if it is over a certain value in a given timeframe. It would seem easy in theory to do.

@myst3k99 You are right, should be simple enough. I don’t think this data is stored anywhere; at least its not in the obvious places. In my interactions so far trying to find a solution, it seems like everyone is pointing to the right… WC Core, “it’s the gateway’s responsibility…” Gateway, “it’s the processor’s responsibility.” Processor, “it’s the WAF’s fault.”

We’re actually encountering this too. Blocked all know IP addresses, but it doesn’t seem like a simple attack like someone stated above. This is something else and currently using WC 4.8.0

@myst3k99 Which part of the LFD did you update? Is it the lfd Blocklist?

@kgabales & all,

I did a variety of things to stop this attack. But the thing that helped the most was installing reCaptcha v3. https://woocommerce.com/products/recaptcha-for-woocommerce/

The weak link is still that WooCommerce (and payment gateways) allow for unlimited CC processing attempts on a single order. Someone needs to develop a solution to only allow X attempts then set the order status to canceled so no more attempts can be made on that order. (Now, they can always just create a new order, but it would make it just a little more difficult.)

We are seeing this same problem, across many client sites, using a recent version of WC (so the previous posts saying to simply upgrade WC are not correct).

This type of thing is what causes clients to lose confidence in WooCommerce, and WordPress in general. Automattic needs to get on board with a proper solution.

Watching this thread for more information/updates.

– Scott

@sneader the solution for the time being is to use https://woocommerce.com/products/recaptcha-for-woocommerce/ This has successfully deterred this attack for us. However, we have had a couple customer complaints here and there that it has blocked them from processing their order incorrectly; but these are fringe cases with javascript disabled, using a 10 year old tablet on satellite internet, etc.

You are 100% right though that WC needs to up its game. (In my opinion, stop wasting time with bloat analytics and marketing hubs and fix the fundamentals to make WC viable in 2021.)

Hi @webgmclassics ! I’ve not had much luck with captcha solutions. As someone mentioned on this thread, it seems a human is adding items to the cart and checking out, then they unleash some local script to start filling out and submitting card payments to test cards.

For now, we have two pretty good solutions in place, that others might consider looking into.

1) This plugin is really good (it requires PHP 7.4):
https://github.com/BrianHenryIE/bh-wc-checkout-rate-limiter

2) We are definitely not Mod Security experts, and would welcome input to improve this Mod Sec rule, but this is definitely blocking bad guys after 10 posts to checkout, within 10 minutes (it usually only takes 10 seconds or less for them to post 10 times!)

# WordPress WooCommerce Brute Force detection
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:8000001 
<LocationMatch "/">
<If "%{QUERY_STRING} =~ /wc-ajax=checkout/">
SecRule user:wc_bf_block "@gt 0" "deny,status:401,log,id:8000002,msg:'ip address blocked for 1 day, more than 10 wc-ajax=checkout attempts in 3 minutes.'" 
SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.wc_bf_counter=+1,deprecatevar:ip.wc_bf_counter=1/180,id:8000003" 
SecRule ip:wc_bf_counter "@gt 10" "t:none,setvar:user.wc_bf_block=1,expirevar:user.wc_bf_block=86400,setvar:ip.wc_bf_counter=0" 
</If>
</Locationmatch>

In our environment, this rule was added to “modsec/modsec2.user.conf”

We will definitely look closer at recaptcha as well — maybe we did not implement it correctly, or maybe it does not work on certain cart flows.

– Scott

I have this issue happening again. 20 in a minute, all coming from different IP addresses. Multiple orders a day. Australian delivery address too.

@sneader from what I can tell your modsec rule will only pick up successive attempts from the same IP? Not for the same session/cart?

Cheers,
Jason