Cross-Site Tracing is a particularly elaborate vulnerability that, like cross-site scripting, involves the ability to move data between different origins (essential between different web sites, within the context of this article) in an exploitative way that bypasses controls intended to prevent such transfer.

A web browser is essentially a “multi-tenanted” shared platform that is capable of rendering and interacting with any number of web applications. It is intended that each website operated within a relative “sandbox” with its own data view horizon and limited ability to access or interact with other websites’ data. The browser makes use of logical security boundaries in an attempt to ensure that one site cannot corrupt or steal data from another. However, browser exploits such as cross-site tracing can be used to “smuggle” data across these logical security boundaries.

Why not just use XSS?

An attacker is willing to work with the vulnerabilities that a given target presents. Whilst they may well wish that a site had a simply exploitable Remote Code Execution (RCE) vulnerability, an attacker does not simply give up when low hanging fruit is not available, but moves on to more complex and esoteric exploits. So if RCE is not available, he may attempt to exploit an SQLi vulnerability; if SQLi is not available he may seek to exploit a stored XSS vulnerability; and if Stored XSS is not available, he may seek to exploit a Reflected XSS vulnerability.

If none of these options are available and an attacker cannot perform a direct XSS attack since the site correctly sanitises data and does not present an opportunity for the reflection of active client-side scripts, then the attacker has hit their first hurdle. Alternatively, a XSS vulnerability may be present, but the attacker wishes to steal the user’s authentication token (this may be a session cookie passed in the Cookie HTTP header, or another token passed in the Authorization or other custom header). A well-versed attacker may turn to Cross-Site Tracing (XST) at this point.

Step 1 – Injecting a script

In the absence of an XSS weakness on the site that an attacker wishes to target and with which their intended victim is interacting, an attacker CAN execute a script on the user’s browser that is loaded and executed within the context of the origin (site) that they control, simply by getting the victim to visit their malicious website or clicking on the link that they supply.

Of course, this is not immediately useful or exploitable by the attacker, since any scripts loaded are restricting to performing actions within the DOM relating to the rendered page, on their domain. Due to same-origin policy (SOP) protection mechanisms in browsers, the attacker’s malicious script cannot directly access objects such as cookies because their malicious script did not originate at that domain and cannot cross the logical boundary that segments the data view horizons in the user’s browser.

Step 2 – Bypassing Cross-Domain Restrictions

So, the second challenge for our attacker is that any actions their script attempts to perform will only take place within the context of their own domain. In order to bypass this domain restriction security policy in the user’s browser, they will need to find a user who has a domain-restriction-bypass vulnerability within their browser. Several vulnerabilities of this type are known to exist in older versions of browsers, but modern web browsers are typically free of such vulnerabilities.

Modern versions of browsers such as Firefox will return errors such as “Illegal Value” and Google Chrome in newer versions should return errors such as “Uncaught Error: SecurityError: DOM Exception 18” in response to attempts to bypass the cross-domain restriction policy.

Step 3 – Third Party Plugins

However, some vulnerable technologies such as Flash and ActiveX are still in use (though fast being retired) and can be exploited where they exist.

The attacker can therefore attempt to get their malicious script to trigger a GET request from the targeted user’s browser to the targeted webserver. Since the HTTP header of the user’s request will contain the user’s session cookie in it for the legitimate site, the attacker may attempt to gain access to it via the DOM “document.cookie” object. This may be possible, but typically is where the third hurdle in this exploit is met – access to the “document.cookie” object is typically disabled for session cookies in particular by developers and system administrators by applying the httpOnly attribute to it in the Set-Cookie response.

HTTP/1.1 200 OK
Date: Sun, 10 Oct 2010 23:26:07 GMT
Server: Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g
Last-Modified: Sun, 26 Sep 2010 22:04:35 GMT
Content-Length: 12
Connection: close
Content-Type: text/html
Set-Cookie: sessionId=38afes7a8; Secure; HTTPOnly

Hello Daniel!

This attribute ensures that the cookie can be transmitted in HTTP requests but cannot be accessed in other way, such as by JavaScript (including the attacker’s malicious script).

Step 4 – HTTP Verbs

However, our attacker has a final trick up their sleeve – the “T” in “XST”. Instead of sending a GET request, the attacker’s malicious script sends a TRACE request to the target site via the flawed component such as Flash. The TRACE verb is designed to echo a user’s input and intended for debugging or testing a web server, but critically all content, including headers is reflected back in the request body (i.e. as context-less text response, without special meaning, and hence not protected by the DOM):

The malicious request that the attacker’s script issues:

$ telnet example.com 80
Trying 127.0.0.1…
Connected to example.com.
Escape character is ‘^]’.
TRACE / HTTP/1.1
Host: example.com
Cookie: sessionId=38afes7a8

And the response received back, first the headers:

HTTP/1.1 200 OK
Date: Mon, 02 Dec 2002 19:24:51 GMT
Server: Apache/2.0.40 (Unix)
Content-Type: message/http

and then the message body containing a reflection of the submitted request:

TRACE / HTTP/1.1
Host: example.com
Cookie: sessionId=38afes7a8

That session cookie can now be picked off the HTTP TRACE response by the malicious JavaScript since it is plaintext in the message body and is not subject to special domain restriction policies. The malicious JavaScript can then send it on a listening service on the attacker’s site for harvesting. Some modern browsers do block the TRACE method usage in several places in order to help mitigate XST, but as always there are generally exploitable workarounds or exceptions, particularly in unpatched or older software. (Note that the TRACK method may be available and can be exploited in the same way as TRACE).

How can AppCheck Help?

AppCheck can help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities from first principle to detect vulnerabilities in in-house application code. AppCheck also draws on checks for known infrastructure vulnerabilities in vendor devices and code from a large database of known and published CVEs. The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail and proof of concept evidence through safe exploitation.

Additional Information

As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@localhost