Identify application entry points (OTG-INFO-006)

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

This is a draft of a section of the new Testing Guide v3

Brief Summary

Enumerating the application and its attack surface is a key precursor before any attack should commence. This section will help you identify and map out every area within the application that should be investigated once your enumeration and mapping phase has been completed.

Description of the Issue

You should always get a good understanding of the application and how the user/browser communicates with it as you walk through the application. As you walk through the application pay special attention to all HTTP request (GET and POST Methods also known as Verbs) and every parameter and form field that is passed to the application. In addition to this pay attention to when GET requests are used and when POST request are used. It is very common that GET request will be used but when sensitive information is passed it will be done within the body of a POST request. Note here that to see the parameters sent in a POST request you will need to be using a tool such as an in-line proxy (for example OWASP's Webscarab) or a browser plugin. Within the POST request make special note of any hidden form fields that are being passed to the application as these usually contain sensitive information such as state information, quantity of items, the price of items, etc. In the author's experience it has been very useful in using an in-line proxy and a spreadsheet for this stage. The proxy will keep track of every request and response between you and the application as you walk through it. Additionally at this point I usually trap every request and response so that I 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) but with experience of knowing what to look for this time can be significantly reduced. As you walk through the application and notice any interesting parameters in the URL, custom header, or body of the message then note this in your spreadsheet. The spreadsheet should include the page you requested (might be good to add the request number from the proxy here also), the interesting parameters, the type of request (POST/GET), authenticated/unauthenticated access, ssl used, part of a multi-step process, and any other special notes (such as state info passed to another application). Once you have every area of the application mapped out then you can go through the application and test each of the areas that you 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 I will identify some helpful points of interests for all requests and responses. Within the requests section I will focus on the GET and POST methods as these are the majority of the requests that are used. Also note that are are Methods that can be used such as PUT and DELETE which can be very dangerous if allowed. There is a special section in this guide dedicated for testing this so I will only make note of this to be as thorough as possible.

Requests:

-Identify where GET's are used and where POST's are used -Identify all parameters identified within 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 the form fields you enter will be sent in the body of the message in addition to any hidden form fields are automagically sent to the application as well. These typically aren't seen unless you are using a proxy or view the HTML source code. In addition the next page you see, its data, and your access can all be different depending on the value of this parameter(s). -Identify all parameters within the GET request (i.e. URL) in particular the query string (usually after a ? mark). -Identify all the parameters of the query string which usually are in a pair format such as foo=bar. Also note many parameters can be in one query sting (such as separated by a &, ~, :, or any other special character or encoding) and not necessarily in this format. -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 your attacks. You need to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. I will stop at this point as later sections will identify how to test these parameters but just make sure you identify each one of them. -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 directive), modified, and/or added to. -Identify where there are any redirects (300 type messages), 400 type messages in particular 403 Forbidden, and 500 internal server erros during normal responses (ie unmodified requests) -Also not where any interesting headers are identified such as "Server: BIG-IP" which indicated the site is being load balanced. (thus if load balanced and one server is incorrectly configured then you might have to make multiple requests to access the vulnerable server depending on the type of load balancing used)

Black Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...