Re: Defining secure-enough origins.

On Fri, Aug 22, 2014 at 4:03 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 8/22/14, 9:58 AM, Mike West wrote:
>
>> Frames can be navigated to 'about:blank' across origins (via
>> window.opener, for instance).
>>
>
> Sure.  So for about:blank the origin is what matters.  And for sandboxed
> about:blank you're really not quite sure where it came from, is that the
> issue?


Ok. I see your point. We'd allow 'about:blank' for non-sandboxed frames
because it inherits the origin. Why wouldn't we then allow it for sandboxed
frames.

That's a fair question. I don't think there's a relevant difference between
those cases. We should treat them the same.

Using location won't work, as you've noted. Walking up the chain in a
similar way to about:srcdoc would work.


> Frames can't be navigated to an effective
>> 'about:srcdoc' (I think).
>>
>
> Well, by setting the srcdoc attribute on the iframe, right?  Is the claim
> that this is ok because only code that's same-origin with the iframe
> element can do that?  But I thought we were talking about transports, not
> origins...


If an insecure origin could modify the content of a secure origin by
setting the srcdoc attribute, that would be bad. Happily, I don't think
that can happen.

An insecure origin that's opened by a secure origin can navigate the
opener's frames to about:blank, which, if you squint, means that those
'about:blank' frames weren't securely transported. I'm not sure there's
much impact to this, as the HTTP origin can't populate that frame. Still.

A better example of that situation comes up with content that's been
postMessage'd into an HTTPS frame from an HTTP origin (which happens on
about 0.1% of page loads according to
http://www.chromestatus.com/metrics/feature/popularity#PostMessageFromInsecureToSecure
).

-mike

Received on Friday, 22 August 2014 14:22:32 UTC