Last Comment Bug 412781 - writes to non-existent location.* properties permitted across domains
: writes to non-existent location.* properties permitted across domains
[sg:low] fixed on trunk by XOW
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 1.8 Branch
: All All
-- minor (vote)
: ---
Assigned To: Johnny Stenback (:jst,
: Andrew Overholt [:overholt]
Depends on: xow
  Show dependency treegraph
Reported: 2008-01-17 08:07 PST by Michal Zalewski
Modified: 2011-07-25 13:31 PDT (History)
10 users (show)
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Michal Zalewski 2008-01-17 08:07:04 PST

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.

Comment 1 User image Daniel Veditz [:dveditz] 2008-01-18 18:14:12 PST
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).
Comment 2 User image Daniel Veditz [:dveditz] 2008-02-15 11:48:06 PST
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.
Comment 3 User image Jesse Ruderman 2011-07-25 13:31:23 PDT
This was fixed by XOW (bug 367911).

Note You need to log in before you can comment on or make changes to this bug.