* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #33 (closed editorial: fixed)

Opened 7 years ago

Last modified 5 years ago

TRACE security considerations

Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: unassigned
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/Pine.BSF.4.53.0302141609440.56878@measurement-factory.com

Description

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.

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

  • Component set to semantics
  • Milestone set to unassigned

comment:2 Changed 7 years ago by mnot@pobox.com

  • version set to 00-draft

comment:3 Changed 7 years ago by fielding@gbiv.com

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.

comment:4 Changed 6 years ago by ylafon@w3.org

Proposal Add in the Security Considerations, in the "Transfer of Sensitive Information" section the following text:

<t>

Some methods, like TRACE (<xref target="method.trace" />) may expose information sent in request headers in the response entity. Clients &SHOULD; be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect data from the Client.

</t>

comment:5 Changed 5 years ago by mnot@pobox.com

  • Priority set to normal
  • Type changed from design to editorial
  • Severity set to Active WG Document

comment:6 Changed 5 years ago by ylafon@w3.org

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in [654]:

Resolve #33: Added TRACE security considerations (closes #33)

Note: See TracTickets for help on using tickets.