10.0 Business Logic Testing
Last updated
Last updated
10.1 Test Business Logic Data Validation
Review the project documentation and use exploratory testing looking for data entry points or hand off points between systems or software.
Once found try to insert logically invalid data into the application/system. Specific Testing Method:
Perform front-end GUI Functional Valid testing on the application to ensure that the only “valid” values are accepted.
Using an intercepting proxy observe the HTTP POST/GET looking for places that variables such as cost and quality are passed. Specifically, look for “hand-offs” between application/systems that may be possible injection or tamper points.
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.
10.2 Test Ability to Forge Requests
Some examples of forged requests include exploiting guessable or predictable parameters or expose “hidden” features and functionality such as enabling debugging or presenting special screens or windows that are very useful during development but may leak information or bypass the business logic.
Example 1
Suppose an e-commerce theater site allows users to select their ticket, apply a onetime 10% Senior discount on the entire sale, view the subtotal and tender the sale. If an attacker is able to see through a proxy that the application has a hidden field (of 1 or 0) used by the business logic to determine if a discount has been taken or not. The attacker is then able to submit the 1 or “no discount has been taken” value multiple times to take advantage of the same discount multiple times.
Example 2
Suppose an online video game pays out tokens for points scored for finding pirates treasure and pirates and for each level completed. These tokens can later be that can later be exchanged for prizes. Additionally each level’s points have a multiplier value equal to the level. If an attacker was able to see through a proxy that the application has a hidden field used during development and testing to quickly get to the highest levels of the game they could quickly get to the highest levels and accumulate unearned points quickly.
Also, if an attacker was able to see through a proxy that the application has a hidden field used during development and testing to enabled a log that indicated where other online players, or hidden treasure were in relation to the attacker, they would then be able to quickly go to these locations and score points.
Through Identifying Guessable Values
Using an intercepting proxy observe the HTTP POST/GET looking for some indication that values are incrementing at a regular interval or are easily guessable.
If it is found that some value is guessable this value may be changed and one may gain unexpected visibility.
Through Identifying Hidden Options
Using an intercepting proxy observe the HTTP POST/GET looking for some indication of hidden features such as debug that can be switched on or activated.
If any are found try to guess and change these values to get a different application response or behavior.
10.3 Test Integrity Checks
Example 1
Imagine an ASP.NET application GUI application that only allows the admin user to change the password for other users in the system. The admin user will see the username and password fields to enter a username and password while other users will not see either field. However, if a non admin user submits information in the username and password field through a proxy they may be able to “trick” the server into believing that the request has come from an admin user and change password of other users.
Example 2
Most web applications have dropdown lists making it easy for the user to quickly select their state, month of birth, etc. Suppose a Project Management application allowed users to login and depending on their privileges presented them with a drop down list of projects they have access to. What happens if an attacker finds the name of another project that they should not have access to and submits the information via a proxy. Will the application give access to the project? They should not have access even though they skipped an authorization business logic check.
Example 3
Suppose the motor vehicle administration system required an employee initially verify each citizens documentation and information when they issue an identification or driver’s license. At this point the business process has created data with a high level of integrity as the integrity of submitted data is checked by the application. Now suppose the application is moved to the Internet so employees can log on for full service or citizens can log on for a reduced self-service application to update certain information. At this point an attacker may be able to use an intercepting proxy to add or update data that they should not have access to and they could destroy the integrity of the data by stating that the citizen was not married but supplying data for a spouse’s name. This type of inserting or updating of unverified data destroys the data integrity and might have been prevented if the business process logic was followed.
Example 4
Many systems include logging for auditing and troubleshooting purposes. But, how good/valid is the information in these logs? Can they be manipulated by attackers either intentionally or accidentally having their integrity destroyed?
Test Objectives
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.
How to Test
Specific Testing Method 1
Using a proxy capture HTTP traffic looking for hidden fields.
If a hidden field is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.
Specific Testing Method 2
Using a proxy capture HTTP traffic looking for a place to insert information into areas of the application that are non-editable.
If it is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.
Specific Testing Method 3
List components of the application or system that could be impacted, for example logs or databases.
For each component identified, try to read, edit or remove its information. For example log files should be identified and Testers should try to manipulate the data/information being collected.
10.4 Test for Process Timing
Example 1
Video gambling/slot machines may take longer to process a transaction just prior to a large payout. This would allow astute gamblers to gamble minimum amounts until they see the long process time which would then prompt them to bet the maximum.
Example 2
Many system log on processes ask for the username and password. If you look closely you may be able to see that entering an invalid username and invalid user password takes more time to return an error than entering a valid username and invalid user password. This may allow the attacker to know if they have a valid username and not need to rely on the GUI message.
Figure 4.10.4-1: Example Control Flow of Login Form
Example 3
Most Arenas or travel agencies have ticketing applications that allow users to purchase tickets and reserve seats. When the user requests the tickets seats are locked or reserved pending payment. What if an attacker keeps reserving seats but not checking out? Will the seats be released, or will no tickets be sold? Some ticket vendors now only allow users 5 minutes to complete a transaction or the transaction is invalidated.
Example 4
Suppose a precious metals e-commerce site allows users to make purchases with a price quote based on market price at the time they log on. What if an attacker logs on and places an order but does not complete the transaction until later in the day only of the price of the metals goes up? Will the attacker get the initial lower price?
Test Objectives
Review the project documentation for system functionality that may be impacted by time.
Develop and execute misuse cases.
How to Test
The tester should identify which processes are dependent on time, whether it was a window for a task to be completed, or if it was execution time between two processes that could allow the bypass of certain controls.
Following that, it is best to automate the requests that will abuse the above discovered processes, as tools are better fit to analyze the timing and are more precise than manual testing. If this is not possible, manual testing could still be used.
The tester should draw a diagram of how the process flows, the injection points, and prepare the requests before hand to launch them at the vulnerable processes. Once done, close analysis should be done to identify differences in the process execution, and if the process is misbehaving against the agreed upon business logic.
10.5 Test Number of Times a Function Can Be Used Limits
Example
Suppose an eCommerce site allows users to take advantage of any one of many discounts on their total purchase and then proceed to checkout and tendering. What happens of the attacker navigates back to the discounts page after taking and applying the one “allowable” discount? Can they take advantage of another discount? Can they take advantage of the same discount multiple times?
Test Objectives
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.
How to Test
Review the project documentation and use exploratory testing looking for functions or features in the application or system that should not be executed more that a single time or specified number of times during the business logic workflow.
For each of the functions and features found that should only be executed a single time or specified number of times during the business logic workflow, develop abuse/misuse cases that may allow a user to execute more than the allowable number of times. For example, can a user navigate back and forth through the pages multiple times executing a function that should only execute once? or can a user load and unload shopping carts allowing for additional discounts.
10.6 Testing for the Circumvention of Work Flows
Example 1
Many of us receive so type of “club/loyalty points” for purchases from grocery stores and gas stations. Suppose a user was able to start a transaction linked to their account and then after points have been added to their club/loyalty account cancel out of the transaction or remove items from their “basket” and tender. In this case the system either should not apply points/credits to the account until it is tendered or points/credits should be “rolled back” if the point/credit increment does not match the final tender. With this in mind, an attacker may start transactions and cancel them to build their point levels without actually buy anything.
Example 2
An electronic bulletin board system may be designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on a deny list is found in the user entered text 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/deny list since on edit the posting is never compared again. Keeping this in mind, attackers may open an initial blank or minimal discussion then add in whatever they like as an update.
Test Objectives
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.
How to Test
Testing Method 1
Start a transaction going through the application past the points that triggers credits/points to the users account.
Cancel out of the transaction or reduce the final tender so that the point values should be decreased and check the points/ credit system to ensure that the proper points/credits were recorded.
Testing Method 2
On a content management or bulletin board system enter and save valid initial text or values.
Then try to append, edit and remove data that would leave the existing data in an invalid state or with invalid values to ensure that the user is not allowed to save the incorrect information. Some “invalid” data or information may be specific words (profanity) or specific topics (such as political issues).
10.7 Test Defenses Against Application Misuse
Example
An authenticated user undertakes the following (unlikely) sequence of actions:
Attempt to access a file ID their roles is not permitted to download
Substitutes a single tick ' instead of the file ID number
Alters a GET request to a POST
Adds an extra parameter
Duplicates a parameter name/value pair
The application is monitoring for misuse and responds after the 5th event with extremely high confidence the user is an attacker. For example the application:
Disables critical functionality
Enables additional authentication steps to the remaining functionality
Adds time-delays into every request-response cycle
Begins to record additional data about the user’s interactions (e.g. sanitized HTTP request headers, bodies and response bodies)
If the application does not respond in any way and the attacker can continue to abuse functionality and submit clearly malicious content at the application, the application has failed this test case. In practice the discrete example actions in the example above are unlikely to occur like that. It is much more probable that a fuzzing tool is used to identify weaknesses in each parameter in turn. This is what a security tester will have undertaken too.
Test Objectives
Generate notes from all tests conducted against the system.
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.
How to Test
This test is unusual in that the result can be drawn from all the other tests performed against the web application. While performing all the other tests, take note of measures that might indicate the application has in-built self-defense:
Changed responses
Blocked requests
Actions that log a user out or lock their account
These may only be localized. Common localized (per function) defenses are:
Rejecting input containing certain characters
Locking out an account temporarily after a number of authentication failures
Localized security controls are not sufficient. There are often no defenses against general mis-use such as:
Forced browsing
Bypassing presentation layer input validation
Multiple access control errors
Additional, duplicated or missing parameter names
Multiple input validation or business logic verification failures with values that cannot be the result user mistakes or typos
Structured data (e.g. JSON, XML) of an invalid format is received
Blatant cross-site scripting or SQL injection payloads are received
Utilizing the application faster than would be possible without automation tools
Change in continental geo-location of a user
Change of user agent
Accessing a multi-stage business process in the wrong order
Large number of, or high rate of use of, application-specific functionality (e.g. voucher code submission, failed credit card payments, file uploads, file downloads, log outs, etc).
These defenses work best in authenticated parts of the application, although rate of creation of new accounts or accessing content (e.g. to scrape information) can be of use in public areas.
Not all the above need to be monitored by the application, but there is a problem if none of them are. By testing the web application, doing the above type of actions, was any response taken against the tester? If not, the tester should report that the application appears to have no application-wide active defenses against misuse. Note it is sometimes possible that all responses to attack detection are silent to the user (e.g. logging changes, increased monitoring, alerts to administrators and and request proxying), so confidence in this finding cannot be guaranteed. In practice, very few applications (or related infrastructure such as a web application firewall) are detecting these types of misuse.
10.8 Test Upload of Unexpected File Types
How to Test
Specific Testing Method
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.
10.9 Test Upload of Malicious Files
Test Objectives
Identify the file upload functionality.
Review the project documentation to identify what file types are considered acceptable, and what types would be considered dangerous or malicious.
If documentation is not available then consider what would be appropriate based on the purpose of the application.
Determine how the uploaded files are processed.
Obtain or create a set of malicious files for testing.
Try to upload the malicious files to the application and determine whether it is accepted and processed.
How to Test
Malicious File Types
The simplest checks that an application can do are to determine that only trusted types of files can be uploaded.
Web Shells
If the server is configured to execute code, then it may be possible to obtain command execution on the server by uploading a file known as a web shell, which allows you to execute arbitrary code or operating system commands. In order for this attack to be successful, the file needs to be uploaded inside the webroot, and the server must be configured to execute the code.
Uploading this kind of shell onto an Internet facing server is dangerous, because it allows anyone who knows (or guesses) the location of the shell to execute code on the server. A number of techniques can be used to protect the shell from unauthorised access, such as:
Uploading the shell with a randomly generated name.
Password protecting the shell.
Implementing IP based restrictions on the shell.
Remember to remove the shell when you are done.
The example below shows a simple PHP based shell, that executes operating system commands passed to it in a GET parameter, and can only be accessed from a specific IP address:
<?php if ($_SERVER['REMOTE_HOST'] === "FIXME") { // Set your IP address here if(isset($_REQUEST['cmd'])){ $cmd = ($_REQUEST['cmd']); echo "<pre>\\n"; system($cmd); echo "</pre>"; } } ?>
Once the shell is uploaded (with a random name), you can execute operating system commands by passing them in the cmd GET parameter:
https://example.org/7sna8uuorvcx3x4fx.php?cmd=cat+/etc/passwd
Filter Evasion
The first step is to determine what the filters are allowing or blocking, and where they are implemented. If the restrictions are performed on the client-side using JavaScript, then they can be trivially bypassed with an intercepting proxy.
If the filtering is performed on the server-side, then various techniques can be attempted to bypass it, including:
Change the value of Content-Type as image/jpeg in HTTP request.
Change the extensions to a less common extension, such as file.php5, file.shtml, file.asa, file.jsp, file.jspx, file.aspx, file.asp, file.phtml, file.cshtml
Change the capitalisation of the extension, such as file.PhP or file.AspX
If the request includes multiple file names, change them to different values.
Using special trailing characters such as spaces, dots or null characters such as file.asp..., file.php;jpg, file.asp%00.jpg, 1.jpg%00.php
In badly configured versions of nginx, uploading a file as test.jpg/x.php may allow it to be executed as x.php.
Malicious File Contents
Once the file type has been validated, it is important to also ensure that the contents of the file are safe. This is significantly harder to do, as the steps required will vary depending on the types of file that are permitted.
Malware
Applications should generally scan uploaded files with anti-malware software to ensure that they do not contain anything malicious. The easiest way to test for this is using the EICAR test file, which is an safe file that is flagged as malicious by all anti-malware software.
Depending on the type of application, it may be necessary to test for other dangerous file types, such as Office documents containing malicious macros. Tools such as the Metasploit Framework and the Social Engineer Toolkit (SET) can be used to generate malicious files for various formats.
When this file is uploaded, it should be detected and quarantined or deleted by the application. Depending on how the application processes the file, it may not be obvious whether this has taken place.
Archive Directory Traversal
If the application extracts archives (such as Zip files), then it may be possible to write to unintended locations using directory traversal. This can be exploited by uploading a malicious zip file that contains paths that traverse the file system using sequences such as ..\\..\\..\\..\\shell.php. This technique is discussed further in the snyk advisory.
Zip Bombs
A Zip bomb (more generally known as a decompression bomb) is an archive file that contains a large volume of data. It’s intended to cause a denial of service by exhausting the disk space or memory of the target system that tries to extract the archive. Note that although the Zip format is the most example of this, other formats are also affected, including gzip (which is frequently used to compress data in transit).
At its simplest level, a Zip bomb can be created by compressing a large file consisting of a single character. The example below shows how to create a 1MB file that will decompress to 1GB:
dd if=/dev/zero bs=1M count=1024 | zip -9 > bomb.zip
There are a number of methods that can be used to achieve much higher compression ratios, including multiple levels of compression, abusing the Zip format and quines (which are archives that contain a copy of themselves, causing infinite recursion).
A successful Zip bomb attack will result in a denial of service, and can also lead to increased costs if an auto-scaling cloud platform is used. Do not carry out this kind of attack unless you have considered these risks and have written approval to do so.
XML Files
XML files have a number of potential vulnerabilities such as XML eXternal Entities (XXE) and denial of service attacks such as the billion laughs attack.
These are discussed further in the Testing for XML Injection guide.
Other File Formats
Many other file formats also have specific security concerns that need to be taken into account, such as:
CSV files may allow CSV injection attacks.
Office files may contain malicious macros or PowerShell code.
PDFs may contain malicious JavaScript.
The permitted file formats should be carefully reviewed for potentially dangerous functionality, and where possible attempts should be made to exploit this during testing.
Source Code Review
When there is file upload feature supported, the following API/methods are common to be found in the source code.
Java: new file, import, upload, getFileName, Download, getOutputString
C/C++: open, fopen
PHP: move_uploaded_file(), Readfile, file_put_contents(), file(), parse_ini_file(), copy(), fopen(), include(), require()