In January 2003 Jeremiah Grossman divulged a method to bypass the HttpOnly1 cookie restriction. He named it Cross-Site Tracing (XST), unwittingly starting a trend to attach “cross-site” to as many web-related vulnerabilities as possible.
Alas, the “XS” in XST evokes similarity to XSS (Cross-Site Scripting) which has the consequence of leading people to mistake XST as a method for injecting JavaScript. (Thankfully, character encoding attacks have avoided the term Cross-Site Unicode, XSU.) Although XST attacks rely on browser scripting to exploit the vulnerability, the vulnerability is not the injection of JavaScript. XST is a means for accessing headers normally restricted from JavaScript.
Confused yet?
First, review XSS. XSS vulnerabilities, better described as HTML injection, occur because a web application echoes an attacker’s payload within the HTTP response body — the HTML. This enables the attacker to modify a page’s DOM by injecting characters that affect the HTML’s layout, such as adding spurious characters like brackets (< and >) and quotes (‘ and “). Cross-site tracing relies on HTML injection to craft an exploit within the victim’s browser, but this implies that an attacker already has the capability to execute JavaScript. So, XST isn’t about injecting tags into the browser; the attacker must already be able to do that.
Cross-site tracing takes advantage of the fact that a web server should reflect the client’s HTTP message in its respose.2 The common misunderstanding of an XST attack’s goal is that it uses a TRACE request to cause the server to reflect JavaScript in the HTTP response body that the browser would consequently execute. As the following example shows, this is in fact what happens even though the reflection of JavaScript isn’t the real vulnerability. The green and red text indicates the response body. The request was made with netcat.