Link: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/33
Origin: http://www.w3.org/mid/Pine.BSF.4.53.0302141609440.56878@measurement-factory.com
Component: p2-semantics
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.
That security advisory is a load of festering smelly bits. It depends on a known security issue on a known hole-filled browser and its related error-prone configuration option. The obvious solution (from a protocol perspective) is to avoid sending arbitrary private browser information in arbitrary methods executed by arbitrary javascript. That has nothing to do with TRACE.
XSS should be discussed in the security considerations.