Closed Bug 54060 Opened 24 years ago Closed 23 years ago

'Access denied' overwriting the document of a sibling frame

Categories

(Core :: Security: CAPS, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: jrgmorrison, Assigned: security-bugs)

References

()

Details

(Whiteboard: review needed)

Attachments

(2 files)

As noted at the end of bug 50393: ------- Additional Comments From Mark Reed 2000-09-23 14:29 ------- There still seems to be a problem. Although the frame will be filled by <frame src=javascript:parent.something>, a subsequent attempt to write to that frame using document.open and document.write(something) will fail. I noticed that View, Frame Source is blank for a frame filled by a javascript url. Test case: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> <html> <head> <script language="JavaScript"> var leftFrame = '<html><body><a href="javascript:parent.initialize()"><big>Start Test</big></a></body></html>'; var success = '<html><body><big>Success</big></body></html>'; var blankFrame = '<html><body></body></html>'; function initialize() { self.right.document.open(); self.right.document.write(success); self.right.document.close(); } // end script --> </script> </head> <frameset cols="120,*" > <frame name="left" src="javascript:parent.leftFrame"> <frame name="right" src="javascript:parent.blankFrame"> </frameset> </html> Note that this works if the frame if filled with external files, as in: <frame name="left" src=left.htm> <frame name="right" src=blank.htm> Tested with Build 2000092008 thru 2000092205. ---end--------------------------------------------- I (jrgm) believe this is related to security principals (but perhaps this is not the case). I receive this exception when clicking on the 'Start test' link: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)"]
Test case posted (internally) at http://jrgm.mcom.com/bugs/54060/test.html Adding rtm keyword: I can't point to a specific high-traffic web page at this time, but clearly this is something that is done by some web developers, and works find in Nav4x and IE. (I wouldn't hold nsbeta3 for this, though).
Marking future because I don't have time to work on this right now; sorry.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
rtm-, Mitch marked this future.
Whiteboard: rtm-
QA Contact: czhang → junruh
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
I'm not sure whether or not this is the same bug or not since it doesn't involve frames, but attempting to view info on a apecific automobile model at http://carpoint.msn.com results in a similar error, apparently resulting from trying to assign to window.location.href The terminal mozilla is run from shows the following error: JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "<unknown>"] Error loading URL javascript:GotoVIP(document.Form1);: 805303f5 Said GotoVIP function reads as follows: function GotoVIP(oForm) { var strPage = ''; var strAsciiMake = oForm.mmMakes.options[oForm.mmMakes.selectedIndex].value; var strAsciiModel = oForm.mmModels.options[oForm.mmModels.selectedIndex].value; var strNew = oForm.mmType.options[oForm.mmType.selectedIndex].value; if (!CheckNames(oForm, strAsciiMake, strAsciiModel)) return; if (strNew == 'true') strPage = 'new.asp'; if (strNew == 'false') strPage = 'used.asp'; window.location.href='http://carpoint.msn.com/vip/overview/' + MakeSafeName(strAsciiMake) + '/' + MakeSafeName(strAsciiModel) + '/' + strPage + '?src=Home&pos=Find'; } This makes carpoint pretty much un-usable... at least for me. So if this is the same bug I'd like to suggest upping severity a notch.
That's not the same bug, but we do have a bug filed on the location.href= issue. I forget the number, but it's assigned to me. This will hopefully be fixed when the DOM moves to XPIDL.
Mass changing milestones to Moz0.9.1. Many of these bugs are dependent on the XPConnected DOM and its associated security UI changes.
Target Milestone: Future → mozilla0.9.1
Attached file attachment of jrgm's testcase (deleted) —
Mitchell is bug 56053 ??
Opening up HTMLDocument.write, .writeln, .open, .close to cross-domain access. It's safe to write to any window because once written to, the window has the principals of the script that does the writing. I just tested this. The patch above just changes the policy prefs.
Keywords: correctness, rtm
Whiteboard: rtm- → review needed
*** Bug 64464 has been marked as a duplicate of this bug. ***
sr=jband
r=jst
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Marking VERIFIED FIXED on: -MacOS91 2001-05-21-15-trunk -Win98SE 2001-05-22-06-trunk -LinRH62 2001-05-22-05-trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: