"In contrast, the developer of OpenCart responded to
the inventory vulnerability by posting a comment—“use your brain!
its [sic] not hard to come up with a solution that does not involve
coding!”—then closed both the inventory and voucher vulnerability
issues and blocked us from responding. "
I don't know opencart, but I know how it is handled in companies using other onlineshops:
When the stock of an item goes negative, it is noticed by staff when they want to fulfill the order. ("Strange, this customer ordered red socks, but we don't have any").
Staff sets the item as "Cannot be delivered" in the order. Which ups the stock to zero again.
Customer order gets fulfilled with a note "Sorry, the red socks could not be delivered.".
It's not perfect, but also not a big drama.
Same with coupons. You should have them being invalidated after the order process. And if you see the same coupon code used twice, you know it is fraud.
It's funny, but the dev's response has since "disappeared". Still some ignorance in the thread (thinking that multiple layers of SHA1 was safe) but hopefully history has vindicated my position at that time.
Never use OpenCart for anything. There's no point, when you'll be insulted and unsupported. And don't work with the owner/contributor: https://github.com/danielkerr
The dev is indeed really incompetent for behaving like that.
Also, his response here is amazing: https://web.archive.org/web/20160120051637/https://github.co...
Think about it: Depending on the shop software, two orders need to be placed within a few milliseconds. Containing the same item. And the item has to be very low on stock so the two orders cannot be fulfilled. That is a very very rare event. It's almost a theoretical event only.
I have seen a bunch of companies grow an online business. There were tons of pain points. This race condition was none of them.
The serializable isolation level does not guarantee reporting this correctly, and a concurrent process reading account balances could see a situation where account holder X is out-of-bounds of their regulatory constraints, despite the account holder themselves taking great pains to act lawfully.
For applications like this, strict-serializability is required. You can read more about isolation levels and anomalies in the article from comp sci Professor Daniel Abadi: https://fauna.com/blog/introduction-to-transaction-isolation...
Even banking works like this because settlements are done asynchronously. Some years ago there were several instances of an attack where someone got a hold of a rich middle easterner's debit card number and PIN, found a way to set the withdrawal limit up, then had crews of people hitting every ATM in Manhattan in one day. They were able to steal millions of dollars because the balance check was in real-time but the settlements weren't (so the balance was not drawn down).