An apparent oversight in the (really pitifully ad hoc) cross-domain access controls in both the Netscape and the Microsoft browsers (in all frames-capable versions we have tested to date) makes it trivially easy for badly-intentioned code in a Web page (or an HTML email message) to poke content into another site, by resetting the document displayed in one of the target site's frames. The browsers give no obvious indication that this has happened; thus users can easily be misled. This could allow a malicious web site or email sender to falsely (but convincingly) attribute a message of its choice to the target, which could be a widely trusted source. Of course, since that message could easily contain a form or other data-gathering tool, this can also be exploited to dupe users into submitting confidential information. While the Netscape and the Microsoft browsers both attempt to protect top-level windows, layers, CSS objects, and form fields from this kind of tampering, they neglect to protect frames. Sites using the HTTPS (HTTP-SSL) protocol are just as easily exploited as plain HTTP sites. Exploits are possible from plain HTML, as well as from Javascript. Full details, and HTML-based and Javascript-based demos, can be found at http://www.securexpert.com . NB: both the Microsoft and the Netscape browsers *can*, if correctly asked, reveal that a frame is of a different origin than expected; but only when the user purposely investigates. Neither browser gives any warning if a frame is reloaded with foreign content by code running from a foreign domain. This raises a deeper question: is it properly the role of the Web browser software to foil this sort of thing? Or should there not be a more deeply entrenched, more reliable, more open, better audited, better trusted mechanism of some sort? Our thinking is that leaving these aspects of security policy to the Web browser software is a bad thing. Here are a few reasons: - Different browsers may implement different policy; this will make it hard to know what to trust, even if the browsers are bug free - Today's popular browsers are binary-only distributions; thus it is extremely difficult to determine what policy they instantiate. - In current implementations, all aspects of policy are hard-wired. Yet many are completely arbitrary -- e.g. what is acceptable as "same-domain" access to objects within the HTML page -- e.g. are www.a.com and www2.a.com considered to be within the smae domain? Are www.x.a.com and www.y.a.com? - Web browsers require or use no special system privileges; therefore malicious local users could easily create trojaned browsers What a better mechanism might be -- better, in other words, than the Java sandbox; and much better than the ad hoc sandbox-like strictures that have lately been added to Javascript -- has become a favorite subject of discussion around here. Thoughts are welcomed.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:23:32 PDT