Today we will talk about Cross Site Tracing (XST).

Today we will talk about Cross Site Tracing (XST).

In January 2003, Jeremiah Grossman released the HttpOnly cookie circumvention method. He called it Cross-Site Tracing (XST), involuntarily starting a trend of attaching “cross-site” to as many web vulnerabilities as possible.

Alas, “XS” in XST causes similarity to XSS (Cross-Site Scripting), which leads people to mistake XST as a method of JavaScript implementation. (Fortunately, character encoding attacks did not use the term “Cross-Site Unicode”, XSU.) Although XST attacks are based on browser scripts to exploit the vulnerability, they are not JavaScript implementations.

    • XST is a header access tool, usually limited to JavaScript.

Not confused yet?

First, take a look at XSS. XSS vulnerabilities that are better described as HTML injections arise because the web application reflects the attacker’s payload in the HTTP response body – HTML.

This allows an attacker to modify DOM pages by inserting characters that affect the HTML layout, e.g. by adding false characters such as brackets (< and >) and quotes (‘ and “). Cross-site tracing relies on embedding HTML code to create an exploit in the victim’s browser, but this means that the attacker is already able to execute JavaScript.

So, XST is not about embedding the tags <script> in the browser; the attacker should already be able to do this.

Cross-site tracing uses the fact that the web server must reflect the client’s HTTP message in its response. A common misconception about the purpose of the XST attack is that it uses a TRACE request to force the server to reflect JavaScript in an HTTP response, the body of the script that the browser will then execute. As the following example shows, this is exactly what happens, although the JavaScript reflection is not a real vulnerability. Green and red text denote the response text. The request was made with netcat.




Tag Reflection <script> not significant (RFC even says the server should reflect the request without changes). The real result of the XST attack is that it provides HTTP headers that are normally not available in JavaScript.

XST attacks use the TRACE method (or synonymous with TRACK) to read HTTP headers that are otherwise blocked for JavaScript access.

For example, it is assumed that the HttpOnly attribute of a cookie does not allow JavaScript to read the properties of that cookie. The Authentication header, which for HTTP Basic Auth is simply a Base64 username and password, is not part of DOM and cannot be read directly by JavaScript.

When we sent the request through netcat, no cookie values or auth headers were displayed because netcat obviously does not have the internal state that the browser has. So, look at the server response when the browser’s XHR object is used to execute a TRACE to request. This is a fragment of JavaScript:


var xhr = new XMLHttpRequest();'TRACE', 'http://test.lab/', false);
if(200 == xhr.status)

The following image shows one of the possible answers. Pay attention to the text in red. The browser added the Authorization and Cookie headers to the XHR query which were reflected by the server:




Now we see that both the HTTP Basic Authentication header and the cookie value are displayed in the response text. A simple regular JavaScript expression can extract these values, bypassing the usual restrictions on script access to headers or secure cookies. The disadvantage for cybercriminals is that modern browsers (such as those that have moved into this decade) are smart enough to block TRACE queries through the XMLHttpRequest object, leaving the attacker to look for alternative features in add-ons such as Flash.

This is a real vulnerability related to crossite tracing: viewing header values. The exploit would be impossible without JavaScript implementation in the first place. Consequently, its real impact (or threat, depending on how you define these terms) reveals confidential header data. Consequently, alternative names for XST can be TRACE disclosure attack, TRACE header reflection, TRACE implementation (TMI) or TRACE header and cookie attack (THC).



According to RFC 2616, “TRACE allows the client to see what is being obtained at the other end of the query chain and use this data for testing or diagnostic information”. The TRACK method works in the same way, but is specific to Microsoft IIS. XST can be used as a method to steal user cookies using cross-site scripts (XSS), even if the cookie has the HttpOnly flag and/or the user authorization header displayed.

The TRACE method, although it looks harmless, can be successfully used in some scripts to steal credentials from legitimate users. In fact, one of the most frequent attack patterns in cross-site scenarios is accessing the document.cookie object and sending it to a web server controlled by an attacker so that they can capture the victim’s session. Tagging a cookie file as HttpOnly denies JavaScript access to it, protecting it from being sent to third parties. However, even in this scenario it is possible to use the TRACE method to bypass this protection and to access the cookie.

In 2003, Microsoft tried to protect itself against one of the most common forms of cross-site scripting by introducing the HttpOnly flag in Internet Explorer 6, which prevented JavaScript from accessing cookies. A common attack was to gain access to a document.cookie object and send it to a web server controlled by an attacker so that they could capture the victim’s session. Tagging a cookie file as httpOnly denies JavaScript access to it, protecting it from being sent to third parties.

Below is another example of how cURL can be used to form a header:


$ curl -X TRACE -H "X-Header: test"
User-Agent: curl/7.24.0
Host: Accept: */*
X-Header: test

As you can see, he just sends the header back. The problem is that TRACE will display all the information you send to the server, including cookies and web authentication strings, as they are also just headers.


    var xmlhttp = new XMLHttpRequest();
    var url = '';

    xmlhttp.withCredentials = true; // send cookie header'TRACE', url, false);


The above JavaScript code will send a TRACE request to the target web server. If your browser has a cookie from the target domain, the cookies will be displayed in a warning. Of course, this can easily be changed to do something more dangerous, such as send a cookie to another server. XST has successfully provided the code with the ability to bypass httpOnly when accessing cookie data without using document.cookie.

Although this will no longer work in modern browsers, I still think it is important to know that even something seemingly harmless such as the TRACE method can be used as an exploit.

After Microsoft issued a press release describing the HTTPOnly patch to protect against XSS, hackers found a way to circumvent HTTPOnly and conduct XSS attacks on a larger scale. A typical XST attack can begin when a careless Internet user visits a site hosted on a compromised server. The server sends the script code to the victim’s computer. The victim computer sends a TRACE HTTP request to another site that has recently visited the victim computer. The second site then sends cookies or other authentication data to the compromised server and thus makes the data available to the attacker.

To ensure protection against XST, Internet users can disable JavaScript or ActiveX in their browsers. However, this makes inoperable many functions that Internet users take for granted. There are other, less problematic measures that you can implement. For example, you can configure your browser to automatically clear all cookies at the end of each session. Some browsers, such as Firefox and Opera, allow users to easily delete all stored personal data at any time. Server administrators can set up servers to disable HTTP TRACE by default.

General recommendations

  • Remove known domain restriction circumvention weaknesses in browsers.
  • Disabling or disabling the TRACE request method in production and development (unless
  • required) web servers.
  • Web server providers must update their web server packages to disable TRACE by default.
  • Web server providers should inform their users how to disable or disable TRACE on existing web servers.
  • ActiveX elements that support arbitrary HTTP requests should be marked as unsafe by default.
  • Users should be able to disable all active scripts and increase the security of their credentials. However, this can have a negative impact on the functionality of many websites.

Since Cross-Site Tracing (XST) can be considered a retro vulnerability, the purpose of this article was to familiarize users with an interesting (in my opinion) vector of attack on web applications.

WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.


0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Do NOT follow this link or you will be banned from the site!
Would love your thoughts, please comment.x

Spelling error report

The following text will be sent to our editors: