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.
176<br />
Web Application Penetration Testing<br />
path=/; domain=example.com; httponly<br />
Location: private/<br />
X-Content-Type-Options: nosniff<br />
X-XSS-Protection: 1; mode=block<br />
X-Frame-Options: SAMEORIGIN<br />
Content-Length: 0<br />
Keep-Alive: timeout=1, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html<br />
----------------------------------------------------------<br />
http: /example.com/private<br />
GET /private HTTP/1.1<br />
Host: example.com<br />
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;<br />
rv:25.0) Gecko/20100101 Firefox/25.0<br />
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br />
Accept-Language: en-US,en;q=0.5<br />
Accept-Encoding: gzip, deflate<br />
Referer: https: /secure.example.com/login<br />
Cookie: JSESSIONID=BD99F321233AF69593ED-<br />
F52B123B5BDA;<br />
Connection: keep-alive<br />
HTTP/1.1 200 OK<br />
Cache-Control: no-store<br />
Pragma: no-cache<br />
Expires: 0<br />
Content-Type: text/html;charset=UTF-8<br />
Content-Length: 730<br />
Date: Tue, 25 Dec 2013 00:00:00 GMT<br />
----------------------------------------------------------<br />
Tools<br />
• [5] curl can be used to check manually for pages<br />
References<br />
OWASP Resources<br />
• [1] OWASP Testing Guide - Testing for Weak SSL/TLS Ciphers,<br />
Insufficient Transport Layer Protection (OTG-CRYPST-001)<br />
• [2] OWASP TOP 10 2010 - Insufficient Transport Layer<br />
Protection<br />
• [3] OWASP TOP 10 2013 - Sensitive Data Exposure<br />
• [4] OWASP ASVS v1.1 - V10 Communication Security Verification<br />
Requirements<br />
• [6] OWASP Testing Guide - Testing for Cookies attributes<br />
(OTG-SESS-002)<br />
Testing for business logic<br />
Summary<br />
Testing for business logic flaws in a multi-functional dynamic<br />
web application requires thinking in unconventional methods.<br />
If an application’s authentication mechanism is developed with<br />
the intention of performing steps 1, 2, 3 in that specific order to<br />
authenticate a user. What happens if the user goes from step 1<br />
straight to step 3? In this simplistic example, does the application<br />
provide access by failing open; deny access, or just error out<br />
with a 500 message?<br />
There are many examples that can be made, but the one constant<br />
lesson is “think outside of conventional wisdom”. This type<br />
of vulnerability cannot be detected by a vulnerability scanner<br />
and relies upon the skills and creativity of the penetration tester.<br />
In addition, this type of vulnerability is usually one of the hardest<br />
to detect, and usually application specific but, at the same<br />
time, usually one of the most detrimental to the application, if<br />
exploited.<br />
The classification of business logic flaws has been under-studied;<br />
although exploitation of business flaws frequently happens<br />
in real-world systems, and many applied vulnerability researchers<br />
investigate them. The greatest focus is in web applications.<br />
There is debate within the community about whether these<br />
problems represent particularly new concepts, or if they are variations<br />
of well-known principles.<br />
Testing of business logic flaws is similar to the test types used<br />
by functional testers that focus on logical or finite state testing.<br />
These types of tests require that security professionals think a<br />
bit differently, develop abused and misuse cases and use many<br />
of the testing techniques embraced by functional testers. Automation<br />
of business logic abuse cases is not possible and remains<br />
a manual art relying on the skills of the tester and their knowledge<br />
of the complete business process and its rules.<br />
Business Limits and Restrictions<br />
Consider the rules for the business function being provided by<br />
the application. Are there any limits or restrictions on people’s<br />
behavior? Then consider whether the application enforces those<br />
rules. It’s generally pretty easy to identify the test and analysis<br />
cases to verify the application if you’re familiar with the business.<br />
If you are a third-party tester, then you’re going to have to<br />
use your common sense and ask the business if different operations<br />
should be allowed by the application.<br />
Sometimes, in very complex applications, the tester will not have<br />
a full understanding of every aspect of the application initially.<br />
In these situations, it is best to have the client walk the tester<br />
through the application, so that they may gain a better understanding<br />
of the limits and intended functionality of the application,<br />
before the actual test begins. Additionally, having a direct<br />
line to the developers (if possible) during testing will help out<br />
greatly, if any questions arise regarding the application’s functionality.<br />
Description of the Issue<br />
Automated tools find it hard to understand context, hence it’s up<br />
to a person to perform these kinds of tests. The following two<br />
examples will illustrate how understanding the functionality of<br />
the application, the developer’s intentions, and some creative<br />
“out-of-the-box” thinking can break the application’s logic. The<br />
first example starts with a simplistic parameter manipulation,<br />
whereas the second is a real world example of a multi-step process<br />
leading to completely subvert the application.