Closed Bug 9111 Opened 21 years ago Closed 19 years ago
generated document URI should be different from generator
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
Target Milestone: M15
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? <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?
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
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 updated.
cc:ing mstoltz for assessment of severity of security issues. mstoltz--would you please advise whether you think we must nsbeta3+? Thanks!
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.
Re-assigning bug to Mitch. Please triage this according to your priorities, Mitch. jst is overloaded with beta3+ bugs.
Assignee: vidur → mstoltz
Status: ASSIGNED → NEW
escalating, but low priority.
Priority: P3 → P4
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.
Assignee: mstoltz → jst
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.
Milestone 0.8 has been released. We should either resolve this bug or update its milestone.
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
mass remove verifyme requests greater than 4 months old
You need to log in before you can comment on or make changes to this bug.