This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Business Logic Security Cheat Sheet"

From OWASP
Jump to: navigation, search
(draft to live!)
Line 11: Line 11:
 
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 techniques used by functional testers the 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 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 =
 
= Guidance =

Revision as of 12:59, 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.

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.

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:

  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

Business logic vulnerability categories

BUSINESS RULES

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.

The following are 6 sub classes of business rules vulnerabilities:

Process Timing

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

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. 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

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.

Use of non-editable fields

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.

Exposing key request parameters

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. 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.

Information Leakage

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.

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

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.

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 –

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