Closed
Bug 54060
Opened 24 years ago
Closed 24 years ago
'Access denied' overwriting the document of a sibling frame
Categories
(Core :: Security: CAPS, defect, P3)
Core
Security: CAPS
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: jrgmorrison, Assigned: security-bugs)
References
()
Details
(Whiteboard: review needed)
Attachments
(2 files)
|
799 bytes,
text/html
|
Details | |
|
2.24 KB,
patch
|
Details | Diff | Splinter Review |
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)"]
|
Reporter | |
Comment 1•24 years ago
|
||
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).
Keywords: correctness,
rtm
|
Assignee | |
Comment 2•24 years ago
|
||
Marking future because I don't have time to work on this right now; sorry.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
|
||
Updated•24 years ago
|
QA Contact: czhang → junruh
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.
|
|
Assignee | |
Comment 6•24 years ago
|
||
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.
|
|
Assignee | |
Comment 7•24 years ago
|
||
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
|
||
Comment 8•24 years ago
|
||
|
|
Assignee | |
Comment 10•24 years ago
|
||
|
|
Assignee | |
Comment 11•24 years ago
|
||
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
|
|
Assignee | |
Comment 12•24 years ago
|
||
*** Bug 64464 has been marked as a duplicate of this bug. ***
|
||
Comment 13•24 years ago
|
||
sr=jband
|
||
Comment 14•24 years ago
|
||
r=jst
|
|
Assignee | |
Comment 15•24 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
|
|
||
Comment 16•23 years ago
|
||
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.
Description
•