4.0

58
Web Application Penetration Testing
example the netsparker dictionary.
References
• Default Password list: http:/www.governmentsecurity.org/articles/
DefaultLoginsandPasswordsforNetworkedDevices.php
• Default Password list: http:/www.cirt.net/passwords
Test HTTP Methods (OTG-CONFIG-006)
Summary
HTTP offers a number of methods that can be used to perform actions
on the web server. Many of theses methods are designed to aid
developers in deploying and testing HTTP applications. These HTTP
methods can be used for nefarious purposes if the web server is misconfigured.
Additionally, Cross Site Tracing (XST), a form of cross site
scripting using the server’s HTTP TRACE method, is examined.
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 standard today) defines the following eight methods:
• HEAD
• GET
• POST
• PUT
• DELETE
• TRACE
• OPTIONS
• CONNECT
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’s 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 is used mainly for debugging
purposes. This method, originally assumed 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, such as REST
Web Services (which may require PUT or DELETE), it is important to
check that their usage is properly limited to trusted users and safe
conditions.
Arbitrary HTTP Methods
Arshan Dabirsiaghi (see links) discovered that many web application
frameworks allowed well chosen or arbitrary HTTP methods to bypass
an environment level access control check:
• Many frameworks and languages treat “HEAD” as a “GET” request,
albeit one without any body in the response. If a security constraint
was set on “GET” requests such that only “authenticatedUsers”
could access GET requests for a particular servlet or resource,
it would be bypassed for the “HEAD” version. This allowed
unauthorized blind submission of any privileged GET request.
• Some frameworks allowed arbitrary HTTP methods such as “JEFF”
or “CATS” to be used without limitation. These were treated as if
a “GET” method was issued, and were found not to be subject to
method role based access control checks on a number of languages
and frameworks, again allowing unauthorized blind submission of
privileged GET requests.
In many cases, code which explicitly checked for a “GET” or “POST”
method would be safe.
How to Test
Discover the Supported Methods
To perform this test, the tester needs some way to figure out which
HTTP methods are supported by the web server that is being examined.
The OPTIONS HTTP method provides the tester with the most
direct and effective way to do that. RFC 2616 states that, “The OP-
TIONS 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):
$ 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
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 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
one must be familiar with Cross Site Scripting attacks.
The TRACE method, while apparently harmless, can be successfully
leveraged in some scenarios to steal legitimate users’ credentials.
This attack technique was discovered by Jeremiah Grossman in
2003, in an attempt to bypass the HTTPOnly tag that Microsoft introduced
in Internet Explorer 6 SP1 to protect cookies from being
accessed by JavaScript. As a matter of fact, one of the most recurring
attack patterns in Cross Site Scripting is to access the document.cookie
object and send it to a web server controlled by the