OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Rain Forest Puppy (rfp_at_vulnwatch.org)
Date: Wed Jan 22 2003 - 21:28:55 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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