In January 2003 Jeremiah Grossman disclosed 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.
First, let’s review XSS. These vulns, alternately 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 quotes (
<script> tags into the browser. The attacker must already be able to do that.
The reflection of
To reiterate: XST attacks use the
TRACE (or synonymous
For example, the
No cookie values or auth headers showed up when we made the example request via netcat because we didn’t include any. Netcat doesn’t have the internal state or default headers that a browser does. For comparison, take a look at the server’s response when a browser’s XHR object makes a
var xhr = new XMLHttpRequest(); xhr.open('TRACE', 'https://test.lab/', false); xhr.send(null); if(200 == xhr.status) alert(xhr.responseText);
The following image shows one possible response. (In this scenario, we’ve imagined a site for which the browser has some prior context, including cookies and a login with HTTP Basic Auth.) Notice the text in red. The browser included the
Cookie headers to the XHR request, which have been reflected by the server:
We’ll see if any of those actually catch on for the next OWASP Top 10 list.
HttpOnly was introduced by Microsoft in Internet Explorer 6 Service Pack 1, which was released September 9, 2002. It was created to mitigate, not block, XSS exploits that explicitly attacked cookie values. It wasn’t a method for preventing html injection (aka cross-site scripting or XSS) vulnerabilities from occurring in the first place. Mozilla magnanimously adopted in it FireFox 184.108.40.206 four and a half years later. ↩
Security always has nuance. Requesting
TRACE /<script>alert(42)</script> HTTP/1.0will likely be stored in a traffic log file. If some log parsing tool renders requests like this to a web page without filtering the content, then HTML injection once again becomes possible. This is often referred to as second order XSS – when a payload is injected via one application, stored, then rendered by a separate one. ↩