1. Bypassing Field Length Restrictions (XSS)
1.1. Problem
In the target application, you may find an input field that could be
vulnerable to stored XSS, but the server truncates the input to a number
of characters that seems insufficient to carry out a meaningful XSS
attack. This restriction can be bypassed by using JavaScript comment delimiters appropriately.
1.2. Solution
The strings in Example 1
combine to be a cross-site scripting attack if they are all concatenated
together. Although none of them is an attack in its own right, they are
all pieces of a standard, basic XSS attack string.
Example 1. Using JavaScript comments to bypass field length
restrictions
<script>/*
*/alert(/*
*/"XSS")/*
*/</script>
|
Also, try inserting the sequence in reverse order.
This will work in several scenarios. It will work when there are
multiple length-restricted fields
that are concatenated together with some punctuation or HTML tags in
between. It will also work when multiple instances of the same input
field are displayed on the same page. The author has seen several
examples in real applications where a list of status codes, for example,
are displayed on a page. The status codes are provided by an end user
and are not checked at all. The status codes are displayed in a table
defined in HTML like that shown in Example 2.
Example 2. Sample application output where status code length is
restricted by server
...
<tr><td>statusCode1
</td></tr>
<tr><td>
statusCode2
</td></tr>
...
|
Example 3 shows the
resulting script from Example 2.
Example 3. Sample HTML output after using JavaScript comments
appropriately
<tr><td><script>
/*</td></tr><tr><td>*/
alert(
/*</td></tr><tr><td>*/
"XSS")
/*</td></tr><tr><td>*/
</script></td></tr>
|
In most browsers, including Internet Explorer 7 and Mozilla
Firefox 3.0, this is equivalent:
<script>alert("XSS")<script>.
As with other similar XSS tests, the application is vulnerable if
you see an alert box pop up as a result of injecting your input.
1.3. Discussion
In scenarios where the server restricts the length of an input
field but fails to perform proper input validation or output encoding,
sequences such as example 12-9 can be used to inject JavaScript into the
page. The cases where this attack would work include those where the
inputs from the attacker are all displayed on a single page (in a table,
for example). Anything between the /*
and */ delimiters is treated as a
comment, and thus, any HTML code that the site inserts between the
attacker’s inputs is commented out.
We will not discuss in depth the exact locations where comments
are allowed in JavaScript, because the answer is
implementation-dependent. Internet Explorer 7, for example, allows comments in many more
locations than Mozilla Firefox 3.0. Some experimentation may be required
to get the attack to work.
2. Attempting Cross-Site Tracing Interactively
2.1. Problem
One protection against XSS attacks implemented by some browsers is the
HttpOnly attribute in cookies. If a
cookie has this attribute set, the browser will not let any JavaScript
code access the cookie. If the target
web server supports the TRACEHttpOnly attribute set as a protection against
cookie theft, it is essential that you test for this potential
vulnerability.
operation, then an attacker can still steal the cookie. Therefore, if
your application generates cookies with the
2.2. Solution
At the command line, type: telnet
host
port where host and
port are the hostname and the TCP
port number of the web server being tested. Then, type the code shown in
Example 4.
Example 4. Testing for XST using telnet
TRACE / HTTP/1.1
Host:host:port
X-Header: This is a test
|
Ensure that you press Enter twice after entering these lines. If
the server responds with something such as shown in Example 5, then cross-site tracing is possible on
the target web server.
Example 5. Sample response when server is vulnerable to XST
HTTP/1.1 200 OK
Date: Sun, 27 Jul 2008 03:49:19 GMT
Server: Apache/2.2.8 (Win32)
Transfer-Encoding: chunked
Content-Type: message/http
44
TRACE / HTTP/1.1
Host:host:port
X-Header: This is a test
0
|
If, on the other hand, the server responds with something like
what is shown in Example 6, then it is not
vulnerable to XST.
Example 6. Sample response when server is not vulnerable to XST
HTTP/1.1 405 Method Not Allowed
Date: Sun, 27 Jul 2008 03:54:48 GMT
Server: Apache/2.2.8 (Win32)
Allow:
Content-Length: 223
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /.</p>
</body></html>
|
2.3. Discussion
Cross-site tracing is a technique that can be used to bypass
HttpOnly protection in cookies. The
TRACE HTTP method is useful for
debugging purposes, but is typically left on by default in many web
servers. A TRACE request to a web
server simply echoes back the request to the caller. When the caller
(browser) has a cookie for the target site, it sends the cookie along
with the request. The cookie is then echoed back by the web server in
the response.
Suppose an attacker cannot execute the attack on a site vulnerable to XSS because the
HttpOnly attribute is set on the
cookie. The attacker can instead generate a script where he can
replace the GET in the XmlHttpRequest.open() function call with
TRACE. Then, he can parse the cookie
out of the server’s response. Of course, this requires the site to be
vulnerable to cross-site scripting as well as to cross-site tracing. The
TRACE method being left enabled is
not necessarily a vulnerability in itself; the attacker needs to be able
to insert JavaScript code into a vulnerable page to be able to make
requests to the target server from the victim’s browser and read the
responses.
NOTE
This test should be executed in your operational environment or
on staging servers that replicate the production environment’s
configuration. This is a configuration issue that needs to be
addressed during deployment, so testing servers in the development or
QA environments will not provide accurate results for the production
environment.
