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. Thus, attempts to steal the cookie as discussed earlier will fail. However, if the target web server supports the TRACE operation, then an attacker can still steal the cookie. Therefore, if your application generates cookies with the HttpOnly attribute set as a protection against cookie theft, it is essential that you test for this potential vulnerability.
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 1.
Example 1. 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 2, then cross-site tracing is possible on the target web server.
Example 2. 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 3 then it is not vulnerable to XST.
Example 3. 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>
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 described earlier 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 that even if your application is not vulnerable to XST and the attacker cannot steal the cookie, it only makes the simplest XSS attack impossible; it does not mitigate XSS.
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.
Vinay Jagtap
A hard core Technocrat with over a decade of extensive experience in heading complex test projects coupled with real time experience of project management and thought leadership. Extensive experience in Performance, Security and Automation Testing and development of automation frameworks and ability to setup and execute Global service centers and Center of Excellences for testing.
Get Free Email Updates to your Inbox!
