W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 7 Jan 2013 17:23:12 -0800
Message-ID: <CAJE5ia8ewpQxBZH_C_JutOCNH+D60MLqQT8cDyso5vsaDcs07g@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: whatwg <whatwg@lists.whatwg.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Maybe this got sorted out later in this thread, but I believe that's
what WebKit does.

Adam


On Sat, Dec 15, 2012 at 5:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> An "easy" solution would be to just return null for .contentDocument
> in the case of cross-origin iframes.
>
> / Jonas
>
> On Sat, Dec 15, 2012 at 10:43 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> Ccing whatwg because that's where the whole "origin" thing is currently
>> defined.
>>
>> Consider this testcase:
>>
>> <iframe src="http://w3.org"></iframe><script>
>> window.onload = function () {
>>   try {
>>     var doc = document.querySelector("iframe").contentDocument;
>>     var list = document.getElementsByTagName.call(doc, "*");
>>     alert(list.item(0).textContent);
>>   } catch (e) {
>>     alert(e);
>>   }
>> }</script>
>>
>> This throws in Safari, Chrome, Firefox, and Opera, all on the
>> "getElementsByTagName.call" bit (except when loaded via file:// in Safari,
>> in which case it actually lets you read all data from random website in the
>> iframe).
>>
>> But I see nothing in the specs that requires this behavior, or indeed even
>> allows it.  The security bits currently in the html spec talk about property
>> access on cross-origin Document and Window, but in this case there is no
>> property access happening on them per se...
>>
>> In any case, this needs to be defined somewhere.
>>
>> -Boris
Received on Tuesday, 8 January 2013 01:24:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT