I have a Chrome extension which is perfect for race attacks. https://github.com/sakurity/racer
"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).
By the way because of this instead of select for update for single record I prefer update with no change. If there is no record, nothing will be locked.
Generally I dont find adding more locks hurts things that are well designed - often you will find deadlocks turn into just waiting for your turn in line - and then you can tune your db code or your hardware or your whatever to maximize that throughput.
Also fwiw if you are doing any sort of upsert and you are not locking for the update/insert combo, then you are definitely opening the door to a duplicate key insert - as long as you handle that though, nbd.
You'll be my hero of the day!
Researchers found a way to analyze database logs to identify race conditions in databases, and demonstrated how once this knowledge acquired, it left websites open to be exploited through their public APIs.
Are there type safe database libraries for Idris or Rust?
Also the issue is that it's trying to be database agnostic which means that you can't use any of the cool features from your database of choice.