Closed Bug 9111 Opened 21 years ago Closed 19 years ago

generated document URI should be different from generator


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






(Reporter: brendan, Assigned: pollmann)




(Keywords: dom0, Whiteboard: [nsbeta3-]) (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, which
can happen if 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 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!

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?
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Is this is a valid test case?

w ="about:blank");

Gets an alert of the location of the first window. What's a test case where it
should be different from the generator?
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!)
This wont happen for M15 unless someone tells me what the generated URI should
be, moving to M16 for now.
Target Milestone: M15 → M16
M16 has been out for a while now, these bugs target milestones need to be 
cc:ing mstoltz for assessment of severity of security issues. mstoltz--would you
please advise whether you think we must nsbeta3+? Thanks!
Keywords: nsbeta3
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 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.
Re-assigning bug to Mitch.  Please triage this according to your priorities, 
Mitch.  jst is overloaded with beta3+ bugs.
Assignee: vidur → mstoltz
escalating, but low priority.
Priority: P3 → P4
Whiteboard: [nsbeta3+]
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
Assignee: mstoltz → jst
Whiteboard: [nsbeta3+]
Eric, re-assigning this to you.  This will fall out of the work you are doing on 
wysiwyg: urls.
Assignee: jst → pollmann
Marking nsbeta3- based on Mitchell Stoltz's comments that the security aspect of
this bug has been fixed.
Whiteboard: [nsbeta3-]
Milestone 0.8 has been released. We should either resolve this bug or update its
Keywords: dom0
Clearing very old milestone (M16) in hope of reevaluation.
Target Milestone: M16 → ---
From Nisheeth's comment when the fix for bug 35340 lands this will be fixed so I
am marking this bug fixed.
Actually marking fixed.
Closed: 19 years ago
Resolution: --- → FIXED
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.