A Race To The Bottom: Database Transactions Undermining Your AppSec
summary
Shows a concrete failure mode: concurrent transfers let ten requests overdraw an account because defaults allow reads without locks. Reproduces it with a Go snippet and local multithreaded clients, then scales attack suggestions using turbo Intruder and Burp to beat network jitter. Demonstration logs reveal interleaved transaction operations on PostgreSQL/MySQL variants; the fix list is specific: FOR UPDATE or versioned optimistic locking, raise isolation to serializable (or appropriate snapshot level), and add concurrent-unit tests that retry failed transactions.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:07Databases as black boxes
- 3:16Live demo: bank transfer
- 5:05Race condition in transfers
- 8:16Database locks and concurrency
- 10:01SQL read phenomena explained
- 13:54Race conditions in multithreading
- 15:18Exploiting the race condition
- 19:33Impact on microservices
- 21:37Exploitation techniques
- 24:02Fixing with optimistic locking
- 25:26Pessimistic locking
- 28:15Transaction isolation deep dive
- 31:47Database implementation differences
- 33:12Detecting unsecured transactions
- 34:16Real-world exploits
- 34:58Key takeaways
- 36:44Q&A
- 38:31Q&A
- 40:20Q&A
- 41:45Closing remarks
related talks
41mConcurrency, Scalability and Transactions -- Myths and Surprises
17mThe Hidden Danger in Financial Transactions
41mTransactions: myths, surprises and opportunities
28mData corrupting architectures we know and love
45mTransactions and Concurrency Control Patterns
32mThe Very Hungry Transaction
34mThe Very Hungry Transaction
48mUnderstanding and Reducing Application Contention