Test HTTP Methods (OTG-CONFIG-006)
In this test we check that the web server is not configured to allow potentially dangerous HTTP commands (methods) and that Cross Site Tracing (XST) is not possible
Short Description of the Issue (Topic and Explanation)
While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the today standard) defines the following eight methods:
Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:
- PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim server as a file repository
- DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack
- CONNECT: This method could allow a client to use the web server as a proxy
- TRACE: This method simply echoes back to the client whatever string has been sent to the server, and it is used mainly for debugging purposes. This method, apparently harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page)
If an application needs one or more of these methods, it is important to check that their use is properly limited to trusted users and safe conditions.
Black Box testing and example
Discover the Supported Methods
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.
The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
icesurfer@nightblade ~ $ nc www.victim.com 80 OPTIONS / HTTP/1.1 Host: www.victim.com HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Tue, 31 Oct 2006 08:00:29 GMT Connection: close Allow: GET, HEAD, POST, TRACE, OPTIONS Content-Length: 0 icesurfer@nightblade ~ $
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section
Test XST Potential
Note: in order to understand the logic and the goals of this attack you need to be familiar with Cross Site Scripting attacks.
As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), we can proceed as shown in the following example:
icesurfer@nightblade ~ $ nc www.victim.com 80 TRACE / HTTP/1.1 Host: www.victim.com HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Tue, 31 Oct 2006 08:01:48 GMT Connection: close Content-Type: message/http Content-Length: 39 TRACE / HTTP/1.1 Host: www.victim.com
There are multiple ways to make a browser issue a TRACE request, as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker as two ways to successfully launch a Cross Site Tracing attack:
More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman.
Gray Box testing and example
The testing in a Gray Box scenario follows the same steps of a Black Box scenario
- RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
- RFC 2975: “HTTP State Management Mechanism”
- Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
- NetCat - http://www.vulnwatch.org/netcat
OWASP Testing Guide v2
Here is the OWASP Testing Guide v2 Table of Contents