Re: Sandboxed iframes (was Re: Seamless iframes + CSS3 selectors = bad idea)

@Ian

Starting from abarth message:
http://sla.ckers.org/forum/read.php?13,31377#msg-31430

Anyway, maybe I misunderstood what he said, I thought he meant in chrome it
was a new and exclusive origin (different from the parent one) and my tests
sort of confirmed that.

On firefox for example, the origin is something a little weird (that is
probably the same maciej just explained). where you have a different origin
but access to parent/opener..

So well..

Greetings!!
-- Eduardo
http://www.sirdarckcat.net/



On Sun, Dec 6, 2009 at 10:04 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Dec 6, 2009, at 2:30 AM, Ian Hickson wrote:
>
>  On Sun, 6 Dec 2009, Maciej Stachowiak wrote:
>>
>>> On Dec 6, 2009, at 1:38 AM, Ian Hickson wrote:
>>>
>>>> On Sun, 6 Dec 2009, sird@rckc.at wrote:
>>>>
>>>>>
>>>>> ian, isnt allow-same-origin confusing? since if its same origin what
>>>>> stops you from linking it and bypassing those protections.
>>>>>
>>>>
>>>> allow-same-origin is only really intended to be used with the
>>>> aforementioned doc="" attribute idea (eventually) and data: URIs (in
>>>> the meantime). The example you mention is indeed misleading.
>>>>
>>>
>>> It seems like a data: URI would not do the trick, since it already has a
>>> unique origin, so allow-same-origin would not do what it is intended to.
>>> I believe you would have to document.write() into the iframe's content
>>> document (after loading about:blank), or load it with a javascript: URI
>>> containing a constant string.
>>>
>>
>> The origin of a data: Document is the same as its parent browsing
>> context's Document's origin.
>>
>
> It does look like HTML5 says something like that.
>
> WebKit uses unique origins for data: URIs, which I think Gecko used to do
> as well, but it looks like they have changed. It's a security hole to use
> the parent's origin, if you can cause navigation to a data: URI in a frame
> in a different-origin parent.
>
> What HTML5 actually says is somewhat different from what you stated above:
>
> "If a Document or image was generated from a data: URL found in another
> Document or in a script
>    The origin is the origin of the Document or script in which the data:
> URL was found."
>
> Taken literally this rule does not seem practically implementable. UAs
> would have change their JavaScript implementations to tag every JavaScript
> string value with an origin, to keep track of where it was found if it gets
> passed cross-origin (e.g. via postMessage). It's also possible for data:
> URLs not to be found in any script or document, if they are created by
> script in appending multiple strings or taking user input.
>
> What Firefox seems to do is give a data: URL frame the same origin as the
> frame that initiated navigating it to that data: URL. That seems like a
> secure and implementable rule.
>
> Regards,
> Maciej
>
>