Closed Bug 289675 Opened 19 years ago Closed 19 years ago
getter/setter on window
.__proto __.__proto __.__proto __ allows XSS attacks
1.24 KB, text/html
4.29 KB, patch
|Details | Diff | Splinter Review|
4.17 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Getter/setter defined on window.__proto__.__proto__.__proto__ is executed when a global variable is used in scripts, but is not cleared when a new page is loaded. Therefore allows XSS attacks. Testcase available. Reproducible: Always Steps to Reproduce: 1.define getter/setter on window.__proto__.__proto__.__proto__ with some name. 2.navigate the browser to the page that uses a global variable with a name defined in step 1. Actual Results: Getter/setter defined in step 1 will be evaluated in the context of a new page. Expected Results: Getter/setter defined in step 1 must be cleared when loading a new page. Or, do not allow web pages to poison window.__proto__.__proto__.__proto__.
testcase for the bug.
Confirming. If you set browser.dom.global_scope_pollution.disabled to true (undoing the IE compat fixes in bug 256932) you can still do this, but using only two __proto__ instead of three.
Assignee: general → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
That is the last object on the prototype chain, namely Object.prototype. We should be resetting that to a new one created for a new Object ctor on new doc load, of course. /be
OS: Windows 98 → All
Hardware: PC → All
Not sure when or how this broke, didn't have time to dig into that yet. But the problem is that XPConnect is unable to find Object.prototype when we're re-initializing a context (i.e. during page transition), so it ends up using the old one it had. That's bad, and there was code that printed out a warning for that, but I hadn't been observant enough to notice that. I turned on that code for everyone now to hopefully catch this earlier if it happens again. So this patch makes it so that we can resolve standard classes during context re-initialization. Pretty straight forward.
Comment on attachment 180219 [details] [diff] [review] Make context re-initialization work right again. a=chase/drivers pending r/sr
Comment on attachment 180219 [details] [diff] [review] Make context re-initialization work right again. r=bzbarsky.
Attachment #180219 - Flags: review?(bzbarsky) → review+
Comment on attachment 180219 [details] [diff] [review] Make context re-initialization work right again. I think that NS_WARNING should be an NS_ERROR. Is that going to turn tinderbox orange? If so, we still have a potential security hole. /be
Attachment #180219 - Flags: superreview?(brendan) → superreview+
r=dveditz too, but get rid of the NS_WARNING and uncomment the NS_ERROR
jst checked in to the aviary branch
Whiteboard: [sg:fix] → [sg:fix] needed trunk and 1.7 branch
Fixed on the 1.7 branch too.
Whiteboard: [sg:fix] needed trunk and 1.7 branch → [sg:fix] needed trunk
Whiteboard: [sg:fix] needed trunk → [sg:fix] needed trunk - Hold private until April 25,2005
landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [sg:fix] needed trunk - Hold private until April 25,2005 → [sg:fix] Hold private until April 25,2005
This caused some pretty weird (though possibly correct) code flow during context init. I filed bug 295606 on that.
Depends on: 295606
Comment on attachment 181440 [details] [diff] [review] trunk version of what got checked in this patch was applied in cenzic hailstorm 2.6 against mozilla/ -mozilla1.8a5 and js/ -mozilla1.8b1
You need to log in before you can comment on or make changes to this bug.