Difference between revisions of "Business Logic Security Cheat Sheet"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
= Introduction =
 
= 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.  
+
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? =
 
= 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.  
 
Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules, workflow or privilege manipulation.  
 
= Generic Example of a Business Logic Issue =
 
  
 
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.  
 
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.  
 
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.
 
 
= Guidance =
 
  
 
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:  
 
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:  
Line 23: Line 17:
 
# Test Reporting – Save and report results
 
# Test Reporting – Save and report results
  
= Business logic vulnerability categories =
+
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.
 +
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 =
  
== BUSINESS RULES ==
+
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.   
 
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.
  
The following are 6 sub classes of business rules vulnerabilities:
+
= 2. Consider Time Related Business Rules ===
  
=== Process Timing ===
+
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.   
 
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.   
  
=== Client side validations ===
+
= 3. Consider Money Related Business Rules ===
  
It must be ensured that the application implements all the validations related to business logic on the server side. Such validations must not reside on the client side. Client side validations are not foolproof and can be easily bypassed using web proxy editor tools.
+
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?
The testing must involve attempts to remove javascripts from the response or to disable them on the browsers so as to evade client side validations and perform actions against the business rules of the application. Testing should ensure whether the application has implemented validations properly on the server side.
+
  
=== Business Logic Decision ===
+
= 4. Consider Process Related Business Rules ===
  
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 2 such cases listed below, it is important to look for such scenarios in the application while testing.
+
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?
  
==== Use of non-editable fields ====
+
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 not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. The fields remain non-editable only in the context of the browsers. The users can easily edit their values using proxy editor tools and try to manipulate business logic. If the application exposes values related to business rules like quantity, etc. as non-editable fields it must maintain a copy on the server side and use the same for business logic processing.
+
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.  
  
==== Exposing key request parameters ====
+
= 5. Consider Human Resource Business Rules
  
At times application developers inadvertently expose key parameters like the once indicating the type of the user, nature of the request, status of the transaction, etc. to the users. Such parameters are usually seen in redirection requests that are sent as an input for further processing to other classes or features of the application.
+
TBD: This is for rules surrounding HR. Could the application be used to violate any HR procedures or standards
The application must not expose such parameters to the users and instead store them in session objects or server side data stores. The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application.
+
  
In case if such values need to be exposed to the users, a checksum of such request parameters must be present in the request to ensure tamper proof communication.
+
= 6. Consider Contractual Relationship Business Rules
  
=== Information Leakage ===
+
TBD: Can the application be used in a manner that is inconsistent with any contractual relationships -- such as a contract with a service provider
  
The application must guard against attackers that are able gain information by decompiling JavaScript, flash or Silverlight on the client side or direct link URL information and using this information to enter the business process and have access to unauthorized information.
+
= 7. TBD - Let's think of some other REAL Business Rules
  
=== Lack of Change Control Management ===
 
  
The application must apply business rules uniformly throughout the entire application ensuring that editing or updating follows the same rules as the initial creation or entry of information. 
 
  
=== Unexposed Parameters ===
+
= Related Articles  =
  
There are cases where the request parameters directly bound to business objects. Such objects are business entities that are used for processing business logic. However, such crucial business objects may even have unexposed variables. The names of such variables could be guessable and related to business rules like price, role etc. Thus, an attacker can send additional parameters in the request and if their names happen to match with those of the unexposed parameters, the attacker would be able to alter the values of the unexposed variables and thus bypass the business rule.
+
WARNING: Most of the examples discussed in these articles are not actually business logic flaws
 
+
The application must accept only desired inputs from the user and the rest must be rejected or left unbound with the business objects. 
+
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.
+
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.
+
 
+
== WORKFLOWS ==
+
 
+
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 following are 2 sub classes of workflow vulnerabilities:  
+
+
=== Premature Approval/Completion ===
+
 
+
The application must require that if the workflow is terminated without correctly completing any and all actions and spawned actions are “rolled back” or canceled.
+
 
+
=== Lack of Process Verification ===
+
 
+
The application must be self-aware and 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 developing business logic abuse cases with the goal of successfully completing the business process while
+
 
+
== PRIVILEGE MANIPULATION ==
+
 
+
Privilege manipulation vulnerabilities involve any type of vulnerability that allows the attacker to gain access to and misuse an application in a way that will escalate the users privileges to access resources they are not have are not authorized to have. Preventing this type of exploit requires that the application use strong processes to protect resources.
+
 
+
For example, an application may have different membership or class levels of users with each level having different privileges. If cookies are written upon login, a user may be able to guess or predict the cookie value to elevate their privileges. 
+
The following are 4 sub classes of privilege manipulation vulnerabilities:
+
 
+
=== Parameter Manipulation ===
+
 
+
The application’s business logic must not be constructed in such a way that it does not validate parameters before they are processed, or allow cookies or LDAP parameters to be manipulated, allowing attackers to get authenticated or get access to unauthorized data in the application.
+
 
+
In most of the applications primary key values that are used to uniquely identify an entity in the application are exposed as “ID” parameters to the users like "employeeID", accounted etc. If an application directly identifies the record to be processed based on the “ID” parameter present in the request without ensuring if the logged-in user is permitted to access that record; the user can access any valid record in the system by supplying its corresponding “ID” value.
+
 
+
Applications must ensure to implement proper authorization check before processing records from the data stores based on request parameters, cookie values or any other source of input. Additionally, instead of exposing primary key values some dummy values can be exposed to the user.
+
 
+
=== Predictive Parameters or Resource Naming ===
+
 
+
The application must be constructed with session tokens, credentials, and URLs that are not guessable or predictable preventing attackers from manipulating the business process.
+
 
+
=== Dependency on visibility of view elements ===
+
 
+
Some application developers believe in the concept of – “what is hidden is secure”. They make the visibility of the some input fields dependent the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic.
+
 
+
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. 
+
 
+
Thus there exists a hole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are kept invisible from them.
+
 
+
=== Business Logic Invocation Technique ===
+
 
+
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the business logic entities. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. There have been cases where fully qualified class names of the business logic class travels in the request. In such a case an attacker can easily change the name of the class and perform unauthorized operations in the application.
+
 
+
In addition to this there is a common trend observed now-a-days in the application designs that is to determine and invoke a method of the business class objects based on the some request parameters. If there are no restrictions present in these classes before processing such request parameters then an attacker can easily get a control over executing any valid method of the business logic classes by manipulating such crucial parameters.
+
 
+
==== Secure Practice ====
+
 
+
The applications must ensure to:
+
* Apply necessary authorization check before processing business logic method
+
* Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to specific URLs/methods/views.
+
 
+
==== Testing Criteria ====
+
With a view of the above mentioned factors we must carefully evaluate the request structure to determine whether user inputs are used to determine any of the following elements (as applicable):
+
 
+
* Business logic class
+
* Method names
+
* View components
+
 
+
In such case identify unexposed configurations and business logic methods as per the user’s privileges (wherever applicable) and attempt to access them.
+
 
+
Testing for privilege manipulation vulnerabilities involves using an intercepting proxy to observe the HTTP POST/GET looking for variables that can be manipulated an resubmitted to manipulate the application.
+
 
+
= Related Articles  =
+
  
 
* Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –  
 
* Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –  

Revision as of 13:24, 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 any 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

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, some testing can be automated using 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