Subject: XSS makes TRACE harmful?

From: Alex Rousskov <[email-masked]>
Date: Fri, 14 Feb 2003 17:39:26 -0700 (MST)

There is an HTTP-related security violation approach found/researched
by White Hat Security:

  PR: http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt
  Details: http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf

I bet many of you have seen the related advisories/PR. For those who
have not, here is the gist:

	Modern browsers usually do not allow scripts embedded in
	HTML to access cookies and authentication information
	exchanged between HTTP client and server. However, a
	script can get access to that info by sending a
	simple HTTP TRACE request to the originating (innocent)
	server. The user agent will auto-include current
	authentication info in such request. The server will echo all
	the authentication information back, for script to read and
	[mis]use. Apparently, sending an HTTP request is possible via
	many scripting methods like ActiveX. See the URL above for
	details.

With numerous XSS (cross-site-scripting) vulnerabilities in user
agents, this seems like a real and nasty problem. TRACE method support
is optional per RFC 2616, but many popular servers support it. White
Hat Security advises server administrators to disable support for
TRACE.

What is your opinion? Should TRACE be supported by default? Is it a
good idea to mention this "exposure" vulnerability in HTTP errata or
elsewhere?

Thanks,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 17 Feb 2003 16:53:07 +0100

Am Samstag, 15.02.03, um 01:39 Uhr (Europe/Berlin) schrieb Alex 
> good idea to mention this "exposure" vulnerability in HTTP errata or

Hmm. Maybe one could exclude sensitive header such as
Authorization, Cookie and Proxy-Authorization from TRACE responses.
After all, 2616, ch. 9.8 says that the complete request SHOULD
be send back. So, it's not a MUST and implementation might have
a good reason for not doing so. Making life harder for such
exploits seems like a good idea and it would allow to keep TRACE
in the server.

On the other hand - as it is stated also in the report - there is no
protection against XSS-enabled clients.

//Stefan

---

From: Scott Lawrence <[email-masked]>
Date: 17 Feb 2003 11:43:01 -0500

> Authorization, Cookie and Proxy-Authorization from TRACE responses.

The entire value of TRACE lies in it being an exact copy; otherwise
it's pretty worthless as a debugging mechanism.

> protection against XSS-enabled clients.

This exploit does not expose any user or application that is not
already sending authentication credentials in clear over the net.
Digest Authentication already solves this problem, and provides the
session tracking (via the server nonce) that applications want as
well, without exposing anything either on the net or to XSS clients.

Trying to repair this "new" problem by changing TRACE is like fixing
an abdominal bullet wound with a Band-Aid.

-- 
Scott Lawrence        
  Actively seeking work 

  http://world.std.com/~lawrence/    [<[email-masked]> is deprecated]