Developer Office Hours: January Edition

Howdy, everyone! We’re back with our monthly iteration of Office Hours. ☺️

What Are Office Hours?

Office hours are an opportunity for developers to ask questions they need answered or share challenges they need help navigating.

This is something that is already happening organically in our Slack channels, which is great! But we also want to offer dedicated blocks of time to make sure there is someone from our team who can help answer questions and facilitate the conversations around challenges.

This month’s office hours

We will hold office hours on January 18 from 14:00UTC until 15:00 UTC in the #developers channel on the WooCommerce Community Slack

This month we will be joined by Vedanshu Jain (@vedjain), member of the WooCommerce Core team and expert on High-Performance Order Storage (HPOS).

This is a great opportunity for those of you who want to know more about HPOS specifically or would like to have the opportunity to chat with a WooCommerce Core developer.

This session is for new and experienced developers, and while this month’s focus is on HPOS, we welcome all community questions and feedback.

We hope to see you there, and please comment below what subjects you’d like to focus on for future sessions. This will help us schedule  subject matter experts to answer all of your questions. 

See you soon!


2 responses to “Developer Office Hours: January Edition”

  1. I’d like to discuss the ongoing card testing and fraudulent charges attacks against Woo stores.

    https://wptavern.com/woocommerce-store-owners-combat-fraudulent-stripe-charges

    Topics like

    this problem seems to get 0 attention from core team, or am I missing info about where it’s worked on?
    core is still woefully underequipped for defenses out of the box, and no open work towards it – at minimum you need reCAPTCHA, rate limiting, etc
    core has serious design flaws from security perspectives: multiple garbage objects can get created per one attack requests, and this can easily multiple to tens of thousands garbage users, orders, subscriptions, etc overnight – massive cleanup needed, where some of it is even non-restorable (can’t really rewind sequential order numbers etc) https://github.com/woocommerce/woocommerce/issues/24603
    I see reports where even with hifi defenses up, attackers are still able to run card testing attacks – I’d like to get insight from payment gateway developers if it is still possible to send payment processor requests via direct JS API-s while skipping server-side validations, like reCAPTCHA, because that’s what it sounds like.

    1. tobinfekkes Avatar
      tobinfekkes

      Yes, the StoreAPI with the new checkout block really opened the door and lowered the barrier to fraud checkouts. Especially during the holidays, it got pretty bad.

      Rate-limiting was released as part of the Woo Gutenberg Blocks plugin.

      https://github.com/woocommerce/woocommerce-blocks/blob/trunk/src/StoreApi/docs/rate-limiting.md

      Prior to this, we had developed a few in-house tools to prevent the card-testing fraud on our sites, which worked really well. A mix of blocks to prevent certain IP addresses, or physical addresses, or email address, storing the card token now but charging it later in a background task, require user input to select an auto-completed address, etc. The fraudsters aren’t terrible clever; most of the checkout data followed patterns that we could build blocks against.

      I would check out that rate-limiting option. It takes a bit of tweaking to get the block ratio just right for your store. But that feature, plus our other blocking strategies, has reduced the card testing down to nothing.

      Remember, you don’t have to block EVERY fraud request. You just have to make it slow enough, inconsistent enough, or unreliable enough, to make it not worth their time with your site. After awhile, the rate of return for them isn’t worth the rate of success with your site.

Leave a Reply

Your email address will not be published. Required fields are marked *