|
|
| Line 1: |
Line 1: |
| − | = DRAFT CHEAT SHEET - WORK IN PROGRESS =
| + | {{taggedDocument |
| − | | + | | type=delete |
| − | = Introduction =
| + | | comment=old material and controversial |
| − | | + | }} |
| − | 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 a Business Logic Vulnerability? =
| |
| − | | |
| − | A business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules. Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization.
| |
| − | | |
| − | Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. A useful rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, then it's probably just a typical application vulnerability in one of the other categories.
| |
| − | | |
| − | For example, 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.
| |
| − | | |
| − | 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
| |
| − | #) the control is in place to implement the business rule,
| |
| − | #) the control is implemented correctly and cannot be bypassed or tampered with, and
| |
| − | #) 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<br/>
| |
| − | David Fern dfern[at]verizon.net
| |
| − | | |
| − | == Other Cheatsheets ==
| |
| − | {{Cheatsheet_Navigation}}
| |
| − | | |
| − | [[Category:Cheatsheets]]
| |
