Reviewing Code for Race Conditions

Revision as of 15:32, 22 October 2008 by Rahimjina (Talk | contribs)

Jump to: navigation, search
OWASP Code Review Guide Table of Contents


Race Conditions occur when a piece of code does not work as it is supposed to (like many security issues). They are the result of an unexpected ordering of events which can result in the finite state machine of the code to transition to a undefined state and also give rise to contention of more than one thread of execution over the same resource. Multiple threads of execution acting or manipulating the same area in memory or persisted data which gives rise to integrity issues.

How they work:

With competing tasks manipulating the same resource we can easily get a race condition as the resource is not in step-lock or utilises a token based multi-use system such as semaphores.


X = X + 10

So with no controls surrounding this code in a multithreaded environment we get the following problem:

T1 places X into a register in thread 1
T2 places X into a register in thread 2
T1 saves the register value (15) into X.
T1 saves the register value (15) into X.


How to locate the potentially vulnerable code


Look for code which used multithreaded environments:

Keywords such as:




Classic ASP

Notice multithreading is not directly supported feature of classic ASP so this kind of race conditions could be present only when using COM objects.

Vulnerable Patterns for Race Conditions

Static methods (One per class, not one per object) are an issue particularly if there is a shared state among multiple threads. For example in Apache struts static members should not be used to store information relating to a particular request. The same instance of a class can be used by multiple threads and the value of the static member can not be guaranteed.


  1. References to static variables, these much be thread locked.
  3. Static methods that alter static state

Related Articles