Difference between revisions of "Testing: Identify application entry points (OTG-INFO-006)"

From OWASP
Jump to: navigation, search
(Black Box testing and example)
(46 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v3}}
+
{{Template:OWASP Testing Guide v4}}
  
'''This is a draft of a section of the new Testing Guide v3'''
+
== Summary ==
 +
Enumerating the application and its attack surface is a key precursor before any thorough testing can be undertaken, as it allows the tester to identify likely areas of weakness. This section aims to help identify and map out areas within the application that should be investigated once enumeration and mapping have been completed.
  
== Brief Summary ==
+
== Test Objectives ==
<br>
+
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.
+
<br>
+
== Description of the Issue ==
+
<br>
+
  
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 to pass parameters.  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 use a tool such as an intercepting proxy (for example OWASP's Webscarab) or a browser plug-in.  Within the POST request also 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, that the developer never intended for you to see or change. 
+
Understand how requests are formed and typical responses from the application
  
In the author's experience it has been very useful in using an intercepting 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 for reference), the interesting parameters, the type of request (POST/GET), authenticated/unauthenticated access, if SSL is used, if its part of a multi-step process, and any other special notes.  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.
+
== How to Test ==
  
Below I will identify some helpful points of interests for all requests and responsesWithin 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 other 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.
+
Before any testing begins, always get a good understanding of the application and how the user/browser communicates with itAs you walk through the application, pay special attention to all HTTP requests (GET and POST Methods, also known as Verbs), as well as every parameter and form field that is passed to the application.  In addition, pay attention to when GET requests are used and when POST requests are used to pass parameters to the applicationIt is very common that GET requests are used, but when sensitive information is passed, it is often done within the body of a POST request.  Note that to see the parameters sent in a POST request, you will need to use a tool such as an intercepting proxy (for example, OWASP: [[OWASP_Zed_Attack_Proxy_Project| Zed Attack Proxy (ZAP)]]) or a browser plug-in.  Within the POST request, also 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, that the developer never intended for you to see or change.
  
'''Requests:'''
+
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 you and the application as you 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 teach you what to look for, and, therefore, this phase can be significantly reduced.  As you walk through the application, take note of any interesting parameters in the URL, custom headers, or body of the requests/responses, and save them in your spreadsheet.  The spreadsheet should include the page you 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 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.
  
*Identify where GET's are used and where POST's are used
+
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.
*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 that 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 hidden parameter(s).
+
'''Requests:'''
*Identify all parameters within the GET request (i.e. URL) in particular the query string (usually after a ? mark).
+
* Identify where GETs are used and where POSTs are used.
*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 string such as separated by a &, ~, :, or any other special character or encoding.
+
* Identify all parameters used in a POST request (these are in the body of the request).
*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.
+
* 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 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 the hidden parameter(s).
*Also pay attention to any additional or custom type headers not typically seen (such as debug=False)
+
* 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 your attacks.  You need 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 you identify each one of them.
 +
* Also pay attention to any additional or custom type headers not typically seen (such as debug=False).
  
 
'''Responses:'''
 
'''Responses:'''
 +
*Identify where new cookies are set (Set-Cookie header), modified, or added to.
 +
*Identify where there are any redirects (300 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 you might have to make multiple requests to access the vulnerable server, depending on the type of load balancing used.
  
*Identify where new cookies are set (set-cookie directive), modified, and/or added to.
+
=== Black Box testing and example ===
*Identify where there are any redirects (300 type messages), 400 type messages in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e. unmodified requests).
+
'''Testing for application entry points:''' <br>
*Also not where any interesting headers are identified such as "Server: BIG-IP" which indicates 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.
+
The following are two examples on how to check for application entry points.<br>
  
 +
====EXAMPLE 1====
 +
This example shows a GET request that would purchase an item from an online shopping application.
  
<br>
+
GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
 +
Host: x.x.x.x
 +
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
  
== Black Box testing and example ==
+
'''Result Expected:'''
'''Testing for application entry points:''' <br>
+
...<br>
+
  
'''EXAMPLE 1:'''
+
Here you 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).
  
This example shows a GET request that would purchase an item from an online shopping application.
+
====EXAMPLE 2====
 +
This example shows a POST request that would log you into an application.
  
Example 1 of a simplified GET request:
+
POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
 +
