Hello Everyone, welcome back to my story, in this section, i will give you about How to Business Logic Testing | Base on OWASP.
Summary
Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional methods. If an application’s authentication mechanism is developed with the intention of performing steps 1, 2, 3 in that specific order to authenticate a user. What happens if the user goes from step 1 straight to step 3? In this simplistic example, does the application provide access by failing open; deny access, or just error out with a 500 message?
There are many examples that can be made, the most frequently used being “thinking outside the conventional wisdom”. These types of vulnerabilities cannot be detected by vulnerability scanners and rely on the skill and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the most difficult to detect, and is usually application-specific, but at the same time, is usually one of the most costly to the company or organization, if exploited.
The classification of business logic flaws is still poorly studied; although exploitation of business flaws occurs frequently in real-world systems, and many applied vulnerability researchers are investigating them. The biggest focus is on web applications. There is debate within the community as to whether this problem is a completely new concept, or just a variation on familiar principles.
Testing of business logic flaws is similar to the test types used by functional testers that focus on logical or finite state testing. These types of tests require that security professionals think a bit differently, develop abused and misuse cases and use many of the testing techniques embraced by functional testers. 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.
Description of the Issue
Automated tools find it hard to understand context, hence it’s up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer’s intentions, and some creative “out-of-the-box” thinking can break the application’s logic. The first example starts with a simplistic parameter manipulation.
Example 1:
Suppose an e-commerce site allows users to select items to purchase, view a summary page and then tender the sale. What if an attacker was able to go back to the summary page, maintaining their same valid session and inject a lower cost for an item and complete the transaction, and then check out?
Example 2:
Suppose a users uses an online booking application with a voucher, which should only be used once, but can be used repeatedly.
Example 3:
Suppose there is a wifi provider company, every month there is a payment deadline. For example, the payment deadline is the 15th of the middle of the month, it turns out that if you make a payment at the beginning of the month, the price can be cut more and become cheaper.
There are 9 checklists in owasp for the control section for Business Logic Testing.
1. Test Business Logic Data Validation
Applications must ensure that only logically valid data can be entered at the front end as well as directly into the server side of the system application. Only verifying data locally can make the application vulnerable to server injection through proxies or during handover with other systems.
Example, How to Test :
2. Test Ability to Forge Requests
Request forgery is a method that attackers use to circumvent front end GUI applications to directly submit information for back end processing. The attacker’s goal is to send HTTP POST/GET requests through an eavesdropping proxy with data values that are not supported, guarded, or expected by the application’s business logic. Some examples of forged requests include exploiting guessable or predictable parameters or exposing “hidden” features and functionality such as enabling debugging or displaying special screens or windows that are very useful during development but can leak information or bypass business logic.
Vulnerabilities related to the ability to spoof requests are unique to each application and differ from business logic data validation because the focus is on breaking the business logic workflow.
Example, How to Test :
3. Test Integrity Checks
Many applications are designed to display different fields depending on the user of situation by leaving some inputs hidden. However, in many cases it is possible to submit values hidden field values to the server using a proxy. In these cases the server-side controls must be smart enough to perform relational or server-side edits to ensure that the proper data is allowed to the server based on user and application specific business logic.
Example, How to Test :
4. Test for Process Timing
It is possible that attackers can gather information on an application by monitoring the time it takes to complete a task or give a respond. Additionally, attackers may be able to manipulate and break designed business process flows by simply keeping active sessions open and not submitting their transactions in the “expected” time frame.
Process timing logic vulnerabilities is unique in that these manual misuse cases should be created considering execution and transaction timing that are application/system specific.
Example, How to Test :
5. Test Number of Times a Function Can Be Used Limits
Many of the problems that applications are solving require limits to the number of times a function can be used or action can be executed. Applications must be “smart enough” to not allow the user to exceed their limit on the use of these functions since in many cases each time the function is used the user may gain some type of benefit that must be accounted for to properly compensate the owner. For example: an eCommerce site may only allow a users apply a discount once per transaction, or some applications may be on a subscription plan and only allow users to download three complete documents monthly.
Vulnerabilities related to testing for the function limits are application specific and misuse cases must be created that strive to exercise parts of the application/functions/ or actions more than the allowable number of times.
Attackers may be able to circumvent the business logic and execute a function more times than “allowable” exploiting the application for personal gain.
Example, How to Test :
6. Testing for the Circumvention of Work Flows
The application’s business logic must require that the user complete specific steps in the correct/specific order and if the workflow is terminated without correctly completing, all actions and spawned actions are “rolled back” or canceled. Vulnerabilities related to the circumvention of workflows or bypassing the correct business logic workflow are unique in that they are very application/system specific and careful manual misuse cases must be developed using requirements and use cases.
The applications business process must have checks to ensure that the user’s transactions/actions are proceeding in the correct/acceptable order and if a transaction triggers some sort of action, that action will be “rolled back” and removed if the transaction is not successfully completed.
Example, How to Test :
7. Test Defenses Against Application Misuse
The misuse and invalid use of of valid functionality can identify attacks attempting to enumerate the web application, identify weaknesses, and exploit vulnerabilities. Tests should be undertaken to determine whether there are application-layer defensive mechanisms in place to protect the application.
The lack of active defenses allows an attacker to hunt for vulnerabilities without any recourse. The application’s owner will thus not know their application is under attack.
Example, How to Test :
8. Test Upload of Unexpected File Types
Many applications’ business processes allow for the upload and manipulation of data that is submitted via files. But the business process must check the files and only allow certain “approved” file types. Deciding what files are “approved” is determined by the business logic and is application/system specific. The risk in that by allowing users to upload files, attackers may submit an unexpected file type that that could be executed and adversely impact the application or system through attacks that may deface the web site, perform remote commands, browse the system files, browse the local resources, attack other servers, or exploit the local vulnerabilities, just to name a few.
Vulnerabilities related to the upload of unexpected file types is unique in that the upload should quickly reject a file if it does not have a specific extension. Additionally, this is different from uploading malicious files in that in most cases an incorrect file format may not by it self be inherently “malicious” but may be detrimental to the saved data. For example if an application accepts Windows Excel files, if an similar database file is uploaded it may be read but data extracted my be moved to incorrect locations.
Example, How to Test :
9. Test Upload of Malicious Files
Many application’s business processes allow users to upload data to them. Although input validation is widely understood for text-based input fields, it is more complicated to implement when files are accepted. Although many sites implement simple restrictions based on a list of permitted (or blocked) extensions, this is not sufficient to prevent attackers from uploading legitimate file types that have malicious contents.
Vulnerabilities related to the uploading of malicious files is unique in that these “malicious” files can easily be rejected through including business logic that will scan files during the upload process and reject those perceived as malicious. Additionally, this is different from uploading unexpected files in that while the file type may be accepted the file may still be malicious to the system.
Finally, “malicious” means different things to different systems, for example malicious files that may exploit SQL server vulnerabilities may not be considered as “malicious” in an environment using a NoSQL data store.
Example, How to Test :
