This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21674 - Security: Spec doesn't match reality for named access to cross-origin frames
Summary: Security: Spec doesn't match reality for named access to cross-origin frames
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 critical
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard: Hixie, see direct e-mail 15371538
Keywords:
: 23218 (view as bug list)
Depends on: 20701
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-12 06:50 UTC by Bobby Holley (:bholley)
Modified: 2017-03-09 08:32 UTC (History)
7 users (show)

See Also:


Attachments

Description Bobby Holley (:bholley) 2013-04-12 06:50:39 UTC
HTML5 says that the dynamic nested browsing context properties are available cross-origin on Window, but that appears to be indexed access only, not named frame access.

I just put together a testcase: http://people.mozilla.com/~bholley/testcases/cross-origin-named-window/test.html

This testcase returns true in Firefox, Safari, Chrome, Opera (Presto), and IE9. I don't have a copy of IE10 lying around, but it would be good if someone checked that.

Do we have a reason to believe that the current spec is web-compatible here?
Comment 1 Ian 'Hixie' Hickson 2013-04-13 17:11:31 UTC
This is just an oversight in the spec.

Extra questions:
- Are they enumerable?
- Are named properties other than child browsing context names accessible?
- If not, are they distinguishable from names that otherwise don't exist?

(I can test this if you don't have the bandwidth to, but since you've already made a cross-origin test case, you might be able to get answers quicker than me!)
Comment 2 Bobby Holley (:bholley) 2013-04-13 18:36:57 UTC
(In reply to comment #1)
> This is just an oversight in the spec.
> 
> Extra questions:
> - Are they enumerable?

I updated the testcase a little bit to poke on this. Looks like they're not in Chrome/Safari, but it's a bit tricky to determine this from script in Gecko, because enumerating a cross-origin window seems to throw a security exception. I'm pretty sure it didn't used to, so I'm going to look into that.

> - Are named properties other than child browsing context names accessible?

As mentioned on IRC, I think it would be a major security problem if they were.
Comment 3 Daniel Veditz 2013-04-16 06:09:24 UTC
With the updated testcase IE 10 seems to have the same results as Firefox: the script throws an access error on line 9. On Chrome I get an alert with the results "Cross-Origin Named Frame Access Works: true\nEnumerable: false".
Comment 4 Bobby Holley (:bholley) 2013-04-16 15:26:31 UTC
(In reply to comment #3)
> With the updated testcase IE 10 seems to have the same results as Firefox:
> the script throws an access error on line 9. On Chrome I get an alert with
> the results "Cross-Origin Named Frame Access Works: true\nEnumerable: false".

I've filed [1] for this. Hixie, can you confirm my interpretation of the spec behavior on that bug?

https://bugzilla.mozilla.org/show_bug.cgi?id=862380
Comment 5 Ian 'Hixie' Hickson 2013-06-03 23:31:55 UTC
Bobby, can you summarise what you think should change in the spec for this?
Comment 6 Bobby Holley (:bholley) 2013-08-09 21:46:26 UTC
(In reply to comment #5)
> Bobby, can you summarise what you think should change in the spec for this?

Sorry for the delay here.

Named subframes should be cross-origin accessible just like indexed subframes (they're essentially a property of the browsing context). They are not enumerable, because cross-origin windows are not enumerable.
Comment 7 Boris Zbarsky 2013-08-09 21:51:26 UTC
Hmm.  Does getOwnPropertyNames show them?  Named subframes are normally own props of the NamedPropertiesObject, but in the cross-window access case it's not clear to me whether they should appear to be own properties of the WindowProxy or not.
Comment 8 Boris Zbarsky 2013-08-09 21:52:56 UTC
Largely because the spec doesn't actually define what things like getOwnPropertyDescriptor and Object.getPrototypeOf() should do on the WindowProxy in a way that's compatible with exposing the named subframes (and arguably not in any way at all, because afaict a strict reading of the spec would allow getting the proto cross-origin which can't possibly be the intention).
Comment 9 Ian 'Hixie' Hickson 2013-10-01 20:53:58 UTC
*** Bug 23218 has been marked as a duplicate of this bug. ***
Comment 10 Anne 2016-01-18 12:20:54 UTC
Okay, it seems that in order to fix this we should turn "the browsing context name of any child browsing context of the active document whose name is not the empty string" into its own thing so that it can be referenced both by the Window's named properties definition and by the set of properties available cross-origin.

Does that make sense?

https://github.com/annevk/html-cross-origin-objects should then take care of the rest.
Comment 11 Bobby Holley (:bholley) 2016-01-19 20:40:44 UTC
Superficially, that sounds fine. My opinion as of the last time I thought about this issue in detail is summarized in comment 6.