21674 2013-04-12 06:50:39 +0000 Security: Spec doesn't match reality for named access to cross-origin frames 2017-03-09 08:32:03 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All RESOLVED MOVED Hixie, see direct e-mail 15371538 P2 critical Unsorted 20701 1 bobbyholley ian annevk bzbarsky contributor dveditz ian mike w3c contributor oldest_to_newest 86017 0 bobbyholley 2013-04-12 06:50:39 +0000 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? 86141 1 ian 2013-04-13 17:11:31 +0000 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!) 86145 2 bobbyholley 2013-04-13 18:36:57 +0000 (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. 86270 3 dveditz 2013-04-16 06:09:24 +0000 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". 86294 4 bobbyholley 2013-04-16 15:26:31 +0000 (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 88595 5 ian 2013-06-03 23:31:55 +0000 Bobby, can you summarise what you think should change in the spec for this? 91852 6 bobbyholley 2013-08-09 21:46:26 +0000 (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. 91853 7 bzbarsky 2013-08-09 21:51:26 +0000 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. 91854 8 bzbarsky 2013-08-09 21:52:56 +0000 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). 94117 9 ian 2013-10-01 20:53:58 +0000 *** Bug 23218 has been marked as a duplicate of this bug. *** 124618 10 annevk 2016-01-18 12:20:54 +0000 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. 124638 11 bobbyholley 2016-01-19 20:40:44 +0000 Superficially, that sounds fine. My opinion as of the last time I thought about this issue in detail is summarized in comment 6. 124652 12 annevk 2016-01-20 15:25:19 +0000 https://github.com/whatwg/html/pull/544