Vulnwatch mailing list archives
administrivia: cross-site tracing
From: Rain Forest Puppy <rfp () vulnwatch org>
Date: Thu, 23 Jan 2003 03:28:55 +0000 (GMT)
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
Current thread:
- administrivia: cross-site tracing Rain Forest Puppy (Jan 22)