10

An e-commerce site should reserve products for a user while they're going through the payment process (more info). This creates a potential denial-of-service risk where an attacker could reserve many products and never complete payment - reserving all the stock and preventing legitimate sales.

How can this be defended against?

One option I considered is doing as much verification as possible on the user before allowing reservations. But there's not much verification you can do - the whole idea is that anyone can buy from your store. You could potentially require a verified email, but that's inconvenient for users, and it's still quite easy for an attacker to verify a large batch of emails.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • 2
    I think it's more of a business logistics issue. You have an expected rate of abandoned carts, and you have an ability for JIT manufacturing. You don't typically warehouse everything; you have an optimisation curve. – schroeder Jul 09 '20 at 12:48
  • @schroeder - Sure, if you can JIT, this isn't an issue. Question was more around products you can't JIT, e.g. things manufactured offshore in batches. In the latter case, the business decision is clear: don't let people DoS. My question is how can IT implement this? – paj28 Jul 09 '20 at 12:57
  • 1
    Fair enough. Actually, I know someone who launched a tech start-up just for this ... Let me get her attention on your question. – schroeder Jul 09 '20 at 13:02
  • Right. It falls into the "wicked problem" domain. Abandoned cart management processes are the key to try to verify legitimate orders. – schroeder Jul 09 '20 at 13:30
  • I'm pretty sure sometimes I bought the last item available, and adding it to the cart would not decrease the counter. In other words, I suspect most e-commerce websites only decrease the stock after you have paid. This makes it impossible to DoS like you said, because the attacker would need to pay. But what happens if somebody else had the last item in their cart? I guess at checkout, it would suddenly turn out to be unavailable. Bad surprise for the user! But how likely is it? Only likely if you have few items and lots of requests. But you could monitor that (alert on low stock), etc. – reed Jul 09 '20 at 18:01
  • @reed - Over on [software engineering](https://softwareengineering.stackexchange.com/questions/412515/should-an-e-commerce-application-reserve-products-before-attempting-payment) they're adamant this is a necessary feature. But I'm not so sure myself. – paj28 Jul 09 '20 at 18:27
  • Actually, the problem is more complex than I thought. What if the user pays by bank transfer? That takes time to complete (hours or even days). So IMO, the appropriate solution depends on several factors: available stock, purchase rate, payment methods, etc. But I'm afraid this won't help against DoS attacks anyway, in theory. To avoid DoS attacks, you will probably need to monitor all those factors, monitor user behavior, to be able to detect malicious behavior and try to stop it as soon as possible. – reed Jul 09 '20 at 20:57
  • @reed - Yeah, that's a big problem! I guess it's a business choice whether to hold reservations that long. This little feature is such a can of worms, I can see why people don't bother. – paj28 Jul 09 '20 at 22:42
  • 2
    @reed Amazon will notify the user even as late as the payment screen if something in their cart goes out of stock. But once you get to the payment screen and START a payment, then the products are "reserved" for ~2 hours or so even if the payment fails. The keyword being start here, since valid payments methods are harder to forge in bulk than user accounts or phone numbers. – Kartik Soneji Jul 10 '20 at 00:49

4 Answers4

21

I've seen 2 main solutions:

Your products are being reserved for X minutes

I've seen notices like this occasionally, but only on places where inventory really matters (usually ticketing sites).

I've also built a number of eCommerce sites for small businesses, and their preferred solution is always the same:

Just ignore it

It's often just not a critical factor, even if you don't have JIT manufacturing capabilities. Sometimes you can just have it drop shipped from the manufacturer. Most of the time the turn over on your inventory is low enough that it just doesn't matter. Sometimes you have to reach out to the customer after they place the order and let them know about the delay.

In short, this is more of a business problem, and not all businesses care.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • Thank for the pragmatic response. Other [answers](https://softwareengineering.stackexchange.com/a/412516/108835) claimed this was essential, but I figured it's rare in practice because it's difficult to implement well. – paj28 Jul 09 '20 at 15:17
  • @paj28 I also worked primarily with smaller businesses, most of which didn't have the technical capabilities (in terms of live-and-accurate inventory tracking) to implement this. Although to be fair it's not just small businesses that have this issue. I've often called larger retail establishments (think Lowes, Home Depot, Best Buy) because I want to check availability of the item and have been told, "The system says we have a couple in stock but sometimes that means we're out, so let me check". You can't tightly control ordering if you don't know how much you have in stock. – Conor Mancone Jul 09 '20 at 17:39
  • @ConorMancone Amazon does this by default. If your payment fails or is interrupted midway, then you can retry the payment and the products are still "reserved" for you. I think the important bit is having a valid payment method before reserving, since they are harder to forge in bulk then user accounts or phone numbers. Then you can easily implement rate-limiting by checking how many products are reserved by each payment method instead of per user account. – Kartik Soneji Jul 10 '20 at 00:53
  • 1
    "Essential" is a strong word, but it really depends on the business. For in-demand ticketing sites with reserved seats, I'd say it's essential because it would be really hard to complete transactions without some kind of reservation (click seat A105, enter payment details, oops—A105 is now sold out, back up, click seat G102, enter payment details, oops—G102 is now sold out, and so on). For normal consumer goods with steady demand patterns, dealing with it may just not be a business priority. – Zach Lipton Jul 10 '20 at 02:59
6

Abandoned cart management processes are the key to try to verify legitimate orders. Use your expected order patterns even in periods of order spikes. Get engagement from users by nagging them about their abandoned cart. If they don't engage with the email or log back in, even after enticement, you can write-off the order.

Not exactly a security-based solution, but it's what's done in practice.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • Did you have any particular abandoned cart processes in mind? Sure, we can nag the user and release the reservation after a timeout, or failure to engage. But that doesn't fully prevent the DoS risk. I have a feeling most sites do little about this in practice. – paj28 Jul 09 '20 at 13:37
  • Your feeling is correct, and that's why my friend started her company. It still didn't do very well because most vendors don't have a need for this level of optimisation. They are either handling it using logistics or delays. It's also not a huge problem. If you are ordering in batches, then you factor that into your schedule. And you tend not to reserve orders until verified payment. If you want fast turnaround times in manufacturing, then you're in JIT territory. – schroeder Jul 09 '20 at 13:55
  • Abandoned cart: nag within 12 hours, offer small discount, highlight oft-also-ordered products, mention the time sensitivity of ordering else experiencing a fulfilment delay. If email is unopened within 12 hours: dump the reservation. If email is opened; start a sales funnel process, but dump after 48 hours regardless. – schroeder Jul 09 '20 at 13:58
  • There's a reason why Amazon has an "order now to get with X days" on the sales page, but not the cart. If you come back to your cart after their timeout, yo'll get it when you get it :) – schroeder Jul 09 '20 at 14:01
  • Reserving after payment introduces a small risk of a negative user experience ([explained here](https://softwareengineering.stackexchange.com/questions/412515/should-an-e-commerce-application-reserve-products-before-attempting-payment)) I'd be really interested to see a link to your friend's company. – paj28 Jul 09 '20 at 14:12
  • Right, but you reserve all of the expected items in the carts to combat that. How much and for how long is what you want to optimise. – schroeder Jul 09 '20 at 14:15
  • Exactly. I was responding to your earlier comment "you tend not to reserve orders until verified payment". Interesting observation about Amazon. This comment thread is skirting the core issue: how do we allow such reservations, and avoid DoS attacks? – paj28 Jul 09 '20 at 14:20
  • "post-reservation challenge" disguised as sales. It "verifies" the email, and measures human engagement. – schroeder Jul 09 '20 at 14:22
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/110404/discussion-between-paj28-and-schroeder). – paj28 Jul 09 '20 at 14:23
4

Reservation is a privilege

If we can, we reserve products during checkout:

  • Returning users - who have previously made and paid for an order. Their account is more trusted and can reserve products any time.

  • New users:

    • At normal times, they can reserve products during checkout.
    • If the there's ongoing DoS attempts, new users are not allowed to reserve products. A warning could be included on the order page, but I'm not going to as it will probably just cause confusion.

To implement this, there needs to be a "defcon" level, presumably based on things like number of abandoned checkouts in the past hour.

Schroeder suggested behavioural analysis could be used to determine if the user is human. This would be pretty neat, but I'm not going to code behavioural analysis myself. If there's an open-source solution maybe I'd use that.

Edit - Square's API helps

I've realised that Square's API helps a lot with this. With their API, client-side code generates a single-use payment token. This is submitted, then server-side code charges the token.

When the token is submitted, the app can check stock levels. It's not too bad an experience for the user if they enter their details, but the order fails before the card is charged. The app doesn't need to reserve stock while the user enters card details. And I expect a DoS is less likely as you can't easily obtain Square tokens in bulk (although I haven't tested that!)

This arrangement is somewhat like two-phase commit.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • 1
    If this is about things like quickly sold-out concert tickets, it may be the case that new customers never make it to a successful order because they didn't manage to do so last time ... – Hagen von Eitzen Jul 10 '20 at 06:08
  • @HagenvonEitzen - Yep, that's definitely a problem. There's a number of tradeoffs to be made here and I'd say this arrangement is the least bad overall. But if you can suggest a way to avoid the new customer problem without re-introducing one of the other problems, I'd love to hear it! – paj28 Jul 10 '20 at 13:29
1

I understand that the "I am not a robot" tick box, is running analysis on mouse movement. And in fact the technology underneath doesn't require you to actually tick a box; it's just looking for some mouse mouse movement data to input into a machine learning algorithm. The algorithm then decides if you're human or not.

Perhaps this process could be applied to the "Add to Cart" button, (instead of a "I'm not a Robot" checkbox).

Establishing that a user is a real user before reserving stock, would make your DoS attack much more difficult (perhaps prohibitively difficult).

This is the process used by Google's reCapture 3, so it should be very easy to implement. (thanks to @paj28 in the comments)

schroeder
  • 123,438
  • 55
  • 284
  • 319
Aidan Ewen
  • 111
  • 4
  • It's called a CAPTCHA. You're suggesting to add Google's reCAPTCHA code to the order page. – schroeder Jul 10 '20 at 07:43
  • @schroeder, I read this as suggesting to run mouse movement analysis on the order page to tell real customers from robots. Less visible to the user, more complicated for the programmer. – o.m. Jul 10 '20 at 11:47
  • @o.m. - That's essentially what reCAPTCHA 3 does – paj28 Jul 10 '20 at 13:28
  • @paj28, ah, I was thinking of reCAPTCHA 2. – o.m. Jul 10 '20 at 13:39