Cross-site tracing attacks

[This article was contributed by LWN reader Tom Owen]

Cross-site scripting (XSS) is a simple idea at heart: the attacker loads exploitative HTML, including a client-side script, into a web site, typically one which allows public submissions and which does not properly quote HTML tags. Any user of the site who reads the story loads the exploit into their browser. The script uses the client browser's rights to cause mischief -- typically to access information and send it to the attacker. Recent XSS vulnerability reports focus on exposing cookie contents -- perhaps including session and authentication details -- to the attacker. Browser domain restrictions are supposed to stop clients from sending cookie contents anywhere except back to the server that issued them, but it's hard to enforce this restriction if scripts are allowed to access those contents, and many browsers have faults which allow scripts to bypass domain restrictions.

Enter cross-site tracing, which is a new variety of XSS attack. It uses the TRACE command, which is an obscure part of the HTTP 1.1 protocol. It substitutes for GET, except that instead of replying to the request the server echoes it -- the TRACE string and the subsequent headers -- back to the client with a content type of message/http. It's intended as a debugging aid. Most web servers implement TRACE as part of the standard, and, as it's never been implicated in security problems, most sites leave it enabled.

In essence, Whitehat report that some browsers can be scripted to send TRACE requests and return the echoed headers to the script. The report lists Mozilla (using XMLDOM) and IE (using XMLHTTP) as vulnerable. HTTP headers seem like they would be innocous, but unfortunately they carry cookies and HTTP authorization strings to the server. With the aid of one of the available domain restriction breaches, these data can be taken from the trace and sent to the attacker.

Whitehat was obviously pleased with this discovery. The press release uses words like "pandemic" and refers to "a serious security flaw affecting all web server[s] world wide." The whitepaper is more tempered, but it implies that the TRACE method has a defect which compromises every web server.

Opinion on Bugtraq (discussions here and here) and Slashdot ranges from "hyped, sensationalised snakeoil" to "a terrible security hole." The critics point out that there's no fault in TRACE, and client domain restriction breaches already offer scripted ways ways to read cookies. On the whole they seem to have won the argument as there's been little press coverage and no rebuttal from Whitehat. There have been some more positive responses noting that script access to the Authorization: header containing the HTTP Basic authentication is new and disturbing, and that client problems are sometimes best fixed at the server.

Nobody is claiming that TRACE is needed on a production server -- it's as vestigial as HELP in Sendmail SMTP. So, as it's certain that a server that can't do TRACE won't ever allow its clients to be subverted through it, removing it may be the way to go. The Apache Limit directive can't suppress TRACE, so Whitehat and Apacheweek both suggest using mod_rewrite to force a forbidden (403) error in Apache:

	RewriteEngine On 
	RewriteCond %{REQUEST_METHOD} ^TRACE 
	RewriteRule .* - [F] 

RewriteEngine On needs to be repeated in every <VirtualHost> block. Experiment suggests that there's more to it than this, (no, I can't make it work ...) but it has to be easier than iPlanet/Netscape, which requires a binary edit.

Security consultants feel pressure to find and publicise security holes, and it's inevitable that some of them will be less serious than the spin suggests. The community's loud and direct quality control is necessary to keep the numbers within limits. However, even snake oil may have something to teach us, and at least one Apache admin will be spending a few hours this week figuring out just what secures the DELETE method.