Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Rain Forest Puppy (rfp_at_vulnwatch.org)
Date: Wed Jan 22 2003 - 21:28:55 CST
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
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.