Revision as of 18:29, 24 October 2013

Introduction

This cheat sheet provides some guidance for identifying some of the various types of business logic vulnerabilities and some guidance for preventing and testing for them.

What is Business Logic Vulnerability?

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules, workflow or privilege manipulation.

An electronic bulletin board system was designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on the list is found the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity list since on edit the posting is never compared again.

While there is no definitive list of possible business logic issues this section provides some guidance and common groups and generic areas to consider. The process for testing for business logic vulnerabilities requires following a process similar to those used in functional testing including:

1. Requirements and Design Review – Understand the application – scope, features, business rules and roles and privilege levels.
2. Test Planning – Gather data, roles and scenarios, understand workflows and approval levels.
3. Test Case Design – Write the test cases i.e. abuse cases
4. Test Environment Setup – Build the test bed
5. Test Execution – Execute the tests
6. Test Reporting – Save and report results

Testing for business rules vulnerabilities involves developing business logic abuse cases with the goal of successfully completing the business process while not complying with one or more of the business rules.

1. Identify Business Rules and Derive Test/Abuse Cases

The first step is to identify the business rules that you care about and turn them into experiments designed to verify whether the application properly enforces the business rule. For example, if the rule is that purchases over $1000 are discounted by 10%, then positive and negative tests should be designed to ensure that 1) the control is in place to perform the transactions, 2) the control is implemented correctly and cannot be bypassed or tampered with, and 3) the control is used properly in all the necessary places

Business rules vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent any business rules, constraints or restrictions put in place to properly complete the business process. For example, on a stock trading application is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel out if the price dropped. Business Logic testing uses many of the same testing tools and techniques used by functional testers. While a majority of Business Logic testing remains an art relying on the manual skills of the tester, their knowledge of the complete business process, and its rules, the actual testing may involve the use of some functional and security testing tools.

2. Consider Time Related Business Rules

TBD: Can the application be used to change orders after they are committed, make transactions appear in the wrong sequence, etc...

The application must be time-aware and not allow attackers to hold transactions open preventing them completing until and unless it is advantageous to do so.

3. Consider Money Related Business Rules

TBD: These should cover financial limits and other undesirable transactions. Can the application be used to create inappropriate financial transactions? Does it allow the use of NaN or Infinity? Are inaccuracies introduced because of the data structures used to model money?

4. Consider Process Related Business Rules

TBD: This is for steps in a process, approvals, communications, etc... Can the application be used to bypass or otherwise abuse the steps in a process?

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent the designed workflow or continue once the workflow has been broken. For example, an ecommerce site that give loyalty points for each dollar spent should not apply points to the customer’s account until the transaction is tendered. Applying points to the account before tendering may allow the customer to cancel the transaction and incorrectly receive points.

The application must have checks in place ensuring that the users complete each step in the process in the correct order and prevent attackers from circumventing any steps/processes in the workflow. Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.

5. Consider Human Resource Business Rules

TBD: This is for rules surrounding HR. Could the application be used to violate any HR procedures or standards

6. Consider Contractual Relationship Business Rules

TBD: Can the application be used in a manner that is inconsistent with any contractual relationships -- such as a contract with a service provider

7. TBD - Let's think of some other REAL Business Rules

Related Articles

WARNING: Most of the examples discussed in these articles are not actually business logic flaws

• Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –

https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf

• Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf
• CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

Authors and Primary Editors

Ashish Rao rao.ashish20[at]gmail.com
David Fern dfern[at]verizon.net

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

• OWASP Cheat Sheet Series