Note: There are a few cases of duplicates in user autocompletion which are being worked on.

writes to non-existent location.* properties permitted across domains




10 years ago
6 years ago


(Reporter: Michal Zalewski, Assigned: jst)


1.8 Branch
Bug Flags:
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:low] fixed on trunk by XOW)



10 years ago

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: = '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.

Component: Security → DOM
Product: Firefox → Core
QA Contact: firefox → general
Version: 2.0 Branch → Trunk
Version: Trunk → 1.8 Branch
This behavior follows from location being defined as allAccess as opposed to other similar properties (like history) where only the getter is allAccess.,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
Whiteboard: [sg:dupe 361961] fixed on trunk by XOW → [sg:low] fixed on trunk by XOW
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

6 years ago
This was fixed by XOW (bug 367911).
Group: core-security
Last Resolved: 6 years ago
Depends on: 367911
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.