Testing for business logic

Brief Summary of Business Logic Vulnerability
Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional methods. If an application's authentication mechanism is developed with the intention of performing steps 1, 2, 3 in that specific order to authenticate a user.

What happens if you go from step 1 straight to step 3?

In this simplistic example, does the application provide access by failing open; deny access, or just error out with a 500 message?

There are many examples that can be made, but the one constant lesson is "think outside of conventional wisdom". This type of vulnerability cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the hardest to detect, and usually application specific but, at the same time, usually one of the most detrimental to the application, if exploited.

The classification of business logic flaws has been under-studied; although exploitation of business flaws frequently happens in real-world systems, and many applied vulnerability researchers investigate them. The greatest focus is in web applications. There is debate within the community about whether these problems represent particularly new concepts, or if they are variations of well-known principles. Testing of business logic flaws is similar to the test types used by functional testers that focus on logical or finite state testing. These types of tests require that security professionals think a bit differently, develop abused and misuse cases and use many of the testing techniques embraced by functional testers. Automation of business logic abuse cases is not possible and remains a manual art relying on the skills of the tester and their knowledge of the complete business process and its rules.

Business Limits and Restrictions
Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people's behavior? Then, consider whether the application enforces those rules. It's generally pretty easy to identify the test and analysis cases to verify the application if you're familiar with the business. If you are a third-party tester, then you're going to have to use your common sense and ask the business if different operations should be allowed by the application. Sometimes, in very complex applications, you will not have a full understanding of every aspect of the application initially. In these situations, it is best to have the client walk you through the application, so that you may gain a better understanding of the limits and intended functionality of the application, before the actual test begins. Additionally, having a direct line to the developers (if possible) during testing will help out greatly, if any questions arise regarding the application's functionality.

Description of the Issue
Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer's intentions, and some creative "out-of-the-box" thinking can break the application's logic. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to completely subvert the application.

Example 1:

Suppose an e-commerce site allows users to select items to purchase, view a summary page and then tender the sale. What if an attacker was able to go back to the summary page, maintaining their same valid session and inject a lower cost for an item and complete the transaction, and then check out?

Example 2:

Holding/locking resources and keeping others from purchases these items online may result in attackers purchasing items at a lower price. The countermeasure to this problem is to implement timeouts and mechanisms to ensure that only the correct price can be charged.

Example 3:

What if a user was able to start a transaction linked to their club/loyalty account and then after points have been added to their account cancel out of the transaction? Will the points/credits still be applied to their account?

Business Logic Test Cases
Every application has a different business process, application specific logic and can be manipulated in an infinite number of combinations. This section provides some common examples of business logic issues but in no way a complete list of all issues.

Business Logic exploits can be broken into the following categories:

4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)

4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)

4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)

4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)

4.12.4 Test Tamper Evidence (OTG-BUSLOGIC-004)

4.12.5 Test Excessive Rate (speed) of Use Limits (OTG-BUSLOGIC-005)

4.12.6 Test for Process Timing (OTG-BUSLOGIC-006)

4.12.7 Test Size of Request Limits (OTG-BUSLOGIC-007)

4.12.8 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-008)

4.12.9 Test bypass of Correct Sequence (OTG-BUSLOGIC-009)

4.12.10 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-0010)

4.12.11 Test Self-Hosted Payment Cardholder Data Processing (OTG-BUSLOGIC-011)

4.12.12 Test Security Incident Reporting Information (OTG-BUSLOGIC-012)

4.12.13 Test Defenses Against Application Mis-Use (OTG-BUSLOGIC-013)

4.12.14 Test Upload of Unexpected File Types (OTG-BUSLOGIC-014)

4.12.15 Test Upload of Malicious Files (OTG-BUSLOGIC-015)