Business Logic Security Cheat Sheet - Revision history

Jmanico: Replaced content with "{{taggedDocument | type=delete | comment=old material and controversial }}"

2018-08-17T21:08:04Z

Replaced content with "{{taggedDocument | type=delete | comment=old material and controversial }}"

Jim Bird at 15:55, 5 June 2014

2014-06-05T15:55:40Z

Jmanico at 04:31, 8 November 2013

2013-11-08T04:31:15Z

Jeff Williams at 18:35, 24 October 2013

2013-10-24T18:35:33Z

Jeff Williams at 18:35, 24 October 2013

2013-10-24T18:35:09Z

Jeff Williams at 18:34, 24 October 2013

2013-10-24T18:34:42Z

Jeff Williams at 18:29, 24 October 2013

2013-10-24T18:29:54Z

Jeff Williams at 18:24, 24 October 2013

2013-10-24T18:24:14Z

Show changes

David Fern at 12:59, 24 October 2013

2013-10-24T12:59:30Z

Jmanico: draft to live!

2013-10-23T17:16:50Z

draft to live!

@@ Line 5: / Line 5: @@
 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 a Business Logic Vulnerability? =
-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.
+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.

← Older revision		Revision as of 04:31, 8 November 2013
Line 1:		Line 1:
		+	= DRAFT CHEAT SHEET - WORK IN PROGRESS =
		+
	= Introduction =		= Introduction =

@@ Line 16: / Line 16: @@
 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 perform the transactions,
+#) 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

@@ Line 16: / Line 16: @@
 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 perform the transactions,
+#) the control is in place to perform the transactions,
-) the control is implemented correctly and cannot be bypassed or tampered with, and
+#) the control is implemented correctly and cannot be bypassed or tampered with, and
-) the control is used properly in all the necessary places
+#) 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.

@@ Line 5: / Line 5: @@
 = 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.  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.
-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.
+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.
-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:
+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.

@@ Line 1: / Line 1: @@
-= DRAFT CHEAT SHEET - WORK IN PROGRESS =
+{{taggedDocument
+| type=delete
-= Introduction =
+| comment=old material and controversial
 }}

@@ Line 17: / Line 17: @@
 # 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.
 = 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.
 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...
@@ 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.
-= 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?
-= 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?
@@ Line 50: / Line 49: @@
 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
-= 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
-= 7. TBD - Let's think of some other REAL Business Rules
+= 7. TBD - Let's think of some other REAL Business Rules =

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

← Older revision		Revision as of 17:16, 23 October 2013
Line 1:		Line 1:
−	~~= DRAFT CHEAT SHEET - WORK IN PROGRESS =~~
−
	= Introduction =		= Introduction =