How to check Race Conditions in Web Applications
This is not a terrible story of one hack. May be in a future there will be more terrible things. But not now. This is more instruction to action. Often, what you do not use is very quickly forgotten. So here I decided to write something to remember and share with you.
So what does it mean — race condition?
It’s very common bug for websites with balances, vouchers or other limited resources (mostly money).
A race condition occurs when multiple threads simultaneously access the same shared code, variables, files, etc. without locking or synchronization, resulting in inconsistency of the output.
Just imagine that you can transfer your money from one account to another without loosing money from first account. And yes, it's not a joke. It's real.
For example some years ago Egor Homakov has published story about race condition in Starbucks Caffe. He posted his story here. It's insane. As he said: "I could create a simple bunch of fake gift cards bought around the world, silently generate credits on them and sell Starbucks credits online for Bitcoin with, say, 50% discount. It would easily make me a couple of millions of dollars unless Starbucks actually tracks gift card balances."
How can we check it?
Usually I use a Burp Suit. Here a couple of screenshot how to.
- Catch you request with Burp Suit Proxy. And with context menu Send to Intruder this request.
2. Go to Options menu. Here we choose number of threads: 25. It's better to use 25 (the default value is five) because we want to send many simultaneous requests.
3. Go to Payloads menu. Here we should use Payload type: Null payloads , because we are going to replay the request as it is.
And after this simple steps we can start the intruder attack and observe the results. Simple actions — great consequences.
