As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 91043 - document.write while another page is loading can bypass same-origin check
: document.write while another page is loading can bypass same-origin check
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 Windows NT
: P1 major (vote)
: mozilla1.4final
Assigned To: Mitchell Stoltz (not reading bugmail)
: bmartin
: David Keeler [:keeler] (use needinfo?)
Depends on:
Blocks: blackbird
  Show dependency treegraph
Reported: 2001-07-16 19:25 PDT by Jesse Ruderman
Modified: 2009-07-09 18:34 PDT (History)
17 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

demo (917 bytes, text/html)
2001-07-16 19:26 PDT, Jesse Ruderman
no flags Details
Patch - make document.write(ln) same-origin access only (841 bytes, patch)
2001-07-18 19:43 PDT, Mitchell Stoltz (not reading bugmail)
no flags Details | Diff | Splinter Review
Patch 2 - ignore the last one. (703 bytes, patch)
2001-07-18 19:51 PDT, Mitchell Stoltz (not reading bugmail)
pavlov: review+
dveditz: superreview+
asa: approval+
Details | Diff | Splinter Review
testcase showing innerHTML is working fine (985 bytes, text/html)
2002-11-14 17:12 PST, Sivakiran Tummala
no flags Details

Description User image Jesse Ruderman 2001-07-16 19:25:37 PDT
document.write is currently allAccess.  If an attacker can time a document.write
to fire while an HTML document from another site is loading, he can insert
whatever code he wants into the other document, and Mozilla will assume that
code came from the other site.

Possible fixes:

1. Make document.write be sameOrigin.  Web scripts will then have to explicitly
call if they want to write a new document in a window they don't
currently own.

2. Make the document.write code check who's calling it.  If the caller's
principal doesn't match the target document's principal, call to
create a new document owned by the attacker, or deny access.

I vote for 1, because it's simpler and seems less likely to lead to confusing
problems.  Note that IE doesn't allow access to document.write *or* in another domain.
Comment 1 User image Jesse Ruderman 2001-07-16 19:26:47 PDT
Created attachment 42507 [details]
Comment 2 User image Bradley Baetz (:bbaetz) 2001-07-16 23:36:54 PDT
document.write has code to stop this - see bug 32088, revision 3.207 in
nsHTMLDocument.cpp. Why is this failing?

Can this be turned into a universalXPConnect vulnerabilty in combination with
bug 88087? I couldn't trigger it, but I'll try on a 133Mhz machine tomorrow.
Comment 3 User image Jesse Ruderman 2001-07-18 12:38:21 PDT
Netscape 4 allows access to document.write across domains, but IE doesn't.  So 
if we blocked access to document.write across domains, we would be breaking 
compatibility only with Netscape 4.

By the way, Netscape 4 crashes if I try to test for this security hole.  I guess 
it isn't vulnerable...
Comment 4 User image Mitchell Stoltz (not reading bugmail) 2001-07-18 19:43:47 PDT
Created attachment 42804 [details] [diff] [review]
Patch - make document.write(ln) same-origin access only
Comment 5 User image Mitchell Stoltz (not reading bugmail) 2001-07-18 19:51:17 PDT
Created attachment 42806 [details] [diff] [review]
Patch 2 - ignore the last one.
Comment 6 User image Jesse Ruderman 2001-07-18 19:55:16 PDT
Comment 7 User image John Bandhauer 2001-07-18 19:59:47 PDT
Comment 8 User image Mitchell Stoltz (not reading bugmail) 2001-07-19 14:28:37 PDT
Checked in on trunk. Adding vtrunk. I would like to get this onto the branch.
Comment 9 User image selmer (gone) 2001-07-19 18:01:33 PDT
ckritzer: pls verify on trunk builds when available.
Comment 10 User image selmer (gone) 2001-07-19 18:09:01 PDT
PDT+ per pdt mtg w/mstoltz
Comment 11 User image Mitchell Stoltz (not reading bugmail) 2001-07-19 18:24:41 PDT
Fixed on branch.
Comment 12 User image ckritzer (gone) 2001-07-19 19:29:21 PDT
Okay, this bug is VERIFIED FIXED on:

