COMMAND

    NS and IE

SYSTEMS AFFECTED

    Netscape and MS Web browsers

PROBLEM

    Richard  Reiner  found  following.   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   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?

SOLUTION

    It appears that the attacker needs to guess the name of the target
    frame, which for  static pages is  trivial. If this  is true, then
    dynamically generated HTML can defeat the attack at the host side,
    by  generating  an  address-  or  session-based frame name that is
    unguessable by the attacker. To do this, modify the frame name  to
    use the hash of a secret appended to the remote's IP address:

        frame_name = original_name + SHA1( browser_IP_address + secret);