9111 - generated document URI should be different from generator

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P4)

Description

[Brendan Eich [:brendan]]

document.open (also write with implicit open) looks in the JSContext to find its
global window object's location, which it imputes to the generated document.
This is insecure if the calling context's global object has a location different
from the origin (codebase principals) of the script calling document.open, which
can happen if evil.org stuffs a pointer to its function in the onload property
of a victim window.

I think norris is gonna fix this as far as security goes by using the calling
frame's principals, which came from the compiler when it processed the scripted
function that's calling document.open or write.

Leaving security aside and turning to the DOM level 0 question here: what should
the generated document's URI (window.location, document.URL) be?  It seems to me
it ought to be a generated URI that uniquely identifies the document, and that
relates it to the generator's origin.  That was the intent of the unlamented
wysiwyg: URL type from MozillaClassic, whose implementation was sadly buggy in
numerous ways.  Is the concept sound?  Can we do better in Mozilla 5?  I think
it's worth a shot.  At the least, it avoids "hall of mirros" reload hazards!

/be

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

This is _so_ not beta.  Norris, are you willing to take this bug and do the Hard
Thinking about what this URI should look like?

Comment 2

[vidur (gone)]

In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Comment 3

[Norris Boyd]

Is this is a valid test case?

<script>
w = window.open("about:blank");
w.document.write("<script>alert(document.location);<\/script>");
</script>

Gets an alert of the location of the first window. What's a test case where it
should be different from the generator?

Comment 4

[Brendan Eich [:brendan]]

The generated doc's location should be related to the generator's, but it should
not be the same, or "hall-of-mirrors" effects due to some code (ours or the page
author's JS) reloading document.location.

(No, I don't propose wysiwyg: URLs as the solution!)
/be

Comment 5

[Johnny Stenback (:jst)]

This wont happen for M15 unless someone tells me what the generated URI should
be, moving to M16 for now.

Comment 6

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 7

[ekrock's old account (dead)]

cc:ing mstoltz for assessment of severity of security issues. mstoltz--would you
please advise whether you think we must nsbeta3+? Thanks!

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Minor security risk here. In Norris's code above, window "w" keeps the location
about:blank, and the corresponding principal. If some (legitimate) site used
code like Norris's to generate a page containing sensitive data, the principal
of that page would continue to be about:blank, which means that the contents of
the page are readable by scripts from anywhere. I'm not sure how common this
situation is (pages generated by script and containing sensitive data), but it
seems to me we should fix it. I recommend nsbeta3+. 

We can fix it by resetting the document's principal to be that of the calling
function as part of document.open. Principals correspond to
protocol://hostanme:port. For sake of correctness, we should also reset
document.location, although this is trickier since it means coming up with some
newly generated URL with the hostname of the calling function.

Comment 9

[Nisheeth Ranjan]

Re-assigning bug to Mitch.  Please triage this according to your priorities, 
Mitch.  jst is overloaded with beta3+ bugs.

Comment 10

[Patrick C. Beard]

escalating, but low priority.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

The security aspect of this bug has been fixed, by bug 32088. Reassigning to the
DOM folks and clearing nsbeta3+ for re-evaluation. I would assume the remaining
issue is not beta3 material, but the issue remains as to what the URL (the
location property and what's displayed in the url bar) should be for generated
documents.

Comment 12

[Nisheeth Ranjan]

Eric, re-assigning this to you.  This will fall out of the work you are doing on 
wysiwyg: urls.

Comment 13

[Kevin McCluskey (gone)]

Marking nsbeta3- based on Mitchell Stoltz's comments that the security aspect of
this bug has been fixed.

Comment 14

[Oliver Klee]

Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.

Comment 15

[Péter Bajusz]

Clearing very old milestone (M16) in hope of reevaluation.

Comment 16

[Kevin McCluskey (gone)]

From Nisheeth's comment when the fix for bug 35340 lands this will be fixed so I
am marking this bug fixed.

Comment 17

[Eric Pollmann]

Actually marking fixed.

Comment 18

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old