4.0

106
Web Application Penetration Testing
1.2 GET
• An example of a failed test (ie, the server supports OPTIONS despite
no need for it):
GET /index.html HTTP/1.1
host: www.example.com
1.3 HEAD
HEAD /index.html HTTP/1.1
host: www.example.com
1.4 POST
POST /index.html HTTP/1.1
host: www.example.com
#!/bin/bash
for webservmethod in GET POST PUT TRACE CONNECT
OPTIONS PROPFIND;
do
printf “$webservmethod “ ;
printf “$webservmethod / HTTP/1.1\nHost: $1\n\n” | nc -q 1 $1
80 | grep “HTTP/1.1”
done
1.5 PUT
PUT /index.html HTTP/1.1
host: www.example.com
1.6 DELETE
DELETE /index.html HTTP/1.1
host: www.example.com
1.7 TRACE
TRACE /index.html HTTP/1.1
host: www.example.com
1.8 CONNECT
CONNECT /index.html HTTP/1.1
host: www.example.com
2. Sending HTTP requests
• For each method and/or method text file, send the request to
nc www.example.com 80 < OPTIONS.http.txt
your web server via netcat or telnet on port 80 (HTTP):
3. Parsing HTTP responses
• Although each HTTP method can potentially return different results,
there is only a single valid result for all methods other than
GET and POST.
The web server should either ignore the request completely or return
an error. Any other response indicates a test failure as the
server is responding to methods/verbs that are unnecessary.
These methods should be disabled.
Automated HTTP verb tampering testing
If you are able to analyze your application via simple HTTP status
codes (200 OK, 501 Error, etc) - then the following bash script will
test all available HTTP methods.
Code copied verbatim from the Penetration Testing Lab blog [5]
References
Whitepapers
• Arshan Dabirsiaghi: “Bypassing URL Authentication and Authorization
with HTTP Verb Tampering” - http: /www.aspectsecurity.
com/research-presentations/bypassing-vbaac-with-http-verbtampering
Testing for HTTP Parameter pollution
(OTG-INPVAL-004)
Summary
Supplying multiple HTTP parameters with the same name may
cause an application to interpret values in unanticipated ways. By
exploiting these effects, an attacker may be able to bypass input
validation, trigger application errors or modify internal variables
values. As HTTP Parameter Pollution (in short HPP) affects a
building block of all web technologies, server and client side attacks
exist.
Current HTTP standards do not include guidance on how to interpret
multiple input parameters with the same name. For instance,
RFC 3986 simply defines the term Query String as a series of
field-value pairs and RFC 2396 defines classes of reversed and
unreserved query string characters. Without a standard in place,
web application components handle this edge case in a variety of
ways (see the table below for details).
By itself, this is not necessarily an indication of vulnerability. However,
if the developer is not aware of the problem, the presence
of duplicated parameters may produce an anomalous behavior
in the application that can be potentially exploited by an attacker.