Closed
Bug 16565
Opened 25 years ago
Closed 25 years ago
Two Server Frame Targetting Bug
Categories
(Core :: Security, defect, P3)
Core
Security
Tracking
()
M17
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 >> 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>
Updated•25 years ago
|
Assignee: karnaze → pollmann
Updated•25 years ago
|
Assignee: pollmann → norris
Component: HTMLFrames → Security
OS: Windows NT → All
Hardware: PC → All
Summary: Two Site Frame Targetting Bug → Two Server Frame Targetting Bug
Comment 2•25 years ago
|
||
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?
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
Comment 4•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M14 → M16
Bulk moving all Browser Security bugs to new Security: General component. The previous Security component for Browser will be deleted.
Component: Security → Security: General
Comment 7•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M16 → M17
Assignee | ||
Comment 8•25 years ago
|
||
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Status: ASSIGNED → NEW
Assignee | ||
Comment 10•25 years ago
|
||
*** This bug has been marked as a duplicate of 13871 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Updated•24 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•