Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:4013
HistoryJan 23, 2003 - 12:00 a.m.

[VulnWatch] administrivia: cross-site tracing

2003-01-2300:00:00
vulners.com
15

There's been a lot of back and forth about the recent WhiteHat Security
XST bug. Sensationalism aside, the fact still remains:

  1. Access to cookies, particularly the 'httponly' add-on by IE, is limited
    by browser security restrictions. And I don't recall any browser being
    able to legitimately access auth credentials either, but I could be wrong.

  2. By using XMLDOM objects (Mozilla/Netscape), XML ActiveX controls (IE),
    Shockwave Flash, Java, or whatever browser trickery works, you can make an
    arbitrary request to the server. Yes, this can be seen as a browser
    problem, but it's a multi-technology, multi-browser issue.

  3. The above said technologies may still restrict access to cookies and/or
    auth credentials under normal operation.

  4. By making a TRACE request to a server, the said technologies can cause
    all the headers to be returned as body content, thus circumventing what
    normal access restrictions may apply in #1 and #3.

Yes, the attack still requires a guillable user to wander onto a bad link,
and yes, it requires the browser to support some kind of scriptable object
capable of making an HTTP request. But the fact remains that all of this
was true of cross-site scripting, IN ADDITION to requiring a dynamic
HTML page on the target site which redisplayed HTML content unfiltered.
This attack removes the requirement of a vulnerable dynamic HTML page on
the target site, and instead only requires the server support the TRACE
method (which many do). It has effectively removed the target vulnerable
CGI precondition from the cross-site scripting equation, making it a more
widespread problem than cross-site scripting. In short, rather than a
single CGI being vulnerable to cross-site scripting, now the entire server
is vulnerable, regardless of it's actual contents.

Of course, the actual severity of cross-site scripting is still a thing of
myth and guesstimation. There have been a handful of published
exploitation cases of it in the past, but in actuality cross-site
scripting is more of a 'due diligence' PR campaign than an actual security
threat (IMHO). Exploitation is still a feat of luck and social
engineering.

Getting back to the technical side of things, IIS users should also keep
in mind that IIS aliases 'TRACK' to 'TRACE'…so if you're using URLScan
to specfically block the TRACE method, then add TRACK to the filter to.

Ever onward,

  • rfp