View source for 4.12.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)

== Brief Description ==

The application must ensure that only logically valid data can be entered at the front end as well as directly to the server side of an application of system. Only verifying data locally may leave applications vulnerable to server injections through proxies or at handoffs with other systems. This is different from simply performing Boundary Value Analysis (BVA) in that it is more difficult and in most cases can not be simply verified at the entry point, but usually requires checking some other system.

For example: An application may ask for your Social Security Number. In BVA the application should check formats and symantics (is 9 numbers long, not negative and not all 0's) for the data entered, but there are logic considerstions also. SSNs are grouped and categorized.
 
Is this person on a death file?

Are they from a certain part of the country?     

== Issue ==

The front end and the backend of the application should be verifying and validating that the data it has, is using and is passing along is logically valid. Even if the user provides valid data to an application the business logic may make the application behave differently depending on data or circmstances.

== Example ==

Suppose you manage a multi-tiered e-commerce site that allows users to order carpet. The user selects their carpet, enters the size, makes the payment, and the front end application has verified that all entered information is correct and valid for contact information, size, make and color of the carpet. But, the business logic in the background has two paths, if the carpet is in stock it is directly shipped from your warehouse, but if it is out of stock in your warehouse a call is made to a partner’s system and if they have it in-stock they will ship the order from their warehouse and reimbursed by them. 

What happens if an attacker is able to continue a valid in-stock transaction and send it as out-of-stock to your partner? 

What happens if an attacker is able to get in the middle and send messages to the partner warehouse ordering carpet without payment?

== Testing Method ==

•	Perform front-end GUI Functional Valid testing to ensure that the only acceptable values are accepted.

•	Using an intercepting proxy observe the HTTP POST/GET looking for the place that variables such as Social Security Number, cost and quality are passed.
  
•	Once variables are found start interrogating the field with logically "invalid" data, such as social security numbers or unique identifiers that do not exist or that do not fit the business logic. This testing verifies that the server functions properly and does not accept logically invalid data them.

== Test Tools ==

''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== Related Test Cases ==

In Progress

== References ==  

Beginning Microsoft Visual Studio LightSwitch Development - http://books.google.com/books?id=x76L_kaTgdEC&pg=PA280&lpg=PA280&dq=business+logic+example+valid+data+example&source=bl&ots=GOfQ-7f4Hu&sig=4jOejZVligZOrvjBFRAT4-jy8DI&hl=en&sa=X&ei=mydYUt6qEOX54APu7IDgCQ&ved=0CFIQ6AEwBDgK#v=onepage&q=business%20logic%20example%20valid%20data%20example&f=false

== Remediation ==

The application/system must ensure that only "logically valid" data can accepted at any input point of the application or system.