Closed Bug 122317 Opened 23 years ago Closed 23 years ago

Javascript write to frame failed due to permission denied

Categories

(Core :: Security, defect, P1)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: joe.chou, Assigned: security-bugs)

References

Details

(Whiteboard: patch [eapp])

Attachments

(1 file)

Patch - allow cross-host access to HTMLDocument.write
648 bytes, patch
fabian
: review+
jst
: superreview+
Details | Diff | Splinter Review 
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
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
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
Browser, not engine. Reassigning to Security: General component -
Assignee: rogerl → mstoltz
Component: JavaScript Engine → Security: General
QA Contact: pschwartau → bsharma
Mitchell, is there a work around for this problem, if it seems a long wait for
the fix? 
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.

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
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.
Right, but the principal should almost never be "javascript:". That's where the
bug is. Both principals should be http.
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?
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.
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?
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. ***
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 on attachment 67299 [details] [diff] [review]
Patch - allow cross-host access to HTMLDocument.write

r=fabian with jst's comment
Attachment #67299 - Flags: review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.

Attachment

General

Creator:
Created:
Updated:
Size: