4.0
1NSchAb
1NSchAb
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
181<br />
Web Application Penetration Testing<br />
Example 2<br />
Suppose an online video game pays out tokens for points scored<br />
for finding pirates treasure and pirates and for each level completed.<br />
These tokens can later be that can later be exchanged<br />
for prizes. Additionally each level’s points have a multiplier value<br />
equal to the level. If an attacker was able to see through a proxy<br />
that the application has a hidden field used during development<br />
and testing to quickly get to the highest levels of the game they<br />
could quickly get to the highest levels and accumulate unearned<br />
points quickly.<br />
Also, if an attacker was able to see through a proxy that the application<br />
has a hidden field used during development and testing<br />
to enabled a log that indicated where other online players, or hidden<br />
treasure were in relation to the attacker, they would then be<br />
able to quickly go to these locations and score points.<br />
How to Test<br />
Generic Testing Method<br />
• Review the project documentation and use exploratory testing<br />
looking for guessable, predictable or hidden functionality of<br />
fields.<br />
• Once found try to insert logically valid data into the application/<br />
system allowing the user go through the application/system<br />
against the normal busineess logic workflow.<br />
Specific Testing Method 1<br />
• Using an intercepting proxy observe the HTTP POST/GET<br />
looking for some indication that values are incrementing at a<br />
regular interval or are easily guessable.<br />
• If it is found that some value is guessable this value may be<br />
changed and one may gain unexpected visibility.<br />
Specific Testing Method 2<br />
• Using an intercepting proxy observe the HTTP POST/GET<br />
looking for some indication of hidden features such as debug<br />
that can be switched on or activated.<br />
• If any are found try to guess and change these values to get a<br />
different application response or behavior.<br />
Related Test Cases<br />
Testing for Exposed Session Variables (OTG-SESS-004)<br />
Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)<br />
Testing for Account Enumeration and Guessable User Account<br />
(OTG-IDENT-004)<br />
Tools<br />
OWASP Zed Attack Proxy (ZAP) - https://www.owasp.org<br />
index.php/OWASP_Zed_Attack_Proxy_Project<br />
ZAP is an easy to use integrated penetration testing tool for<br />
finding vulnerabilities in web applications. It is designed to be<br />
used by people with a wide range of security experience and as<br />
such is ideal for developers and functional testers who are new<br />
to penetration testing. ZAP provides automated scanners as<br />
well as a set of tools that allow you to find security vulnerabilities<br />
manually.<br />
References<br />
Cross Site Request Forgery - Legitimizing Forged Requests<br />
http://fragilesecurity.blogspot.com/2012/11/cross-siterequest-forgery-legitimazing.html<br />
Debugging features which remain present in the final game<br />
http://glitchcity.info/wiki/index.php/List_of_video_games_<br />
with_debugging_features#Debugging_features_which_<br />
remain_present_in_the_final_game<br />
Easter egg - http://en.wikipedia.org/wiki/Easter_egg_(media)<br />
Top 10 Software Easter Eggs - http://lifehacker.com/371083/<br />
top-10-software-easter-eggs<br />
Remediation<br />
The application must be smart enough and designed with business<br />
logic that will prevent attackers from predicting and manipulating<br />
parameters to subvert programmatic or business logic<br />
flow, or exploiting hidden/undocumented functionality such as<br />
debugging.<br />
Test integrity checks (OTG-BUSLOGIC-003)<br />
Summary<br />
Many applications are designed to display different fields depending<br />
on the user of situation by leaving some inputs hidden.<br />
However, in many cases it is possible to submit values hidden<br />
field values to the server using a proxy. In these cases the server<br />
side controls must be smart enough to perform relational or<br />
server side edits to ensure that the proper data is allowed to the<br />
server based on user and application specific business logic.<br />
Additionally, the application must not depend on non-editable<br />
controls, drop-down menus or hidden fields for business logic<br />
processing because these fields remain non-editable only in the<br />
context of the browsers. Users may be able to edit their values<br />
using proxy editor tools and try to manipulate business logic.<br />
If the application exposes values related to business rules like<br />
quantity, etc. as non-editable fields it must maintain a copy on<br />
the server side and use the same for business logic processing.<br />
Finally, aside application/system data, log systems must be secured<br />
to prevent read, writing and updating.<br />
Business logic integrity check vulnerabilities is unique in that<br />
these misuse cases are application specific and if users are able<br />
to make changes one should only be able to write or update/edit<br />
specific artifacts at specific times per the business process logic.<br />
The application must be smart enough to check for relational<br />
edits and not allow users to submit information directly to the<br />
server that is not valid, trusted because it came from a non-editable<br />
controls or the user is not authorized to submit through<br />
the front end. Additionally, system artifacts such as logs must be<br />
“protected” from unauthorized read, writing and removal.<br />
Example