Closed Bug 16565 Opened 25 years ago Closed 24 years ago

Two Server Frame Targetting Bug

Categories

(Core :: Security, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 13871

People

(Reporter: joshua, Assigned: security-bugs)

References

Details

Something broke in the frame targetting between
Netscape 4.x and 4.6.

I have a frameset which references two logical
sites within its frames, as seen in the html below.
One frame's src references a logical offsite frame,
though, in production, this site is really my HTTPS
server.  That frames src below is:
  http://dev.chamas.com:2443/login_bar.asp

When that frame's contents, in this case a form,
targets the frame named "body" of the below
frameset, a NEW window pops up, as if frame name "body"
doesn't exists.

Note that this is a bug introduced in 4.6, this
frame syntax worked with Netscape 3.x & previous 4.x
browsers and IE 3.x & 4.x browsers.

The WORKAROUND for my site is to start the frame
named "body" with src contents from the second SSL site,
then it seems there are no problems targetting this
frame later from frames in either logical site.

Thanks,

Joshua

<html>
<head>
<title>NODEWORKS &gt;&gt; Web Link Monitoring</title>
</head>

<frameset cols=*,110,503,* framespacing=0 border=0 frameborder=0>
        <frame src=edge.htm scrolling=no>
        <frame name=nav src="navbar.htm" marginheight=10 marginwidth=6
scrolling=no>

        <frameset rows=37,* framespacing=0 frameborder=0 border=0>
                <frame name=menu src=http://dev.chamas.com:2443/login_bar.asp
scrolling=no
                        marginheight=1 marginwidth=5 >
                <frame name=body src=splash.htm
                        marginheight=5 marginwidth=5 >
        </frameset>
        <frame src=edge.htm scrolling=no>
</frameset>
</html>
Assignee: karnaze → pollmann
Reassigning to Eric.
Assignee: pollmann → norris
Component: HTMLFrames → Security
OS: Windows NT → All
Hardware: PC → All
Summary: Two Site Frame Targetting Bug → Two Server Frame Targetting Bug
First of all, this is a Nav issue and not a Mozilla issue.  In general, Nav
issues should not be posted in bugzilla, as bugzilla is intended to be a bug
tracking database for the Mozilla browser.

It so happens that I remember this change, and it was a security fix introduced
in Nav 4.6.

If I am site X and I embed site Y in a frameset, I don't want site Y to be able
to take over my frames just because they happen to have the same names as mine.

But more importantly, if I am devious site X and I embed well-known, legitimate
site Y in my framesets, site Y certainly doesn't want me to be able to make it
appear as though, when one of their links is clicked, a form asking for name and
password appears in a large frame, while their intended frame appears in a
hidden frame.  There was an well-publicized exploit that did something like
this.

You will have to find a workaround for this bug in Nav 4.6  This workaround will
probably look something like putting all of your content on one server, or at
least redesigning it such that the frameset namespaces of two or more different
servers don't have to overlap.  For your example, try putting the inner frameset
containing "menu" and "body" both on the same server, dev.chamas.com (which I
could not connect to).

Giving Norris this bug for consideration.  Norris, is this issue something that
is being/should be carried over to Gecko?
Status: NEW → ASSIGNED
Target Milestone: M14
Fixing frame spoofing is a relatively low priority. Marking M14.
Depends on: 13871
We'll have to have some of the same frame spoofing fixes in Seamonkey (see
13871). I'll look at this bug when I do those.
Target Milestone: M14 → M16
Not required for beta.
Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.
Component: Security → Security: General
This security fix is one of my major complaints with Nav (aside from it's bugs) 
and truely hope it doesn't find it's way into any future Mozilla build. IT 
already has me using IE for a number of things.
Target Milestone: M16 → M17
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Status: ASSIGNED → NEW
Assigning QA to czhang
QA Contact: petersen → czhang

*** This bug has been marked as a duplicate of 13871 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Verified dupe.
You need to log in before you can comment on or make changes to this bug.