search

httpwg / httpbis-issues

1 stars 1 forks source link

TRACE security considerations #33

Closed mnot closed 3 years ago

mnot commented 16 years ago

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

        <p>
            PR: <a href="http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt">http://www.whitehatsec.com/press_releases/WH-PR-20030120.txt</a><br/>
            Details: <a href="http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf">http://www.betanews.com/whitehat/WH-WhitePaper_XST_ebook.pdf</a>
        </p>

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

        <p>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.</p>

        <p>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.</p>

Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/33

mnot commented 16 years ago
mnot commented 16 years ago

@mnot changed version to 00-draft

mnot commented 16 years ago

fielding@gbiv.com commented:

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.

mnot commented 16 years ago

ylafon@w3.org commented:

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

Some methods, like 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.
mnot commented 16 years ago
mnot commented 16 years ago

Fixed in 654:

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