Win98SE 2001-07-19-09-trunkMacOS91 2001-07-19-08-trunk
LinRH62 2001-07-19-08-trunk

And since Mitch checked into the branch tonight, I will verify tomorrow's branch
bits when they are available.
Comment 13 User image ckritzer (gone) 2001-07-20 14:05:37 PDT
MacOS91 2001-07-20-06-0.9.2
Win98SE 2001-07-20-03-0.9.2
LinRH62 2001-07-20-04-0.9.2

Comment 14 User image Gayatri Rimola 2002-11-12 13:57:39 PST
Nominating since this is a regression from Mach V.
Comment 15 User image Daniel Veditz [:dveditz] 2002-11-12 16:47:30 PST
Seems to crash in layout now, after the exploit has already run.
Comment 16 User image Michael Buckland 2002-11-13 10:42:51 PST
Mitch can you say if you think this is required for Blackbird?
Comment 17 User image Mitchell Stoltz (not reading bugmail) 2002-11-13 15:16:46 PST
Yes, I think this should be required for Blackbird.

It looks like I solved the problem originally by making same-origin access only. Then, in bug 122317, I made
them allAccess again, because the restriction was breaking some convoluted JS
usage in a Siebel app - I had forgotten about the security implications at the
time (doh).

The quick, easy fix is to check in the above patch again, which simply adds a
few lines to the security prefs. However, that will break the Siebel app again.
Security is more important in this case, but I would at least like to explore
some alternatives before we break them again. If I can't get any information
before the end of the day, I'll change the prefs back.
Comment 18 User image Mitchell Stoltz (not reading bugmail) 2002-11-13 15:55:13 PST
OK, the Siebel issue has a quick workaround - we will work with Evangelism to
see that they get the message. In the menatime, let's check in the above patch
again. It removes the security prefs for document.write and writeln, which will
make them default to sameOrigin.

Can I get r/sr for removing those prefs?
Comment 19 User image Mitchell Stoltz (not reading bugmail) 2002-11-13 16:01:23 PST
We should probably get this into 1.2 as well...
Comment 20 User image Asa Dotzler [:asa] 2002-11-13 16:18:54 PST
Comment on attachment 42806 [details] [diff] [review]
Patch 2 - ignore the last one.

a=asa for checkin to the 1.2 branch (on behalf of drivers)
Comment 21 User image Daniel Veditz [:dveditz] 2002-11-13 16:40:29 PST
adt approval for the 1.0.2 branch, please get drivers approval and check in tonight.
Comment 22 User image Daniel Veditz [:dveditz] 2002-11-13 16:54:20 PST
Comment on attachment 42806 [details] [diff] [review]
Patch 2 - ignore the last one.

Comment 23 User image Mitchell Stoltz (not reading bugmail) 2002-11-13 17:15:00 PST
verbal a=chofmann for 1.0 branch.
Comment 24 User image Daniel Veditz [:dveditz] 2002-11-14 03:17:36 PST
Mitch checked this into the 1.0 branch earlier tonight.
Comment 25 User image bsharma 2002-11-14 14:55:56 PST
Verified on 2002-11-14-branch build.
The crash is still happening. The crash happens after a while now but it still
consistently happens.

    Steps to reproduce:
    1. Open the demo page from the bug report.
    2. Click on the first button. This will open the new window with large file,
which will keep on loading.
    3. Come back to the demo page and click on the next two buttons one after
the other, nothing happens.
    4. Go back to that large page and it is still loading. Come back to the demo
page and click on the last two buttons again for couple of time. The crash will
happen after 10 seconds or so.

    Please let me know if you need more details.
