lkraav

Core development team tries hard to ignore the problem.

https://github.com/woocommerce/woocommerce/issues/28711 is a good example to look at.

You might also want to keep tabs on https://github.com/woocommerce/woocommerce/issues/24603 another attack vector wide open for anyone without a captcha, ignored by core development team.

• This reply was modified 1 year, 6 months ago by lkraav.

AFAICT core developers have done nothing to protect from this attack over past months. It needs more drive and demand.

#security channel did get started on WooCommerce Slack.

Your primary defense still is to have a captcha on checkout screen, do not accept orders without passing it.

• This reply was modified 1 year, 6 months ago by lkraav.

OK unfortunately lack of ability to build Post SMTP with recent WP core versions compatibility is a “drop this plugin” signal.

I can also confirm Merchant IDs not working with v3, so I guess downgrade is still the only option?

Hi Jason. Welcome to “WC core security gaps victim support group”.

You should first join #security channel on WooCommerce Slack, here’s an invite link https://join.slack.com/t/woocommercecommunity/shared_invite/zt-1uetvimgj-MsoAFa5HbsyFxjcG2Dnjtg

I drove creation of this channel after my WC site went through the same attack you’re experiencing.

WC core currently ships zero protection for this abuse in core. There’s no security team that I know of, even, so it’s not surprising. This attack is gateway-agnostic, my experience with Stripe plugin is described at https://github.com/woocommerce/woocommerce-gateway-stripe/issues/918#issuecomment-1335918154

We need to join efforts to get this situation improved.

• This reply was modified 1 year, 10 months ago by lkraav.

Yeah we forked this plugin and implemented several extra security measures for our use. While the idea was good, its codebase on GitHub wasn’t good enough to run this vanilla, so this security event isn’t surprising.

Page Rules: see if applying “Bypass Cache” rule for wp-login.php helps this in any way?

> I wish I had a good answer for you. I don’t. The WordPress team has a new Performance group. I’ll file a bug with them, because this is just ridiculous.

I think this should go directly into Core issue tracker.

https://core.trac.www.ads-software.com/search?q=wp_usermeta.meta_key is able to pin-point some existing open performance issues:

https://core.trac.www.ads-software.com/ticket/28160 seems like a good match here.

https://core.trac.www.ads-software.com/ticket/23373 should get a downvote for proposing a clearly suboptimal wildcard search.

> Thanks. I’m unclear about whether modifying indexes does or does not lock up a production database?

Answer: it does not.

10M postmeta index did take 5 minutes to add.

I’m most confused on, why isn’t this in WooCommerce core yet.

I’m going to open that discussion with WC team.

> It’s good to know this worked scaled up to 7+ megarows in wp_postmeta.

We have 10M rows in wp_postmeta, and after getting the wp_postmeta performance index built y-day (had to reconfigure tmpdir off /tmp, which at 2.6G free still ran out of space),

query speed increase was absolutely mind-blowing.

We had 20-30-40s queries go down to 1s and less (WC orders, subscriptions etc)

> It looks like the plugin deleted the FULLTEXT indexes of the plugin which is strange as it shouldn’t be doing that.

I was also about to open a support ticket here, because indexes set by other plugins are getting killed: in our case, also related posts plugins, but ours are YARPP and RP4WP by Never5.

Perhaps Ollie can enlighten us whether it’s possible to leave unknown indexes untouched?

It’s probably impossible to build a library to maintain an index ecosystem, so probably the best thing would be to leave unknown things alone.

> I suggest you use the wp-cli command wp index-mysql enable wp_postmeta to do that, to avoid timeouts.

Thanks. I’m unclear about whether modifying indexes does or does not lock up a production database?

I just recently did run an ADD INDEX operation, and site seemed to have kept running for the 180 seconds time it took.

It seems my wp_postmeta has ~5M rows, should be indexed in a few minutes I think.

[~/www]# wp index-mysql tables
Index WP MySQL For Speed 1.3.3
Versions MySQL:10.3.27-MariaDB-log WordPress:5.8.2 php:7.4.18
Notice: Undefined index: format in /home/www/public_html/wp-content/plugins/index-wp-mysql-for-speed/code/cli.php on line 326
+----------+--------+---------+-------------+--------------+----------------+--------+------------+--------------------+
| table    | prefix | count   | distinct_id | distinct_key | autoload_count | engine | row_format | collation          |
+----------+--------+---------+-------------+--------------+----------------+--------+------------+--------------------+
| comments | wp_    | 856252  | 65865       |              |                | InnoDB | Dynamic    | utf8mb4_unicode_ci |
| options  | wp_    | 3706    |             |              | 2450           | InnoDB | Compact    | utf8mb4_unicode_ci |
| postmeta | wp_    | 4942770 |             | 17343        |                | InnoDB | Dynamic    | utf8mb4_unicode_ci |
| posts    | wp_    | 4250664 |             |              |                | InnoDB | Dynamic    | utf8mb4_unicode_ci |
| termmeta | wp_    | 1978    |             | 22           |                | InnoDB | Dynamic    | utf8mb4_unicode_ci |
| usermeta | wp_    | 1944811 | 54022       | 22354        |                | InnoDB | Dynamic    | utf8mb4_unicode_ci |
| users    | wp_    | 25171   |             |              |                | InnoDB | Dynamic    | utf8mb4_unicode_ci |
+----------+--------+---------+-------------+--------------+----------------+--------+------------+--------------------+

EDIT seems to be doable online https://stackoverflow.com/questions/64794302/create-index-in-huge-mariadb-production-database-without-table-locking

• This reply was modified 3 years, 3 months ago by lkraav.

Probably https://core.trac.www.ads-software.com/ticket/52920

Any updates here @jozsefprofithu?

I’m not sure whether it’s safe to install this on a live Stripe e-commerce site.