Host: x.x.x.x
 +
Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
 +
CustomCookie=00my00trusted00ip00is00x.x.x.x00
  
*GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
+
Body of the POST message:
*Host: x.x.x.x
+
*Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
+
  
'''Result Expected:'''<br>
+
user=admin&pass=pass123&debug=true&fromtrustIP=true
  
Here you 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)
+
'''Result Expected:'''
  
'''EXAMPLE 2:'''
+
In this example you would note all the parameters as you 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.
  
This example shows a POST request that would login you into an application
+
=== Gray Box testing and example ===
Example 2 of a simplified POST request:
+
  
*POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
+
Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat. This would be if there are any external sources from which the application receives data and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers). If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept or expect user input and how it's 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).
*Host: x.x.x.x
+
*Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
+
*CustomCookie=00my00trusted00ip00is00x.x.x.x00
+
  
 +
== Tools ==
  
*user=admin&pass=pass123&debug=true&fromtrustIP=true
+
'''Intercepting Proxy:'''<br>
  
'''Result Expected:'''<br>
+
*OWASP: [[OWASP_Zed_Attack_Proxy_Project| Zed Attack Proxy (ZAP)]]
 +
*OWASP: [[OWASP_WebScarab_Project| WebScarab]]
 +
* [http://www.portswigger.net/burp/ Burp Suite]
 +
* [http://www.contextis.com/research/tools/cat/ CAT]
  
In this example you would note all the parameters as you 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.
+
'''Browser Plug-in:'''<br>
...<br>
+
  
== Gray Box testing and example ==
+
*[http://www.bayden.com/TamperIE/ TamperIE for Internet Explorer]
 +
*[https://addons.mozilla.org/en-US/firefox/addon/966 Tamper Data for Firefox]
  
Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat.  This would be if there are any external sources where the application receives data from and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers).  If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept and/or expect user input and how its formated.  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).
 
  
 
== References ==
 
== References ==
  
'''Tools'''<br>
+
'''Whitepapers'''<br>
  
*Intercepting Proxy
+
*RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -
*Browser Plug-in
+
http://tools.ietf.org/html/rfc2616

Revision as of 16:27, 30 October 2013

This article is part of the new OWASP Testing Guide v4. 
At the moment the project is in the REVIEW phase.

Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: http://www.owasp.org/index.php/OWASP_Testing_Project

Contents


Summary

Enumerating the application and its attack surface is a key precursor before any thorough testing can be undertaken, as it allows the tester to identify likely areas of weakness. This section aims to help identify and map out areas within the application that should be investigated once enumeration and mapping have been completed.

Test Objectives

Understand how requests are formed and typical responses from the application

How to Test

Before any testing begins, always get a good understanding of the application and how the user/browser communicates with it. As you walk through the application, pay special attention to all HTTP requests (GET and POST Methods, also known as Verbs), as well as every parameter and form field that is passed to the application. In addition, pay attention to when GET requests are used and when POST requests are used to pass parameters to the application. It is very common that GET requests are used, but when sensitive information is passed, it is often done within the body of a POST request. Note that to see the parameters sent in a POST request, you will need to use a tool such as an intercepting proxy (for example, OWASP: Zed Attack Proxy (ZAP)) or a browser plug-in. Within the POST request, also 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, that the developer never intended for you to see or change.

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 you and the application as you 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 teach you what to look for, and, therefore, this phase can be significantly reduced. As you walk through the application, take note of any interesting parameters in the URL, custom headers, or body of the requests/responses, and save them in your spreadsheet. The spreadsheet should include the page you 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 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 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 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 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 your attacks. You need 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 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 header), modified, or added to.
  • Identify where there are any redirects (300 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 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 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?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x 
Host: x.x.x.x
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

Result Expected:

Here you 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=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
CustomCookie=00my00trusted00ip00is00x.x.x.x00

Body of the POST message:

user=admin&pass=pass123&debug=true&fromtrustIP=true

Result Expected:

In this example you would note all the parameters as you 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 and example

Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one caveat. This would be if there are any external sources from which the application receives data and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers). If there are any external sources of input into the application then a meeting with the application developers could identify any functions that would accept or expect user input and how it's 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:

Browser Plug-in:


References

Whitepapers

  • RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -

http://tools.ietf.org/html/rfc2616