Difference between revisions of "Business Logic Security Cheat Sheet"
(draft to live!)
|Line 1:||Line 1:|
= Introduction =
= Introduction =
Revision as of 12:16, 23 October 2013
- 1 Introduction
- 2 What is Business Logic Vulnerability?
- 3 Generic Example of a Business Logic Issue
- 4 Guidance
- 5 Business logic vulnerability categories
- 5.1 BUSINESS RULES
- 5.2 WORKFLOWS
- 5.3 PRIVILEGE MANIPULATION
- 6 Related Articles
- 7 Authors and Primary Editors
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 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.
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:
- Requirements and Design Review – Understand the application – scope, features, business rules and roles and privilege levels.
- Test Planning – Gather data, roles and scenarios, understand workflows and approval levels.
- Test Case Design – Write the test cases i.e. abuse cases
- Test Environment Setup – Build the test bed
- Test Execution – Execute the tests
- Test Reporting – Save and report results
Business logic vulnerability categories
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:
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
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.
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.
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.
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:
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 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:
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.
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.
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.
- Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –
- 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
OWASP Cheat Sheets Project Homepage
Developer Cheat Sheets (Builder)
- Authentication Cheat Sheet
- Choosing and Using Security Questions Cheat Sheet
- Clickjacking Defense Cheat Sheet
- C-Based Toolchain Hardening Cheat Sheet
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- Cryptographic Storage Cheat Sheet
- DOM based XSS Prevention Cheat Sheet
- Forgot Password Cheat Sheet
- HTML5 Security Cheat Sheet
- Input Validation Cheat Sheet
- JAAS Cheat Sheet
- Logging Cheat Sheet
- .NET Security Cheat Sheet
- Password Storage Cheat Sheet
- Pinning Cheat Sheet
- Query Parameterization Cheat Sheet
- Ruby on Rails Cheatsheet
- REST Security Cheat Sheet
- Session Management Cheat Sheet
- SAML Security Cheat Sheet
- SQL Injection Prevention Cheat Sheet
- Transaction Authorization Cheat Sheet
- Transport Layer Protection Cheat Sheet
- Unvalidated Redirects and Forwards Cheat Sheet
- User Privacy Protection Cheat Sheet
- Web Service Security Cheat Sheet
- XSS (Cross Site Scripting) Prevention Cheat Sheet
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets
OpSec Cheat Sheets (Defender)
Draft Cheat Sheets
- OWASP Top Ten Cheat Sheet
- Access Control Cheat Sheet
- Application Security Architecture Cheat Sheet
- Business Logic Security Cheat Sheet
- PHP Security Cheat Sheet
- Secure Coding Cheat Sheet
- Secure SDLC Cheat Sheet
- Threat Modeling Cheat Sheet
- Web Application Security Testing Cheat Sheet
- Grails Secure Code Review Cheat Sheet
- IOS Application Security Testing Cheat Sheet
- Key Management Cheat Sheet
- Insecure Direct Object Reference Prevention Cheat Sheet
- Content Security Policy Cheat Sheet