Javascript write to frame failed due to permission denied

VERIFIED FIXED in mozilla0.9.8

Status

()

Core
Security
P1
blocker
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Joe Chou, Assigned: Mitchell Stoltz (not reading bugmail))

Tracking

Trunk
mozilla0.9.8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: patch [eapp])

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
When Siebel testing one of their critical application with Netscape 6, they
encountered an error when trying to write to a frame in a frame set (see test
case below). An error showed in the javascript console:

  "Error: uncaught exception: Permission denied to call method HTMLDocument.write"



This problem prevents Siebel's application from being released. Need JavaScript
folks to look at it ASAP. 



Test case:

HTML file (write_to_frame_test.html):
<HTML>
<HEAD>
<title> Test Page for Netscape 6.2 write problem </title>
<SCRIPT LANGUAGE="JavaScript" SRC="writeTest.js">

</SCRIPT>
</HEAD>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" ALINK="#FF0000"
VLINK="#FF0000">

<H4><FONT FACE="Arial, Helvetica">Test Page for Netscape 6.2 write
problem</FONT></H4>

<P><FORM ACTION="" METHOD=POST name=aForm>
     <INPUT TYPE=text NAME=anInput VALUE="1234" SIZE=48>
       <A HREF="javascript:doNothing()"
          onclick="createFrame('My Title')">&nbsp;&nbsp;Pop-up a new
window&nbsp;&nbsp;
       </A>

</BODY>

</HTML>


Javascript code:


// Beginning of javascript code

var TopDoc = "<HTML><HEAD></HEAD>" +
        "<BODY>\n" +
        "<FORM NAME='myControl' onSubmit='return false;'>\n" +
        "<CENTER>\n" +
        "<TABLE CELLPADDING=0 CELLSPACING=1 BORDER=0><TR>\n" +
        "<TD COLSPAN=7>\n" +
        "<CENTER>\n" +
        "<a href='javascript:parent.opener.writeMyFrame()'>&nbsp;&nbsp;PRESS
HERE&nbsp;&nbsp;</a>\n" +
        "</CENTER>\n" +
        "</TD>\n" +
        "</TR>\n" +
        "</TABLE>\n" +
        "</CENTER>\n" +
        "</FORM>\n" +
        "</BODY>\n" +
        "</HTML>";

var ButtonDoc   = "<HTML><HEAD></HEAD>" +
         "<BODY>" +
         "<TABLE CELLPADDING=0 CELLSPACING=1 BORDER=0><TR>" +
         "<td><nobr>Blank Frame</nobr></td>" +
         "</TR>" +
         "</TABLE>" +
         "</BODY>" +
         "</HTML>";

// POPUP A WINDOW AND BUILD THE FRAMESET
function createFrame(s_winTitle) {
    var theFrameset = "<HTML><HEAD><TITLE>" +
        s_winTitle + "&nbsp&nbsp&nbsp&nbsp</TITLE>" +
        "</HEAD>\n" +
        "<FRAMESET ROWS='80,*' FRAMEBORDER='0'>\n" +
        "  <FRAME NAME='topFrame' marginheight='5'
SRC='javascript:parent.opener.TopDoc' SCROLLING='no'>\n" +
        "  <FRAME NAME='buttonFrame' marginheight='5'
SRC='javascript:parent.opener.ButtonDoc'>\n" +
        "</FRAMESET>\n" +
        "</HTML>";

    top.PopupWin2 = window.open("", 'jWindow' , 'width=300,height=200,resizable');
    top.PopupWin2.document.write(theFrameset);
    top.PopupWin2.focus();
}

// WRITE THE TOP FRAME
function writeMyFrame() {
   alert("Open the doc");
    top.PopupWin2.topFrame.document.open();
    alert("write the frame \n " + TopDoc);
var newTopDoc = "Writing in frame.";
    top.PopupWin2.topFrame.document.write(newTopDoc );
    alert("Close the Doc");
    top.PopupWin2.topFrame.document.close();
}

function doNothing() {
}
//End of Javascript code
(Reporter)

Comment 1

16 years ago
This bug does not exist in NS4.7x, neither on Windows nor Unix.But the bug
exists in NS6.x (up to NS6.2.1). Therefore, it seems to be a regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8

Comment 2

16 years ago
Please fix this ASAP. We are desperate to see this bug to be fixed. Our 
customer is waiting for this.
Severity: critical → blocker
Priority: P2 → P1

Comment 3

16 years ago
Browser, not engine. Reassigning to Security: General component -
Assignee: rogerl → mstoltz
Component: JavaScript Engine → Security: General
QA Contact: pschwartau → bsharma
(Reporter)

Comment 4

16 years ago
Mitchell, is there a work around for this problem, if it seems a long wait for
the fix? 
(Reporter)

Comment 5

16 years ago
I played around the test case a little bit, and found out that the calling of
writeMyFrame inside TopDoc seemed the be the trouble spot. If I moved the call
from Topdoc to the HTML file, then it seemed working OK. Would that offer any
clue?


The modified test case:

======= Test HTML file:
<HTML>
<HEAD>
<title> Test Case for Netscape 6 JavaScript Write() problem </title>
<SCRIPT LANGUAGE="JavaScript" SRC="writeTest.js">

</SCRIPT>
</HEAD>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" ALINK="#FF0000"
VLINK="#FF0000">

<H4><FONT FACE="Arial, Helvetica">Test Case for Netscape 6.2 JavaScript Write()
problem</FONT></H4>

<P><FORM ACTION="" METHOD=POST name=aForm>
       <A HREF="javascript:doNothing()"  
          onclick="createFrame('My Title')">>&nbsp;&nbsp;1. Popup a frame set
window&nbsp;&nbsp;
       </A>
<P>
       <A HREF="javascript:doNothing()"
          onclick="writeMyFrame()">>&nbsp;&nbsp;2. Write to top
frame&nbsp;&nbsp;
       </A>
</FORM></P>


</BODY>

</HTML>


======= Test JavaScript code:

// Beginning of Javascript code.
var newTopDoc="Top Frame updated"
var TopDoc = "<HTML><HEAD></HEAD>" +
        "<BODY>\n" +
        "<FORM NAME='myControl' onSubmit='return false;'>\n" +
        "<CENTER>\n" +
        "<TABLE CELLPADDING=0 CELLSPACING=1 BORDER=0><TR>\n" +
        "<TD COLSPAN=7>\n" +
        "<CENTER>\n" +
        "<td><nobr>Top Frame</nobr></td>" +
        "</CENTER>\n" +
        "</TD>\n" +
        "</TR>\n" +
        "</TABLE>\n" +
        "</CENTER>\n" +
        "</FORM>\n" +
        "</BODY>\n" +
        "</HTML>";

var ButtonDoc   = "<HTML><HEAD></HEAD>" +
         "<BODY>" +
         "<FORM NAME='myControl2' onSubmit='return false;'>\n" +
         "<TABLE CELLPADDING=0 CELLSPACING=1 BORDER=0><TR>" +
         "<TD COLSPAN=7>\n" +
         "<CENTER>\n" +
         "<td><nobr>Bottom Frame</nobr></td>" +
         "</CENTER>\n" +
         "</TD>\n" +
         "</TR>" +
         "</TABLE>" +
         "</CENTER>\n" +
         "</FORM>\n" +
         "</BODY>" +
         "</HTML>";

// POPUP A WINDOW AND BUILD THE FRAMESET
function createFrame(s_winTitle) {
    var theFrameset = "<HTML><HEAD><TITLE>" +
        s_winTitle + "&nbsp&nbsp&nbsp&nbsp</TITLE>" +
        "</HEAD>\n" +
        "<FRAMESET ROWS='80,*' FRAMEBORDER='0'>\n" +
        "  <FRAME NAME='topFrame' marginheight='5' SRC='javascript:parent.opener
.TopDoc' SCROLLING='no'>\n" +
        "  <FRAME NAME='buttonFrame' marginheight='5' SRC='javascript:parent.ope
ner.ButtonDoc'>\n" +
        "</FRAMESET>\n" +
        "</HTML>";

    top.PopupWin2 = window.open("", 'jWindow' , 'width=300,height=200,resizable'
);
    top.PopupWin2.document.write(theFrameset);
    top.PopupWin2.focus();
}

// WRITE THE TOP FRAME
function writeMyFrame() {
    alert("Open the doc");
    top.PopupWin2.topFrame.document.open();
    alert("write the frame \n " + TopDoc);
    top.PopupWin2.topFrame.document.write(newTopDoc );
    alert("Close the Doc");
    top.PopupWin2.topFrame.document.write(newTopDoc );
    alert("Close the Doc");
    top.PopupWin2.topFrame.document.close();
}

function doNothing() {
}
// End of Javascript code.
(Assignee)

Comment 6

16 years ago
I think I've found what's causing this, but I need to investigate further. It
seems that when document.open is called on a page which was created as the
result of evaluating a javascript: URL, the principal of the page (which should
be the principal of the page that supplied the URL) is not being carried over.
I'm working on a fix. In the meantime, the best workaround I can think of is to
make the source of TopFrame be an actual HTML file, not a javascript URL. THis
will avoid the problem.
Status: NEW → ASSIGNED

Comment 7

16 years ago
As I see the check for the "same origin" policy fails because the objects has
two different schemas of origin: "javascript t" and "http".

The check for the access to XPC fails because the JS code is not signed and not
request the enhanced capabilities.
(Assignee)

Comment 8

16 years ago
Right, but the principal should almost never be "javascript:". That's where the
bug is. Both principals should be http.

Comment 9

16 years ago
As I see, the follow way can be used:

If document was created by the  javascript code (as it is in our case) the we
need to create codebase principals for such kind of documents by using the
origin of the javascript code which has generate the document (the JS code has
the http origin), not the URI of the document.

Am I correct?
(Assignee)

Comment 10

16 years ago
I'm working on a fix for the problem now, but I just found a super-easy
workaround. Just don't call document.open(). Calling document.write without
first calling open() calls open() implicitly, and doing it that way avoids the
problem.
(Assignee)

Comment 11

16 years ago
Created attachment 67299 [details] [diff] [review]
Patch - allow cross-host access to HTMLDocument.write

This patch changes the HTMLDocument.write method to allAccess, meaning it can
be called on any window by any window regardless of code origin. I believe this
is safe, because the write function changes the principal of the target page to
that of the calling script. jst et al, do you agree that this is safe?
(Assignee)

Updated

16 years ago
Whiteboard: patch
Yeah, seems safe to me, but we should do the same for HTMLDocument.writeln too.
*** Bug 93600 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Whiteboard: patch → patch [eapp]
Comment on attachment 67299 [details] [diff] [review]
Patch - allow cross-host access to HTMLDocument.write

sr=jst with the same done for document.writeln
Attachment #67299 - Flags: superreview+

Comment 15

16 years ago
Comment on attachment 67299 [details] [diff] [review]
Patch - allow cross-host access to HTMLDocument.write

r=fabian with jst's comment
Attachment #67299 - Flags: review+
(Assignee)

Comment 16

16 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 17

16 years ago
Verified on 2002-02-21-Trunk on WinNT

Ran above test cases. The frame is loaded fine and the alert is shown.
No exception in the JS console.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.