Closed
Bug 412781
Opened 17 years ago
Closed 13 years ago
writes to non-existent location.* properties permitted across domains
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: lcamtuf, Assigned: jst)
References
Details
(Whiteboard: [sg:low] fixed on trunk by XOW)
Hi,
It is possible for page in domain A in possession of a window handle of frame / window in domain B, to set arbitrary non-existent location.* values, for example: third_party_window.location.foo = 'whatever'.
This is probably an unnecessary side channel, and could theoretically become an attack vector against any site that relies upon a location.* property or method that is not implemented in Firefox but supported elsewhere (and hence would not be protected), or simply got mistyped.
Cheers,
/mz
Updated•17 years ago
|
Component: Security → DOM
Product: Firefox → Core
QA Contact: firefox → general
Version: 2.0 Branch → Trunk
Updated•17 years ago
|
Version: Trunk → 1.8 Branch
Comment 1•17 years ago
|
||
This behavior follows from location being defined as allAccess as opposed to other similar properties (like history) where only the getter is allAccess.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libpref/src/init/all.js&rev=3.717&mark=286-288,301#280
This is presumably because in addition to needing to _get_ it to be able to set its properties like .hash and .href, we can also legitimately _set_ location's value directly.
This is fixed on the trunk by Cross-origin wrappers (XOW). There are still regressions we're hammering out but we'd eventually like to land XOW on the 1.8 branch as well to stop issues like this.
Off the top of my head I'm not overly worried about sites using this as a communication channel--there are other ways they could cooperate if they wanted, either server-to-server, using Firefox3's cross-site XHR, funky url-parameter tricks, etc. Without XOW, though, this can be leveraged into a XSS attack (see bug 361961).
Group: security
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.13?
Whiteboard: [sg:dupe 361961] fixed on trunk by XOW
Updated•17 years ago
|
Whiteboard: [sg:dupe 361961] fixed on trunk by XOW → [sg:low] fixed on trunk by XOW
Comment 2•17 years ago
|
||
Given that we're implementing postMessage() on the trunk we're probably not too concerned about the information-passing aspect of this. The fact that the property can be any doctored object, though, could lead to nasty surprises on sites who were storing things on the Location object. Does anyone actually do that? Hixie could do a search perhaps.
Assignee: nobody → jst
Flags: blocking1.8.1.13?
Comment 3•13 years ago
|
||
This was fixed by XOW (bug 367911).
Group: core-security
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: xow
Resolution: --- → FIXED
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•