4.0

177
Web Application Penetration Testing
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:
Holding/locking resources and keeping others from purchases
these items online may result in attackers purchasing items at a
lower price. The countermeasure to this problem is to implement
timeouts and mechanisms to ensure that only the correct price
can be charged.
Example 3:
What if a user was able to start a transaction linked to their club/
loyalty account and then after points have been added to their
account cancel out of the transaction? Will the points/credits still
be applied to their account?
Business Logic Test Cases
Every application has a different business process, application
specific logic and can be manipulated in an infinite number of
combinations. This section provides some common examples of
business logic issues but in no way a complete list of all issues.
Business Logic exploits can be broken into the following categories:
4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)
In business logic data validation testing, we verify that the application
does not allow users to insert “unvalidated” data into
the system/application. This is important because without this
safeguard attackers may be able to insert “unvalidated” data/information
into the application/system at “handoff points” where
the application/system believes that the data/information is
“good” and has been valid since the “entry points” performed
data validation as part of the business logic workflow.
4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)
In forged and predictive parameter request testing, we verify
that the application does not allow users to submit or alter data
to any component of the system that they should not have access
to, are accessing at that particular time or in that particular manner.
This is important because without this safeguard attackers
may be able to “fool/trick” the application into letting them into
sections of thwe application of system that they should not be
allowed in at that particular time, thus circumventing the applications
business logic workflow.
4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)
In integrity check and tamper evidence testing, we verify that the
application does not allow users to destroy the integrity of any
part of the system or its data. This is important because without
these safe guards attackers may break the business logic workflow
and change of compromise the application/system data or
cover up actions by altering information including log files.
4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)
In process timing testing, we verify that the application does not
allow users to manipulate a system or guess its behavior based
on input or output timing. This is important because without this
safeguard in place attackers may be able to monitor processing
time and determine outputs based on timing, or circumvent the
application’s business logic by not completing transactions or
actions in a timely manner.
4.12.5 Test Number of Times a Function Can be Used Limits
(OTG-BUSLOGIC-005)
In function limit testing, we verify that the application does not
allow users to exercise portions of the application or its functions
more times than required by the business logic workflow.
This is important because without this safeguard in place attackers
may be able to use a function or portion of the application
more times than permissible per the business logic to gain additional
benefits.
4.12.6 Testing for the Circumvention of Work Flows (OTG-BUS-
LOGIC-006)
In circumventing workflow and bypassing correct sequence
testing, we verify that the application does not allow users to
perform actions outside of the “approved/required” business
process flow. This is important because without this safeguard
in place attackers may be able to bypass or circumvent workflows
and “checks” allowing them to prematurely enter or skip
“required” sections of the application potentially allowing the
action/transaction to be completed without successfully completing
the entire business process, leaving the system with incomplete
backend tracking information.
4.12.7 Test Defenses Against Application Mis-use (OTG-BUS-
LOGIC-007)
In application mis-use testing, we verify that the application
does not allow users to manipulate the application in an unintended
manner.
4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOG-
IC-008)
In unexpected file upload testing, we verify that the application
does not allow users to upload file types that the system is not
expecting or wanted per the business logic requirements. This is
important because without these safeguards in place attackers
may be able to submit unexpected files such as .exe or .php that
could be saved to the system and then executed against the application
or system.
4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)
In malicious file upload testing, we verify that the application
does not allow users to upload files to the system that are malicious
or potentially malicious to the system security. This is
important because without these safeguards in place attackers
may be able to upload files to the system that may spread viruses,
malware or even exploits such as shellcode when executed.
Tools
While there are tools for testing and verifying that business processes
are functioning correctly in valid situations these tools
are incapable of detecting logical vulnerabilities. For example,
tools have no means of detecting if a user is able to circumvent
the business process flow through editing parameters, predicting
resource names or escalating privileges to access restricted
resources nor do they have any mechanism to help the human