Difference between revisions of "Business logic vulnerability"

From OWASP
Jump to: navigation, search
Line 7: Line 7:
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
 
[[Category:FIXME|Stub article, needs review]]
 
  
 
==Description==
 
==Description==
TBD
 
  
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.
+
Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization. For example:
  
# Start with a one-sentence description of the vulnerability
+
* Purchase orders are not processed before midnight
# What is the problem that creates the vulnerability?
+
* Written authorization is not on file before web access is granted
# What are the attacks that target this vulnerability?
+
* Transactions in excess of $2000 are not reviewed by a person
# What are the technical impacts of this vulnerability?
+
  
 +
Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Here are some examples of problems that are not business logic vulnerabilities:
  
==Risk Factors==
+
* Performing a denial of service by locking an auction user's account
 +
* Posting unvalidated input publically
 +
* Cracking MD5 hashes
 +
* Brute forcing a password recovery scheme
  
TBD
+
Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. Business logic problems are different from authentication problems and every other category. There are many signficant business logic vulnerabilities, but they are far less common than the type of items in the OWASP Top Ten for example.
  
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
+
A nice rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, you can't see business logic flaws.
* Discuss the technical impact of a successful exploit of this vulnerability
+
* Consider the likely [business impacts] of a successful attack
+
  
 +
==Risk Factors==
  
==Examples==
+
The likelihood of business logic problems really depends on the circumstances. You'll need to evaluate the threat agents who could possibly exploit the problem and whether it would be detected. Again, this will take a strong understanding of the business.  The vulnerabilities themselves are often quite easy to discover and exploit without any special tools or techniques, as they are a supported part of the application.
 
+
TBD
+
 
+
===Short example name===
+
: 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]
+
  
 +
Business logic flaws are often the most critical in terms of consequences, as they are deeply tied into the company's process.
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
 
* [[Attack 1]]
 
* [[Attack 2]]
 
 
  
 
==Related [[Vulnerabilities]]==
 
==Related [[Vulnerabilities]]==
 
* [[Vulnerability 1]]
 
* [[Vulnerabiltiy 2]]
 
 
Note: the contents of "Related Problems" sections should be placed here
 
 
  
 
==Related [[Controls]]==
 
==Related [[Controls]]==
 
* [[Control 1]]
 
* [[Control 2]]
 
 
Note: contents of "Avoidance and Mitigation" and "Countermeasure" related Sections should be placed here
 
 
  
 
==Related [[Technical Impacts]]==
 
==Related [[Technical Impacts]]==
 
* [[Technical Impact 1]]
 
* [[Technical Impact 2]]
 
 
  
 
==References==
 
==References==
TBD
 
 
[[Category:FIXME|
 
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]]
 
  
 
__NOTOC__
 
__NOTOC__

Revision as of 14:50, 31 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/31/2008

Description

Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization. For example:

  • Purchase orders are not processed before midnight
  • Written authorization is not on file before web access is granted
  • Transactions in excess of $2000 are not reviewed by a person

Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Here are some examples of problems that are not business logic vulnerabilities:

  • Performing a denial of service by locking an auction user's account
  • Posting unvalidated input publically
  • Cracking MD5 hashes
  • Brute forcing a password recovery scheme

Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. Business logic problems are different from authentication problems and every other category. There are many signficant business logic vulnerabilities, but they are far less common than the type of items in the OWASP Top Ten for example.

A nice rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, you can't see business logic flaws.

Risk Factors

The likelihood of business logic problems really depends on the circumstances. You'll need to evaluate the threat agents who could possibly exploit the problem and whether it would be detected. Again, this will take a strong understanding of the business. The vulnerabilities themselves are often quite easy to discover and exploit without any special tools or techniques, as they are a supported part of the application.

Business logic flaws are often the most critical in terms of consequences, as they are deeply tied into the company's process.

Related Attacks

Related Vulnerabilities

Related Controls

Related Technical Impacts

References