Bot attack on: Allow customers to compare products: CPU 100%

General
1

Settings: General: Catalog:
Allow customers to compare products:

was under a bot attack; our hosting provider switched off this setting.
CPU was 100%

Anyone an idea?

(Hosting provider: It was being spammed by bots.
I therefore disabled this, plus it now results in an error message if someone technically tries to do it anyway.
I don’t know if it is a problem if this is disabled, but for now, this is the solution.)

2

Hello

In .htaccess, after “RewriteRule ^init.php$ - [F,L,NC]” and before the final “RewriteRule . index.php [L,QSA]”:

RewriteCond %{HTTP_COOKIE} !sid_ [NC]
RewriteCond %{QUERY_STRING} (^|&)dispatch(=|[|%5B)product_features. [NC]
RewriteRule ^ - [R=410,L]

RewriteCond %{HTTP_COOKIE} !sid_ [NC]
RewriteCond %{REQUEST_URI} ^/compare/?$ [NC]
RewriteRule ^ - [R=410,L]

Real visitors always carry a sid_ cookie by the time they reach the compare button (session starts on init), bots without cookies get 410 and drop the URL.

Not tested

Best regards
Robert

3

Looks like I am getting the same attack.

This looks like automated abuse or a crawler loop hitting a legitimate comparison-list endpoint, triggering database connection aborts.

I took multiple snapshops of global connection aboards and found spikes. Looking at logs it looks like attachking product_features.add_product which is the normal storefront action used when customers add products to the comparison list. .

Traffic was clearly abnormal:

  • 1,576 requests in one minute
  • concentrated on one action and product
  • 1,125 failures
  • database connections exhausted at 30

Across 31 July, the endpoint received 106,615 requests from 103,214 IPs. Eight nearly identical browser user agents generated 99.2% of them, while 98.4% claimed the homepage as referrer. This is coordinated distributed automation, not a legitimate crawler.

Traffic escalated over several days: approximately 8,000 requests on 28 July, 11,700 on 29 July, 51,300 on 30 July, and 106,600 on 31 July.

Each new bot request can create/write a database-backed session and load product, feature, price, option, image, discount, hook, and template data.

I build a addon it

  • Caps comparison lists
  • Treats duplicate additions and absent removals as idempotent no-ops.
  • Limits comparison mutations
  • Caps excluded feature IDs
4

This could work but could be bypassed:

  • !sid_ is can be bypassed by sending any fake cookie containing sid_; the incident’s rotating clients could adapt immediately.
  • A genuine visitor is not guaranteed to have that cookie—for example, a first visit served from cache, blocked cookies, or a direct /compare/ visit.
  • (^|&)dispatch(=|[|%5B)… contains an unclosed regex character class, while the dot in product_features. is unescaped. That could make the rewrite invalid or match unintended dispatches.
  • Blocking /compare/ is unnecessary. It is the comparison display page, not the expensive state-changing action, and a 410 could remove a legitimate page from search results.

I have added the vonrability as a bug and requested a POST fix. Turning off catalog is a solid protection, if lef on a corrected cookie-gated rule could reduce this exact no-cookie attack, but it cannot guarantee protection.

Origin fallback: legacy comparison mutations must never use GET.

RewriteCond %{REQUEST_METHOD} !^POST$ [NC]
RewriteCond %{QUERY_STRING} (^|&)dispatch=product_features.(add_product|delete_product|clear_list|delete_feature)(&|$) [NC]
RewriteRule ^ - [G,L]

[G,L] is the explicit Apache form for HTTP 410. LiteSpeed documents support for Apache-style .htaccess rewrite rules, but the production server must still receive a syntax check and a few harmless curl requests before this is enabled.

A Cloudflare (if used) rule is preferable as the outer shield; .htaccess protects the origin if Cloudflare is unavailable or bypassed.

5

on further investigation, turning off the setting pending a fix isn’t a complete solution because the setting is used mainly by templates to hide buttons and links. A direct request to product_features.add_product still reaches the frontend controller even after comparison is switched off. UniTheme (and I assume other themes, but this is what I use) also has several compound display conditions involving product.feature_comparison, so hiding every button should be verified rather than assumed.

6

Maybe you can fix the problem at the source. I got a warning from my host saying my bandwidth was exceeding my allowance. Checking my logs, 80% of the bandwidth was from agent AmazonProductDiscovery. Created a free cloudfare account and used WAF to create a custom WAF rule to block it so it never hits my site. It’s also possible to tell Amazon to stop scanning the site and/or use robots.txt to stop them.