race conditions, etc.
Are there automatic tools for this? What manual techniques should I use?
From the Area51 proposal
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
Timing attacks, race condition (CWE-362) vulnerabilities are not very common for web-applications, these are primarily problems of more low-level languages. For example, in CVE-2006-5178, race condition was due to incorrect implementation in PHP interpreter itself. But application relying on those functions goes vulnerable too.
It could be daunting to attempt to reproduce such vulnerability, due to timing issues and the needs of specific environment. With automated vulnerability scanners it is not feasible to conduct such test - even for human it is not easy to find such vulnerability.
To my opinion, developer just needs to keep in mind when the main process can be interrupted. Atomicity should be provided when the sequence of actions must not be interruptible. Mainly database actions are susceptible to such attacks. Even when DBMS supports transactions and provides means for safe synchronization, there can be more global actions that are under control of DBMS to make them atomic. Attention should be pointed also to situations where threads are used.
In the link to CWE-362, there are list of papers that are useful to read. Those would provide much more information than I have given here.
The discussion and answers here appear to be around race conditions, which are usually referred to by that name.
If you really mean timing attacks, you're probably talking about information leakage via discrepancies in execution time. A Lesson In Timing Attacks is a nice, accessible introduction to this.
I'm not aware of any tools that could specifically assist in discovering these, but common web assessment tools could reveal other problems that could be exacerbated by a timing attack.
Suppose you have a vulnerability that allows an external party to run SQL code against your database -- classic SQL injection. Suppose you've taken some precautions: they cannot get data back out or write arbitrary information to your database, you just return a generic error message of some sort. It would be possible for the external party to probe the schema of your database using "select" statements and timing how long it took to receive a response; simply by observing how much work your back-end system is doing, they're learning something about it that they may not have otherwise (whether a particular table actually exists, whether there many be many records in a table, etc.).