Difference between revisions of "Race Conditions"

From OWASP
Jump to: navigation, search
Line 15: Line 15:
 
==Description==
 
==Description==
  
A vulnerability is a weakness in an application (frequently a broken or missing control) that enables an attack to succeed. Be sure you don't put [attacks] or [controls] in this category.
+
A race condition occurs when a pair of routine programming calls in an application do not perform in the sequential manner that was intended per business rules.
 
+
It is a timing event within software that can become a security vulnerability if the calls are not performed in the correct order.
# Start with a one-sentence description of the vulnerability
+
# What is the problem that creates the vulnerability?
+
# What are the attacks that target this vulnerability?
+
# What are the technical impacts of this vulnerability?
+
  
  
 
==Risk Factors==
 
==Risk Factors==
  
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
+
* A common business impact of a race condition is one where a payment confirmation occurs without producing a request object for order fulfillment.
* Discuss the technical impact of a successful exploit of this vulnerability
+
* The technical impact of this vulnerability can be mitigated through thread management classes or other programming constructs that control the synchronization of threads
* Consider the likely [business impacts] of a successful attack
+
  
  
 
==Examples==
 
==Examples==
  
===Short example name===
+
TBD
: A short example description, small picture, or sample code with [http://www.site.com links]
+
 
+
===Short example name===
+
: A short example description, small picture, or sample code with [http://www.site.com links]
+
  
  
Line 63: Line 54:
  
 
==References==
 
==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
 
 
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
 
* http://www.link1.com
 
* [http://www.link2.com Title for the link2]
 
 
[[Category:FIXME|add links
 
 
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 
 
Availability Vulnerability
 
 
Authorization Vulnerability
 
 
Authentication Vulnerability
 
 
Concurrency Vulnerability
 
 
Configuration Vulnerability
 
 
Cryptographic Vulnerability
 
 
Encoding Vulnerability
 
 
Error Handling Vulnerability
 
 
Input Validation Vulnerability
 
  
Logging and Auditing Vulnerability
 
  
Session Management Vulnerability]]
+
* [http://cwe.mitre.org/data/definitions/362.html CWE 79].
  
 
__NOTOC__
 
__NOTOC__

Revision as of 17:34, 13 December 2008

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Contents


ASDR Table of Contents


Last revision (mm/dd/yy): 12/13/2008


Description

A race condition occurs when a pair of routine programming calls in an application do not perform in the sequential manner that was intended per business rules. It is a timing event within software that can become a security vulnerability if the calls are not performed in the correct order.


Risk Factors

  • A common business impact of a race condition is one where a payment confirmation occurs without producing a request object for order fulfillment.
  • The technical impact of this vulnerability can be mitigated through thread management classes or other programming constructs that control the synchronization of threads


Examples

TBD


Related Attacks


Related Vulnerabilities

Related Controls


Related Technical Impacts


References