Difference between revisions of "Business Logic Security Cheat Sheet"

From OWASP
Jump to: navigation, search
Line 17: Line 17:
 
# Test Reporting – Save and report results
 
# 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 any of the business rules.
+
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.
In simple words an abuse case would be – reverse of the business rule. Creating an exhaustive list of abuse cases for all the features of the application and testing for them would enumerate all the business logic errors present in the application.
+
  
 
= 1. Identify Business Rules and Derive Test/Abuse Cases =
 
= 1. Identify Business Rules and Derive Test/Abuse Cases =
Line 29: Line 28:
 
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.   
 
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.     
 
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, some testing can be automated using functional and security testing tools.
+
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 ===
+
= 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...
 
TBD: Can the application be used to change orders after they are committed, make transactions appear in the wrong sequence, etc...
Line 37: Line 36:
 
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.   
 
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 ===
+
= 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?
 
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 ===
+
= 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?
 
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?
Line 50: Line 49:
 
Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.  
 
Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.  
  
= 5. Consider Human Resource Business Rules
+
= 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
 
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
+
= 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
 
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
+
= 7. TBD - Let's think of some other REAL Business Rules =
  
  

Revision as of 13:29, 24 October 2013

Contents

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

Authors and Primary Editors

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

Other Cheatsheets

OWASP Cheat Sheets Project Homepage

Developer Cheat Sheets (Builder)

Assessment Cheat Sheets (Breaker)

Mobile Cheat Sheets

OpSec Cheat Sheets (Defender)

Draft Cheat Sheets