1BO4r2U

103 104
Web Application Penetration Testing
Web Application Penetration Testing
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.
#!/bin/bash
for webservmethod in GET POST PUT TRACE CONNECT OP-
TIONS PROPFIND;
do
printf “$webservmethod “ ;
printf “$webservmethod / HTTP/1.1\nHost: $1\n\n” | nc -q 1
$1 80 | grep “HTTP/1.1”
done
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. As often
in security, unexpected behaviors are a usual source of weaknesses
that could lead to HTTP Parameter Pollution attacks in this case.
To better introduce this class of vulnerabilities and the outcome of
HPP attacks, it is interesting to analyze some real-life examples
that have been discovered in the past.
Input Validation and filters bypass
In 2009, immediately after the publication of the first research on
HTTP Parameter Pollution, the technique received attention from
the security community as a possible way to bypass web application
firewalls.
One of these flaws, affecting ModSecurity SQL Injection Core Rules,
represents a perfect example of the impedance mismatch between
applications and filters. The ModSecurity filter would correctly
blacklist the following string: select 1,2,3 from table, thus blocking
this example URL from being processed by the web server: /index.
aspx?page=select 1,2,3 from table. However, by exploiting the concatenation
of multiple HTTP parameters, an attacker could cause
the application server to concatenate the string after the ModSecurity
filter already accepted the input. As an example, the URL /
index.aspx?page=select 1&page=2,3 from table would not trigger
the ModSecurity filter, yet the application layer would concatenate
the input back into the full malicious string.
Another HPP vulnerability turned out to affect Apple Cups, the
well-known printing system used by many UNIX systems. Exploiting
HPP, an attacker could easily trigger a Cross-Site Scripting
vulnerability using the following URL: http: /127.0.0.1:631/admin
/?kerberos=onmouseover=alert(1)&kerberos. The application validation
checkpoint could be bypassed by adding an extra kerberos
argument having a valid string (e.g. empty string). As the validation
checkpoint would only consider the second occurrence, the first
kerberos parameter was not properly sanitized before being used
to generate dynamic HTML content. Successful exploitation would
result in Javascript code execution under the context of the hosting
web site.
Authentication bypass
An even more critical HPP vulnerability was discovered in Blogger,
the popular blogging platform. The bug allowed malicious users to
take ownership of the victim’s blog by using the following HTTP request:
POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=goldshlager19test%40gmail.com(attacker
email)&ok=Invite
The flaw resided in the authentication mechanism used by the web
application, as the security check was performed on the first blogID
parameter, whereas the actual operation used the second occurrence.
Expected Behavior by Application Server
The following table illustrates how different web technologies behave
in presence of multiple occurrences of the same HTTP parameter.
Given the URL and querystring: http:/example.com/?color=red&color=blue
Web Application Server Backend
ASP.NET / IIS
ASP / IIS
PHP / Apache
PHP / Zeus
JSP, Servlet / Apache Tomcat
JSP, Servlet / Oracle Application
Server 10g
JSP, Servlet / Jetty
IBM Lotus Domino
IBM HTTP Server
mod_perl, libapreq2 / Apache
Perl CGI / Apache
mod_wsgi (Python) / Apache
Python / Zope
ASP
All occurrences concatenated
with a comma
All occurrences concatenated
with a comma
Last occurrence only
Last occurrence only
First occurrence only
First occurrence only
First occurrence only
Last occurrence only
First occurrence only
First occurrence only
First occurrence only
First occurrence only
All occurrences in List data
type
(source: Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf )
How to Test
Luckily, because the assignment of HTTP parameters is typically handled
via the web application server, and not the application code itself,
testing the response to parameter pollution should be standard across
all pages and actions. However, as in-depth business logic knowledge
is necessary, testing HPP requires manual testing. Automatic tools
can only partially assist auditors as they tend to generate too many
false positives. In addition, HPP can manifest itself in client-side and
server-side components.
Server-side HPP
To test for HPP vulnerabilities, identify any form or action that allows
user-supplied input. Query string parameters in HTTP GET requests
are easy to tweak in the navigation bar of the browser. If the form action
submits data via POST, the tester will need to use an intercepting
proxy to tamper with the POST data as it is sent to the server. Having
identified a particular input parameter to test, one can edit the GET
or POST data by intercepting the request, or change the query string
after the response page loads. To test for HPP vulnerabilities simply
append the same parameter to the GET or POST data but with a different
value assigned.
For example: if testing the search_string parameter in the query
string, the request URL would include that parameter name and value.
http:/example.com/?search_string=kittens
JSP
color=red,blue
color=red,blue
color=blue
color=blue
color=red
color=red
color=red
color=blue
color=red
color=red
color=red
color=red
color=[‘red’,’blue’]
The particular parameter might be hidden among several other parameters,
but the approach is the same; leave the other parameters in
place and append the duplicate.
http:/example.com/?mode=guest&search_string=kittens&num_results=100
Append the same parameter with a different value
http:/example.com/?mode=guest&search_string=kittens&num_results=100&search_string=puppies
and submit the new request.
Analyze the response page to determine which value(s) were parsed.
In the above example, the search results may show kittens, puppies,
some combination of both (kittens,puppies or kittens~puppies or [‘kittens’,’puppies’]),
may give an empty result, or error page.
This behavior, whether using the first, last, or combination of input parameters
with the same name, is very likely to be consistent across
the entire application. Whether or not this default behavior reveals
a potential vulnerability depends on the specific input validation and
filtering specific to a particular application. As a general rule: if existing
input validation and other security mechanisms are sufficient on
single inputs, and if the server assigns only the first or last polluted
parameters, then parameter pollution does not reveal a vulnerability. If
the duplicate parameters are concatenated, different web application
components use different occurrences or testing generates an error,
there is an increased likelihood of being able to use parameter pollution
to trigger security vulnerabilities.
A more in-depth analysis would require three HTTP requests for each
HTTP parameter:
[1] Submit an HTTP request containing the standard parameter name
and value, and record the HTTP response. E.g. page?par1=val1
[2] Replace the parameter value with a tampered value, submit and
record the HTTP response. E.g. page?par1=HPP_TEST1
[3] Send a new request combining step (1) and (2). Again, save the
HTTP response. E.g. page?par1=val1&par1=HPP_TEST1
[4] Compare the responses obtained during all previous steps. If the
response from (3) is different from (1) and the response from (3) is
also different from (2), there is an impedance mismatch that may be
eventually abused to trigger HPP vulnerabilities.
Crafting a full exploit from a parameter pollution weakness is beyond
the scope of this text. See the references for examples and details.
Client-side HPP
Similarly to server-side HPP, manual testing is the only reliable technique
to audit web applications in order to detect parameter pollution
vulnerabilities affecting client-side components. While in the server-side
variant the attacker leverages a vulnerable web application to
access protected data or perform actions that either not permitted or
not supposed to be executed, client-side attacks aim at subverting client-side
components and technologies.
To test for HPP client-side vulnerabilities, identify any form or action
that allows user input and shows a result of that input back to the
user. A search page is ideal, but a login box might not work (as it might
not show an invalid username back to the user).
Similarly to server-side HPP, pollute each HTTP parameter with
%26HPP_TEST and look for url-decoded occurrences of the user-sup-