1BO4r2U

177 178
Web Application Penetration Testing
Web Application Penetration Testing
• Defying Logic: Theory, Design, and Implementation of Complex
Systems for Testing Application Logic - http://www.slideshare.
net/RafalLos/defying-logic-business-logic-testing-with-automation
• Prevent application logic attacks with sound app security practices
- http://searchappsecurity.techtarget.com/qna/0,289202,sid92_
gci1213424,00.html?bucket=NEWS&topic=302570
• Real-Life Example of a ‘Business Logic Defect - http://h30501.
www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581
• Software Testing Lifecycle - http://softwaretestingfundamentals.com/software-testing-life-cycle/
• Top 10 Business Logic Attack Vectors Attacking and Exploiting
Business Application Assets and Flaws – Vulnerability Detection
to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/
and http://www.ntobjectives.com/
files/Business_Logic_White_Paper.pdf
Books
• The Decision Model: A Business Logic Framework Linking Business
and Technology, By Barbara Von Halle, Larry Goldberg, Published
by CRC Press, ISBN1420082817 (2010)
Test business logic data validation
(OTG-BUSLOGIC-001)
Summary
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 cannot 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 semantics
(is the value 9 digits long, not negative and not all 0’s)
for the data entered, but there are logic considerations also.
SSNs are grouped and categorized. Is this person on a death file?
Are they from a certain part of the country?
Vulnerabilities related to business data validation is unique in that
they are application specific and different from the vulnerabilities
related to forging requests in that they are more concerned about
logical data as opposed to simply breaking the business logic
workflow.
The front end and the back end 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 circumstances.
Examples
Example 1
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?
Example 2
Many credit card systems are now downloading account balances
nightly so the customers can check out more quickly for amounts
under a certain value. The inverse is also true. I
f I pay my credit card off in the morning I may not be able to use the
available credit in the evening. Another example may be if I use my
credit card at multiple locations very quickly it may be possible to
exceed my limit if the systems are basing decisions on last night’s
data.
How to Test
Generic Test Method
• 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 of 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 them.
Related Test Cases
• All Input Validation test cases
• Testing for Account Enumeration and Guessable User Account
(OTG-IDENT-004)
• Testing for Bypassing Session Management Schema (OTG-
SESS-001)
• Testing for Exposed Session Variables (OTG-SESS-004)
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.
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=4jOejZVlig-
ZOrvjBFRAT4-jy8DI&hl=en&sa=X&ei=mydYUt6qEOX54A-
Pu7IDgCQ&ved=0CFIQ6AEwBDgK#v=onepage&q=business%20
logic%20example%20valid%20data%20example&f=false
Remediation
The application/system must ensure that only “logically valid”
data is accepted at all input and hand off points of the application
or system and data is not simply trusted once it has entered the
system.
Test Ability to forge requests
(OTG-BUSLOGIC-002)
Summary
Forging requests is a method that attackers use to circumvent the
front end GUI application to directly submit information for back
end processing. The goal of the attacker is to send HTTP POST/
GET requests through an intercepting proxy with data values that
is not supported, guarded against or expected by the applications
business logic. 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.
Vulnerabilities related to the ability to forge requests is unique to
each application and different from business logic data validation
in that it s focus is on breaking the business logic workflow.
Applications should have logic checks in place to prevent the system
from accepting forged requests that may allow attackers the
opportunity to exploit the business logic, process, or flow of the
application. Request forgery is nothing new; the attacker uses an
intercepting proxy to send HTTP POST/GET requests to the application.
Through request forgeries attackers may be able to circumvent
the business logic or process by finding, predicting and
manipulating parameters to make the application think a process
or task has or has not taken place.
Also, forged requests may allow subvention of programmatic or
business logic flow by invoking “hidden” features or functionality
such as debugging initially used by developers and testers
sometimes referred to as an ”Easter egg”. “An Easter egg is an
intentional inside joke, hidden message, or feature in a work such
as a computer program, movie, book, or crossword. According to
game designer Warren Robinett, the term was coined at Atari by
personnel who were alerted to the presence of a secret message
which had been hidden by Robinett in his already widely distributed
game, Adventure. The name has been said to evoke the idea of
a traditional Easter egg hunt.” http://en.wikipedia.org/wiki/Easter_egg_(media)
Examples
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.
How to Test
Generic Testing Method
• Review the project documentation and use exploratory testing
looking for guessable, predictable or hidden functionality of fields.
• Once found try to insert logically valid data into the application/
system allowing the user go through the application/system
against the normal busineess logic workflow.
Specific Testing Method 1
• 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.
Specific Testing Method 2
• 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.