Vulnerability in Netscape & Microsoft Web browsers

[rreiner () FSCINTERNET COM (Richard Reiner)]

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.