Difference between revisions of "Business logic vulnerability"
|Line 1:||Line 1:|
[[Table of Contents]]
Revision as of 18:15, 20 February 2009
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Last revision (mm/dd/yy): 02/20/2009
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.
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.