Race conditions and concurrency flaws
You find flaws born in the gap between check and use in code, prove them in your own lab with concurrent requests, close them with database transactions, atomic operations and idempotency keys, and retest under load.
Level 401 · 14 lessons · 12 practice labs
Lessons
Concept
- What a race condition is: time of check and time of use (TOCTOU)
- Races in code: read-modify-write patterns
- Limit overrun: using a single-use coupon many times
- Short task: find three race-prone operations in the lab code
Recognising
- Group sending and the single-packet technique in Burp Repeater
- Measuring concurrent requests in your own lab with Turbo Intruder
- Multi-endpoint races and intermediate states
- Time-sensitive tokens: reset links created at the same moment
- Short task: spend a gift-card balance twice through a race and prove it
Fixing
- Database transactions, isolation levels and row locks
- Atomic operations and uniqueness constraints
- Idempotency keys and distributed locks
- Concurrency tests and spotting double processing in logs
- Capstone: close the race conditions in a wallet service and retest under load
Practice labs
- The read-modify-write pattern in code: Find three operations in the lab code that read a balance then update it and are open to races.
- A coupon is used twice: Prove with a grouped send that a single-use coupon is applied twice by simultaneous requests.
- Spend a gift card balance twice: Prove with the single-packet technique that the same balance is spent twice in the lab wallet service and show the double spend in the log.
- A multi-endpoint race: basket and payment: Prove in the lab that adding an item to the basket during payment confirmation yields an unpaid item and lock the intermediate state.
- Stop double records with a unique constraint: Stop the same invitation being accepted twice with a database unique constraint and handle the error cleanly.
- A balance with an atomic update: Change balance code that reads, modifies and writes into one atomic update and prove the race is closed.
- Row locks and isolation level: Rewrite the transfer operation with row locks and the right isolation level and test it under load without deadlocks.
- Payment with an idempotency key: Add an idempotency key to the payment endpoint and prove a repeated request results in one transaction.
- Spotting double transactions in the log: Write a query that finds double transactions made within milliseconds with the same coupon or card in the transaction log.
- Write a concurrency test: Write an automated test that sends simultaneous requests for the race you closed and show it breaks when the fix is reverted.
- Reset tokens generated at the same instant: Show in the lab that two reset tokens requested at the same instant are related and make generation independent of time.
- Retest the wallet service under load: Close every race in the fictional Velora Wallet service and prove balance consistency with a load test.
About this course
You find flaws born in the gap between check and use in code, prove them in your own lab with concurrent requests, close them with database transactions, atomic operations and idempotency keys, and retest under load.
What you will learn
Prerequisites
You should have practised the topics of the same path up to level 301.
Lab environment
Lessons run on your own Kali Linux desktop in the browser, with the tools ready in their windowed interfaces. Nothing to install; a computer screen is recommended.
Frequently asked questions
- Is this course right for my level?
- The course is at level 401; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.