# 4.10 Business Logic Testing

## [Business Logic Testing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/README)

## 4.10.1 [Test Business Logic Data Validation](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/01-Test_Business_Logic_Data_Validation)

* [ ] Identify data injection points.
* [ ] Validate that all checks are occurring on the back end and can’t be bypassed.
* [ ] Attempt to break the format of the expected data and analyze how the application is handling it.

**Evidence**:

```
​
```

## 4.10.2 [Test Ability to Forge Requests](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/02-Test_Ability_to_Forge_Requests)

* [ ] Review the project documentation looking for guessable, predictable, or hidden functionality of fields.
* [ ] Insert logically valid data in order to bypass normal business logic workflow.

**Evidence**:

```
​
```

## 4.10.3 [Test Integrity Checks](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/03-Test_Integrity_Checks)

* [ ] Review the project documentation for components of the system that move, store, or handle data.
* [ ] Determine what type of data is logically acceptable by the component and what types the system should guard against.
* [ ] Determine who should be allowed to modify or read that data in each component.
* [ ] Attempt to insert, update, or delete data values used by each component that should not be allowed per the business logic workflow.

**Evidence**:

```
​
```

## 4.10.4 [Test for Process Timing](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/04-Test_for_Process_Timing)

* [ ] Look for user inputs that could be used to enumerate hidden information by the attacker. (Login panel, password recovery, etc.)
* [ ] Send data to see if it takes more time or less depending of the values used.

**Evidence**:

```
​
```

## 4.10.5 [Test Number of Times a Function Can Be Used Limits](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/05-Test_Number_of_Times_a_Function_Can_Be_Used_Limits)

* [ ] Perform the same request as many times as possible until a rate limiting function is triggered. This can be applied to functions like "apply coupons", "login" or "recovery password."
* [ ] Identify functions that must set limits to the times they can be called.
* [ ] Assess if there is a logical limit set on the functions and if it is properly validated.

**Evidence**:

```
​
```

## 4.10.6 [Testing for the Circumvention of Work Flows](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/06-Testing_for_the_Circumvention_of_Work_Flows)

* [ ] Review the project documentation for methods to skip or go through steps in the application process in a different order from the intended business logic flow.
* [ ] Develop a misuse case and try to circumvent every logic flow identified.

**Evidence**:

```
​
```

## 4.10.7 [Test Defenses Against Application Misuse](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/07-Test_Defenses_Against_Application_Misuse)

* [ ] Review which tests had a different functionality based on aggressive input.
* [ ] Understand the defenses in place and verify if they are enough to protect the system against bypassing techniques.
  * [ ] Check if there are defenses against SQLI, XSS, RCE, malware file upload.

**Evidence**:

```
​
```

## 4.10.8 [Test Upload of Unexpected File Types](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/08-Test_Upload_of_Unexpected_File_Types)

* [ ] Study the applications logical requirements.
* [ ] Prepare a library of files that are “not approved” for upload that may contain files such as: jsp, exe, or HTML files containing script.
* [ ] In the application navigate to the file submission or upload mechanism.
* [ ] Submit the “not approved” file for upload and verify that they are properly prevented from uploading
* [ ] Check if the website only do file type check in client-side JavaScript
* [ ] Check if the website only check the file type by “Content-Type” in HTTP request.
* [ ] Check if the website only check by the file extension.
* [ ] Check if other uploaded files can be accessed directly by specified URL.
* [ ] Check if the uploaded file can include code or script injection.
* [ ] Check if there is any file path checking for uploaded files. Especially, hackers may compress files with specified path in ZIP so that the unzip files can be uploaded to intended path after uploading and unzip.

**Evidence**:

```
​
```

## 4.10.9 [Test Upload of Malicious Files](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/09-Test_Upload_of_Malicious_Files)

* [ ] Try to upload an EICAR file and try to access it.

```regex
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
```

**Evidence**:

```
​
```