1BO4r2U

173 174
Web Application Penetration Testing
Web Application Penetration Testing
• Information used in authentication (e.g. Credentials, PINs, Session
identifiers, Tokens, Cookies…)
• Information protected by laws, regulations or specific organizational
policy (e.g. Credit Cards, Customers data)
If the application transmits sensitive information via unencrypted
channels - e.g. HTTP - it is considered a security risk. Some examples
are Basic authentication which sends authentication credentials
in plain-text over HTTP, form based authentication credentials
sent via HTTP, or plain-text transmission of any other information
considered sensitive due to regulations, laws, organizational policy
or application business logic.
How to Test
Various types of information that must be protected, could be transmitted
by the application in clear text. It is possible to check if this
information is transmitted over HTTP instead of HTTPS, or whether
weak cyphers are used. See more information about insecure
transmission of credentials Top 10 2013-A6-Sensitive Data Exposure
[3] or insufficient transport layer protection in general Top 10
2010-A9-Insufficient Transport Layer Protection [2].
Example 1: Basic Authentication over HTTP
A typical example is the usage of Basic Authentication over HTTP.
When using Basic Authentication, user credentials are encoded
rather than encrypted, and are sent as HTTP headers. In the example
below the tester uses curl [5] to test for this issue. Note how the
application uses Basic authentication, and HTTP rather than HTTPS
$ curl -kis http:/example.com/restricted/
HTTP/1.1 401 Authorization Required
Date: Fri, 01 Aug 2013 00:00:00 GMT
WWW-Authenticate: Basic realm=”Restricted Area”
Accept-Ranges: bytes Vary:
Accept-Encoding Content-Length: 162
Content-Type: text/html
401 Authorization Required
401 Authorization Required
Invalid login credentials!
Example 2: Form-Based Authentication Performed over HTTP
Another typical example is authentication forms which transmit
user authentication credentials over HTTP. In the example below
one can see HTTP being used in the “action” attribute of the form. It
is also possible to see this issue by examining the HTTP traffic with
an interception proxy.
User:
Password:
Example 3: Cookie Containing Session ID Sent over HTTP
The Session ID Cookie must be transmitted over protected channels.
If the cookie does not have the secure flag set [6] it is permitted for
the application to transmit it unencrypted. Note below the setting
of the cookie is done without the Secure flag, and the entire log in
process is performed in HTTP and not HTTPS.
https:/secure.example.com/login
POST /login HTTP/1.1
Host: secure.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https:/secure.example.com/
Content-Type: application/x-www-form-urlencoded
Content-Length: 188
HTTP/1.1 302 Found
Date: Tue, 03 Dec 2013 21:18:55 GMT
Server: Apache
Cache-Control: no-store, no-cache, must-revalidate, maxage=0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Set-Cookie: JSESSIONID=BD99F321233AF69593ED-
F52B123B5BDA; expires=Fri, 01-Jan-2014 00:00:00 GMT;
path=/; domain=example.com; httponly
Location: private/
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------
http:/example.com/private
GET /private HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https:/secure.example.com/login
Cookie: JSESSIONID=BD99F321233AF69593ED-
F52B123B5BDA;
Connection: keep-alive
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Expires: 0
Content-Type: text/html;charset=UTF-8
Content-Length: 730
Date: Tue, 25 Dec 2013 00:00:00 GMT
----------------------------------------------------------
Tools
• [5] curl can be used to check manually for pages
References
OWASP Resources
• [1] OWASP Testing Guide - Testing for Weak SSL/TLS Ciphers,
Insufficient Transport Layer Protection (OTG-CRYPST-001)
• [2] OWASP TOP 10 2010 - Insufficient Transport Layer Protection
• [3] OWASP TOP 10 2013 - Sensitive Data Exposure
• [4] OWASP ASVS v1.1 - V10 Communication Security Verification
Requirements
• [6] OWASP Testing Guide - Testing for Cookies attributes (OTG-
SESS-002)
Testing for business logic
Summary
Testing for business logic flaws in a multi-functional dynamic web
application requires thinking in unconventional methods. If an application’s
authentication mechanism is developed with the intention
of performing steps 1, 2, 3 in that specific order to authenticate
a user. What happens if the user goes from step 1 straight
to step 3? In this simplistic example, does the application provide
access by failing open; deny access, or just error out with a 500
message?
There are many examples that can be made, but the one constant
lesson is “think outside of conventional wisdom”. This type of vulnerability
cannot be detected by a vulnerability scanner and relies
upon the skills and creativity of the penetration tester. In addition,
this type of vulnerability is usually one of the hardest to detect,
and usually application specific but, at the same time, usually one
of the most detrimental to the application, if exploited.
The classification of business logic flaws has been under-studied;
although exploitation of business flaws frequently happens in real-world
systems, and many applied vulnerability researchers investigate
them. The greatest focus is in web applications. There
is debate within the community about whether these problems
represent particularly new concepts, or if they are variations of
well-known principles.
Testing of business logic flaws is similar to the test types used
by functional testers that focus on logical or finite state testing.
These types of tests require that security professionals think a bit
differently, develop abused and misuse cases and use many of the
testing techniques embraced by functional testers. Automation of
business logic abuse cases is not possible and remains a manual
art relying on the skills of the tester and their knowledge of the
complete business process and its rules.
Business Limits and Restrictions
Consider the rules for the business function being provided by the
application. Are there any limits or restrictions on people’s behavior?
Then consider whether the application enforces those rules.
It’s generally pretty easy to identify the test and analysis cases to
verify the application if you’re familiar with the business. If you are
a third-party tester, then you’re going to have to use your common
sense and ask the business if different operations should be allowed
by the application.
Sometimes, in very complex applications, the tester will not have a
full understanding of every aspect of the application initially. In these
situations, it is best to have the client walk the tester through the application,
so that they may gain a better understanding of the limits
and intended functionality of the application, before the actual test
begins. Additionally, having a direct line to the developers (if possible)
during testing will help out greatly, if any questions arise regarding
the application’s functionality.
Description of the Issue
Automated tools find it hard to understand context, hence it’s up to a
person to perform these kinds of tests. The following two examples
will illustrate how understanding the functionality of the application,
the developer’s intentions, and some creative “out-of-the-box”
thinking can break the application’s logic. The first example starts
with a simplistic parameter manipulation, whereas the second is a
real world example of a multi-step process leading to completely
subvert the application.
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