1BO4r2U

151 152
Web Application Penetration Testing
Web Application Penetration Testing
ity, the tester needs to identify all user controlled input that influences
one or more headers in the response, and check whether he/she
can successfully inject a CR+LF sequence in it.
The headers that are the most likely candidates for this attack are:
• Location
• Set-Cookie
It must be noted that a successful exploitation of this vulnerability
in a real world scenario can be quite complex, as several factors
must be taken into account:
[1] The pen-tester must properly set the headers in the fake response
for it to be successfully cached (e.g., a Last-Modified header
with a date set in the future). He/she might also have to destroy
previously cached versions of the target pagers, by issuing a preliminary
request with “Pragma: no-cache” in the request headers
[2] The application, while not filtering the CR+LF sequence, might
filter other characters that are needed for a successful attack (e.g.,
“”). In this case, the tester can try to use other encodings
(e.g., UTF-7)
[3] Some targets (e.g., ASP) will URL-encode the path part of the
Location header (e.g., www.victim.com/redirect.asp), making a
CRLF sequence useless. However, they fail to encode the query
section (e.g., ?interface=advanced), meaning that a leading question
mark is enough to bypass this filtering
For a more detailed discussion about this attack and other information
about possible scenarios and applications, check the papers
referenced at the bottom of this section.
Gray Box testing
HTTP Splitting
A successful exploitation of HTTP Splitting is greatly helped by
knowing some details of the web application and of the attack target.
For instance, different targets can use different methods to
decide when the first HTTP message ends and when the second
starts. Some will use the message boundaries, as in the previous
example. Other targets will assume that different messages will
be carried by different packets. Others will allocate for each message
a number of chunks of predetermined length: in this case,
the second message will have to start exactly at the beginning of a
chunk and this will require the tester to use padding between the
two messages. This might cause some trouble when the vulnerable
parameter is to be sent in the URL, as a very long URL is likely to
be truncated or filtered. A gray box scenario can help the attacker
to find a workaround: several application servers, for instance, will
allow the request to be sent using POST instead of GET.
HTTP Smuggling
As mentioned in the introduction, HTTP Smuggling leverages the
different ways that a particularly crafted HTTP message can be
parsed and interpreted by different agents (browsers, web caches,
application firewalls). This relatively new kind of attack was
first discovered by Chaim Linhart, Amit Klein, Ronen Heled and
Steve Orrin in 2005. There are several possible applications and
we will analyze one of the most spectacular: the bypass of an
application firewall. Refer to the original whitepaper (linked at
the bottom of this page) for more detailed information and other
scenarios.
Application Firewall Bypass
There are several products that enable a system administration to
detect and block a hostile web request depending on some known
malicious pattern that is embedded in the request. For example, consider
the infamous, old Unicode directory traversal attack against IIS
server (http://www.securityfocus.com/bid/1806), in which an attacker
could break out the www root by issuing a request like:
http:/target/scripts/..%c1%1c../winnt/system32/cmd.exe?/
c+
Of course, it is quite easy to spot and filter this attack by the presence
of strings like “..” and “cmd.exe” in the URL. However, IIS 5.0 is
quite picky about POST requests whose body is up to 48K bytes and
truncates all content that is beyond this limit when the Content-Type
header is different from application/x-www-form-urlencoded. The
pen-tester can leverage this by creating a very large request, structured
as follows:
POST /target.asp HTTP/1.1