Difference between revisions of "Business logic vulnerability"

From OWASP
Jump to: navigation, search
(Brief Summary of Business Logic Vulnerability)
(21 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}}'''
Line 9: Line 5:
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
[[ASDR Table of Contents]]
+
==Brief Summary of Business Logic Vulnerability==
  
==Description==
+
The most recent research represented about the concept Business Logic vulnerability by Jr.Scientist Faisal Nabi in the 24th Annual Computer Security Application Conference (ACSAC, 08)California, Dec 8-12 ,2008.  
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.
+
  
# Start with a one-sentence description of the vulnerability
+
(ACSAC,08)work in progress session:
# What is the problem that creates the vulnerability?
+
# What are the attacks that target this vulnerability?
+
# What are the technical impacts of this vulnerability?
+
  
 +
Designing a Secure Framework Method for Business Application Logic Integrity in e-Commerce Systems,Faisal Nabi, Distributed System Research Group, Department of Computer Science, Victoria University of Wellington, Wellington, New Zealand. http://www.acsac.org/2008/program/wip/
  
==Risk Factors==
+
Business-level- Process Integration is based on business components integration, which takes part to process a certain job/task event, which comes into being because of business logic inside a component. When we talk about business process integration, which means integrating business component’s business processing logic,this integration completely rely upon that Business component’s Interface. A component interface is self descriptor which provides specification, which defines that which component offers, what service (such as,Account service provided by Account Component interface, this is called Component interface specification,which reflects component’s business process functionality, which indicates a component offer a particular service)Integration of components is limited through only the interface. Therefore, business process integration, which depends on component’s interface specification in business component, it refers to business function / processing logic, specification of that business component (Components are reusable units for composition. This statement captures the very fundamental concept of component-based development, that an application is made up and composed of a number of individual parts,and that these parts are specifically designed for integration in a number of different applications. It also captures the “idea that one component may be part of another component” , or part of a sub-system or system, both of which represent components in their own right), and integration of all this process, then develop overall business processing logic for a business component-based software to develop an application in the middle-tier, which connected with information system in the back-end systems of organization.
  
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
+
Since, this business process integration is made on the base of business functional concern; it can not be dealt with technological point of view, because problem is not based on technical or technological specific principle of Integration, which is based on related to some particular component model, but as it is stated above, issue identifies that business processing designed solution based on business components and their business processing integration. This is a point , where the focus is set to the logical structure of the “business solution”, this is the stage where logical problems occurs due to lack of paying attention to the design-based testing environment for Logical structure of the business solution , are known as Business Logic Vulnerabilities (Faisal Nabi, 2008).
* Discuss the technical impact of a successful exploit of this vulnerability
+
* Consider the likely [business impacts] of a successful attack
+
  
 +
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:
  
==Examples==
+
* 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
  
===Short example name===
+
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:
: A short example description, small picture, or sample code with [http://www.site.com links]
+
  
===Short example name===
+
* Performing a denial of service by locking an auction user's account
: A short example description, small picture, or sample code with [http://www.site.com links]
+
* 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.
  
==Related [[Attacks]]==
+
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.
  
* [[Attack 1]]
+
==Risk Factors==
* [[Attack 2]]
+
  
 +
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.
  
==Related [[Vulnerabilities]]==
+
Business logic flaws are often the most critical in terms of consequences, as they are deeply tied into the company's process.
  
* [[Vulnerability 1]]
+
==Related [[Attacks]]==
* [[Vulnerabiltiy 2]]
+
  
Note: the contents of "Related Problems" sections should be placed here
+
Fraud
  
 +
==Related [[Vulnerabilities]]==
  
 
==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__

Revision as of 08:38, 21 May 2009

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


Last revision (mm/dd/yy): 05/21/2009

Vulnerabilities Table of Contents

Brief Summary of Business Logic Vulnerability

The most recent research represented about the concept Business Logic vulnerability by Jr.Scientist Faisal Nabi in the 24th Annual Computer Security Application Conference (ACSAC, 08)California, Dec 8-12 ,2008.

(ACSAC,08)work in progress session:

Designing a Secure Framework Method for Business Application Logic Integrity in e-Commerce Systems,Faisal Nabi, Distributed System Research Group, Department of Computer Science, Victoria University of Wellington, Wellington, New Zealand. http://www.acsac.org/2008/program/wip/

Business-level- Process Integration is based on business components integration, which takes part to process a certain job/task event, which comes into being because of business logic inside a component. When we talk about business process integration, which means integrating business component’s business processing logic,this integration completely rely upon that Business component’s Interface. A component interface is self descriptor which provides specification, which defines that which component offers, what service (such as,Account service provided by Account Component interface, this is called Component interface specification,which reflects component’s business process functionality, which indicates a component offer a particular service)Integration of components is limited through only the interface. Therefore, business process integration, which depends on component’s interface specification in business component, it refers to business function / processing logic, specification of that business component (Components are reusable units for composition. This statement captures the very fundamental concept of component-based development, that an application is made up and composed of a number of individual parts,and that these parts are specifically designed for integration in a number of different applications. It also captures the “idea that one component may be part of another component” , or part of a sub-system or system, both of which represent components in their own right), and integration of all this process, then develop overall business processing logic for a business component-based software to develop an application in the middle-tier, which connected with information system in the back-end systems of organization.

Since, this business process integration is made on the base of business functional concern; it can not be dealt with technological point of view, because problem is not based on technical or technological specific principle of Integration, which is based on related to some particular component model, but as it is stated above, issue identifies that business processing designed solution based on business components and their business processing integration. This is a point , where the focus is set to the logical structure of the “business solution”, this is the stage where logical problems occurs due to lack of paying attention to the design-based testing environment for Logical structure of the business solution , are known as Business Logic Vulnerabilities (Faisal Nabi, 2008).

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