Comment 26 User image Jimmy Lee 2002-11-14 15:54:43 PST
Removing fixed1.0.2 keyword to get on radar.  I can reproduce what Bindu is seeing.
Comment 27 User image Gayatri Rimola 2002-11-14 16:11:42 PST
Mitch, can you please give us a test case which does not use innerHTML since
that is crashing and Bindu can't verify the fix with confidence. Since the bug
has been re-opened in the branch, add back the fixed1.0.2 keyword when you
provide the test case. Thanks.
Comment 28 User image Sivakiran Tummala 2002-11-14 17:11:34 PST
Does not look it is a problem with innerHTML, tested with build:
2002-11-14-09-1.0 Attaching a testcase to demonstate innerHTML is working
properly. And i could not reproduce the crash.
Comment 29 User image Sivakiran Tummala 2002-11-14 17:12:31 PST
Created attachment 106298 [details]
testcase showing innerHTML is working fine
Comment 30 User image Mitchell Stoltz (not reading bugmail) 2002-11-14 22:56:19 PST
I think the crash is a separate bug, independent of the security problem, and
not a stop-ship. harishd is working on the crash and has filed a separate bug.
For now, we can ignore the crash. What to look for is the alert() produced by
the testcase. The testcase should not produce an alert(), but rather an
exception in the JS console. If that's the case, the security bug is fixed. I'm
putting this back to fixed1.0.2; please call me if you're still having trouble
Comment 31 User image bsharma 2002-11-15 15:57:48 PST
Verified on 2002-11-14-branch build on Win2000.

The demo page loads with the exception for each document.write in the JS console.
Comment 32 User image Ben M. 2003-03-21 15:29:52 PST
This is odd... The browser security check at is saying my copy of Mozilla 1.3 still
has this vurnerability.
Is it wrong?
Comment 33 User image Marek Stępień [:marcoos, inactive] 2003-03-28 15:16:36 PST
I have 0/0/0 errors on while using yesterday's nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030327

Comment 34 User image Flo C 2003-04-10 07:37:42 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
has the vulnerability according to the test at 

Still there with the latest nightly build of Phoenix:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030409 Phoenix/0.5+
Comment 35 User image Lucky Pozzo 2003-04-10 12:35:25 PDT
I went through the browser security test at and it showed this bug. Using Mozilla
1.3 on Redhat 8.0
Comment 36 User image Sam Hulick 2003-04-17 12:20:00 PDT
confirmed.. this security issue is present on builds as late as 2003041704
Comment 37 User image Johnny Stenback (:jst, 2003-04-17 13:16:43 PDT
Reopening to make sure this gets re-checked.
Comment 38 User image Mitchell Stoltz (not reading bugmail) 2003-05-09 12:39:51 PDT
Or we could just wait for Godot, Lucky :)
Comment 39 User image Chris Brooking 2003-05-14 01:48:15 PDT
Just tested on Mozilla 1.4b
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030507
bug still present.
Comment 40 User image Mitchell Stoltz (not reading bugmail) 2003-05-15 17:47:02 PDT
I don't believe this bug is still present. The document.write function is still
same-origin access only, and both the original testcase attached to this bug and
the testcase come up negative for me. I can't see the source of the test, since it doesn't stay loaded long enough to grab the source, but
my guess is that the test on that site is flawed.

I'm marking the bug Fixed, but I'd like to get some redundant verification.
Brent or Charles, could you please try the testcase mentioned above, and the
testcase attached to this bug?

Johnny, do you see any suspicious behavior still occurring?
Comment 41 User image Alla Bezroutchko 2003-05-19 07:24:53 PDT
I think there was a timing condition in test. It
might have caused false positives. Now I think I fixed it. According to my
testing 1.4b is not vulnerable, neither is 1.3a, or 1.2.1. 

1.1 is vulnerable. Did not test other versions.

Sorry for the confusion caused by the test.

Here is how I test now:

win ="http://otherdomain/test-moz91043bis.php");
// This window contains a document from another domain that takes
// long time to load
var j = setInterval("catchme()", 100);

function catchme() {
        try {
                var a = win.document.title; // Test if the window is
                                         // still in our domain
        } catch (e) { // Window is not in our domain anymore
                try {
                } catch (e) {

Comment 42 User image tangalanga 2009-07-09 15:32:19 PDT
Sorry, i have Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.9.2a1pre) Gecko/20090708 Minefield/3.6a1pre  and the same bug appeared in
Comment 43 User image Daniel Veditz [:dveditz] 2009-07-09 18:34:34 PDT
Not sure what you're talking about. The (very) old version of the test in the "old-bcheck" directory does have a test for this bug, but all recent versions of Mozilla browsers pass those tests.

Note You need to log in before you can comment on or make changes to this bug.