1BO4r2U

35 36
Web Application Penetration Testing
Web Application Penetration Testing
In the author’s experience, it has been very useful to use an intercepting
proxy and a spreadsheet for this stage of the testing. The proxy
will keep track of every request and response between the tester and
the application as they u walk through it. Additionally, at this point,
testers usually trap every request and response so that they can
see exactly every header, parameter, etc. that is being passed to the
application and what is being returned. This can be quite tedious at
times, especially on large interactive sites (think of a banking application).
However, experience will show what to look for and this phase
can be significantly reduced.
As the tester walks through the application, they should take note
of any interesting parameters in the URL, custom headers, or body
of the requests/responses, and save them in a spreadsheet. The
spreadsheet should include the page requested (it might be good to
also add the request number from the proxy, for future reference),
the interesting parameters, the type of request (POST/GET), if access
is authenticated/unauthenticated, if SSL is used, if it’s part of
a multi-step process, and any other relevant notes. Once they have
every area of the application mapped out, then they can go through
the application and test each of the areas that they have identified
and make notes for what worked and what didn’t work. The rest of
this guide will identify how to test each of these areas of interest, but
this section must be undertaken before any of the actual testing can
commence.
Below are some points of interests for all requests and responses.
Within the requests section, focus on the GET and POST methods,
as these appear the majority of the requests. Note that other methods,
such as PUT and DELETE, can be used. Often, these more rare
requests, if allowed, can expose vulnerabilities. There is a special section
in this guide dedicated for testing these HTTP methods.
Requests:
• Identify where GETs are used and where POSTs are used.
• Identify all parameters used in a POST request (these are in the body
of the request).
• Within the POST request, pay special attention to any hidden
parameters. When a POST is sent all the form fields (including
hidden parameters) will be sent in the body of the HTTP message
to the application. These typically aren’t seen unless a proxy or view
the HTML source code is used. In addition, the next page shown, its
data, and the level of access can all be different depending on the
value of the hidden parameter(s).
• Identify all parameters used in a GET request (i.e., URL), in particular
the query string (usually after a ? mark).
• Identify all the parameters of the query string. These usually are in a
pair format, such as foo=bar. Also note that many parameters can
be in one query string such as separated by a &, ~, :, or any other
special character or encoding.
• A special note when it comes to identifying multiple parameters
in one string or within a POST request is that some or all of the
parameters will be needed to execute the attacks.
The tester needs to identify all of the parameters (even if encoded
or encrypted) and identify which ones are processed by the
application. Later sections of the guide will identify how to test
these parameters. At this point, just make sure each one of them
is identified.
• Also pay attention to any additional or custom type headers not
typically seen (such as debug=False).
Responses:
• Identify where new cookies are set (Set-Cookie header), modified,
or added to.
• Identify where there are any redirects (3xx HTTP status code), 400
status codes, in particular 403 Forbidden, and 500 internal server
errors during normal responses (i.e., unmodified requests).
• Also note where any interesting headers are used. For example,
“Server: BIG-IP” indicates that the site is load balanced.
Thus, if a site is load balanced and one server is incorrectly
configured, then the tester might have to make multiple requests
to access the vulnerable server, depending on the type of load
balancing used.
Black Box Testing
Testing for application entry points:
The following are two examples on how to check for application
entry points.
EXAMPLE 1
This example shows a GET request that would purchase an item
from an online shopping application.
GET https:/x.x.x.x/shoppingApp/buyme.asp?CUSTOME-
RID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
Host: x.x.x.x
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuY-
W1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
Result Expected:
Here the tester would note all the parameters of the request such
as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just
be encoded parameters or used for session state).
EXAMPLE 2
This example shows a POST request that would log you into an application.
POST https:/x.x.x.x/KevinNotSoGoodApp/authenticate.asp?-
service=login
Host: x.x.x.x
Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCB-
zZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaX-
MgMTIzNA==
CustomCookie=00my00trusted00ip00is00x.x.x.x00
Body of the POST message:
user=admin&pass=pass123&debug=true&fromtrustIP=true
Result Expected:
In this example the tester would note all the parameters as they
have before but notice that the parameters are passed in the body
of the message and not in the URL. Additionally, note that there is a
custom cookie that is being used.
Gray Box Testing
Testing for application entry points via a Gray Box methodology would
consist of everything already identified above with one addition. In
cases where there are external sources from which the application
receives data and processes it (such as SNMP traps, syslog messages,
SMTP, or SOAP messages from other servers) a meeting with the
application developers could identify any functions that would accept
or expect user input and how they are formatted. For example, the developer
could help in understanding how to formulate a correct SOAP
request that the application would accept and where the web service
resides (if the web service or any other function hasn’t already been
identified during the black box testing).
Tools
Intercepting Proxy:
• OWASP: Zed Attack Proxy (ZAP)
• OWASP: WebScarab
• Burp Suite
• CAT
Browser Plug-in:
• TamperIE for Internet Explorer
• Tamper Data for Firefox
References
Whitepapers
• RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -
http:/tools.ietf.org/html/rfc2616
Map execution paths through application
(OTG-INFO-007)
Summary
Before commencing security testing, understanding the structure of
the application is paramount. Without a thorough understanding of
the layout of the application, it is unlkely that it will be tested thoroughly.
Test Objectives
Map the target application and understand the principal workflows.
How to Test
In black box testing it is extremely difficult to test the entire code base.
Not just because the tester has no view of the code paths through the
application, but even if they did, to test all code paths would be very
time consuming. One way to reconcile this is to document what code
paths were discovered and tested.
There are several ways to approach the testing and measurement of
code coverage:
• Path - test each of the paths through an application that includes
combinatorial and boundary value analysis testing for each decision
path. While this approach offers thoroughness, the number of
testable paths grows exponentially with each decision branch.
• Data flow (or taint analysis) - tests the assignment of variables via
external interaction (normally users). Focuses on mapping the flow,
transformation and use of data throughout an application.
• Race - tests multiple concurrent instances of the application
manipulating the same data.
The trade off as to what method is used and to what degree each
method is used should be negotiated with the application owner.
Simpler approaches could also be adopted, including asking the application
owner what functions or code sections they are particularly
concerned about and how those code segments can be reached.
Black Box Testing
To demonstrate code coverage to the application owner, the tester
can start with a spreadsheet and document all the links discovered by
spidering the application (either manually or automatically). Then the
tester can look more closely at decision points in the application and
investigate how many significant code paths are discovered. These
should then be documented in the spreadsheet with URLs, prose and
screenshot descriptions of the paths discovered.
Gray/White Box testing
Ensuring sufficient code coverage for the application owner is far
easier with the gray and white box approach to testing. Information
solicited by and provided to the tester will ensure the minimum requirements
for code coverage are met.
Example
Automatic Spidering
The automatic spider is a tool used to automatically discover new resources
(URLs) on a particular website. It begins with a list of URLs to
visit, called the seeds, which depends on how the Spider is started.
While there are a lot of Spidering tools, the following example uses the
Zed Attack Proxy (ZAP):
ZAP offers the following automatic spidering features, which can be
selected based on the tester’s needs:
• Spider Site - The seed list contains all the existing URIs already found
for the selected site.
• Spider Subtree - The seed list contains all the existing URIs already
found and present in the subtree of the selected node.
• Spider URL - The seed list contains only the URI corresponding to the
selected node (in the Site Tree).
• Spider all in Scope - The seed list contains all the URIs the user has
selected as being ‘In Scope’.
Tools
• Zed Attack Proxy (ZAP)