This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Business logic vulnerability

Revision as of 13:38, 21 May 2009 by Ya Ali (talk | contribs) (Brief Summary of Business Logic Vulnerability)

Jump to: navigation, search

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.

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


Related Vulnerabilities

Related Controls

Related Technical Impacts