Difference between revisions of "Business logic vulnerability"

From OWASP
Jump to: navigation, search
(Undo revision 61074 by Ya Ali (talk))
 
(22 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Template:Stub}}
 
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
 
__TOC__
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR Table of Contents]]
 
  
 
==Description==
 
==Description==
TBD
+
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:
  
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.
+
* 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
  
# Start with a one-sentence description of the 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:
# What is the problem that creates the vulnerability?
+
# What are the attacks that target this vulnerability?
+
# What are the technical impacts of this vulnerability?
+
  
 +
* 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
  
==Risk Factors==
+
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.
  
TBD
+
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.
  
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
+
==Risk Factors==
* Discuss the technical impact of a successful exploit of this vulnerability
+
* Consider the likely [business impacts] of a successful attack
+
  
 +
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.
  
==Examples==
+
Business logic flaws are often the most critical in terms of consequences, as they are deeply tied into the company's process.
 
+
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]
+
 
+
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
  
* [[Attack 1]]
+
Fraud
* [[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==
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]
 
 
 
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__

Latest revision as of 09:16, 24 October 2013

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


Last revision (mm/dd/yy): 10/24/2013

Vulnerabilities Table of Contents

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

Fraud

Related Vulnerabilities

Related Controls

Related Technical Impacts

References