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.
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 quotes (
<script> tags into the browser; the attacker must already be able to do that.
The reflection of
var xhr = new XMLHttpRequest(); xhr.open('TRACE', 'http://test.lab/', false); xhr.send(null); if(200 == xhr.status) alert(xhr.responseText);
The following image shows one possible response. Notice the text in red. The browser added the Authorization and 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 (a.k.a cross-site scripting or XSS) vulnerabilities from occurring in the first place. Mozilla magnanimously adopted in it FireFox 188.8.131.52 four and a half years later. ↩
Security always has nuanced exceptions. Merely requesting
TRACE /<script>alert(42)</script> HTTP/1.0might be stored in the web server’s log file or a database. 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 web app. ↩