Re: Isolated Origins

On Wed, Apr 26, 2017 at 4:07 AM, Emily Stark <estark@google.com> wrote:

> On Tue, Apr 25, 2017 at 3:27 PM, Alex Russell <slightlyoff@google.com>
> wrote:
>
>> A few questions:
>>
>>    - The note about needing to process Isolation before cookies is
>>    interesting. Does it mean that this won't be possible to do from a <meta>
>>    tag equivalent?
>>
>> Quite possibly, yeah. I unfortunately don't see how we can make this play
> nicely with meta tags; if the page sets cookies before it goes into
> isolated mode, those cookies won't be accessible.
>

+1, I'd rather not attempt to make isolated origins work with <meta>
because it seems like a can of worms. One of the ideas that appeals to me
is to consider the isolation bit conceptually similar to HSTS where
isolation would be a property of the entire origin, in which case setting
it from <meta> would likely not fit that model.

For something like isolated origins I'd expect that the concern about the
difficulty of setting response headers compared to <meta> wouldn't be a big
concern because it's meant for the most highly sensitive applications where
developers need to be able to set headers anyway to control other security
features.


>
>>    - What's the issue with isolation and iframing? I'd have thought that
>>    one of the valuable aspects of double-keying is protection from iframing.
>>    That is, you can run your main service as isolated and if anyone iframes
>>    you, the isolation won't be invoked (you'll be in the main storage
>>    container) and therefore that "version" simply won't have ambient authority.
>>
>> Hmm, this could probably be made to work. One concern I have is whether
> it makes double-keying not enough and we actually need to key by the whole
> frame tree. If isolated1.com frames isolated2.com which makes a
> cross-origin request to blah.com, do the cookies for blah.com need to be
> triple-keyed? I think they might need to be to be consistent with the
> threat model.
>
> (Also, this makes me realize that we didn't write anything in the spec
> about double-keying storage other than cookies; that needs to be addressed.
> Oops.)
>

Does double-keying storage imply considering [isolated.com] and [
isolated.com iframed by foo.com] to be separate origins, i.e. not being
able to have direct DOM access to each other?

If yes, it's probably not too bad, but I'm worried that bugs in the
isolated origin would still be damaging even in the double-keyed world. For
example, let's say isolated.com has an XSS which is normally not
exploitable because of isolation; if the origin is reachable when iframed
under foo.com then the XSS still executes under isolated.com and can send
messages as that origin (perhaps safe.non-isolated.com trusts messages from
isolated.com), show prompts with the browser UI displaying "isolated.com"
as the origin, etc. It seems like it might be preferable not to have to
worry about this class of problems.


>
>>    - I'd love a solution to opener disownership that's generic.
>>
>> Can you clarify this? I don't understand.
>

Alex, the CSP3 draft has https://w3c.github.io/webappse
c-csp/#directive-disown-opener which might be what you're looking for? FWIW
I'd agree with the note in the spec and this bug
<https://github.com/w3c/webappsec-csp/issues/194> that this needs some more
deliberation.


>
>>    - I'm not sure I understand the serviceworker integration points. If
>>    the behavior of isolation is double-keying when isolated, doesn't this just
>>    imply that these are parallel (separate) SW registrations?
>>
>> I don't think I understand this question either. The point of the SW
> integration is that a SW from the isolated origin must explicitly allow
> navigations to the isolated origin, and they'll fail otherwise. Does that
> clarify it at all?
>
>
>> Thanks!
>>
>> On Tuesday, April 25, 2017, Emily Stark <estark@google.com> wrote:
>>
>>> On the last call, I mentioned that I would send out an "Isolate-Me"
>>> draft. This is a proposal for a mechanism by which an origin can opt in to
>>> isolate itself from other web content -- probably most useful for
>>> high-value security-critical applications that are willing to give up some
>>> functionality for such isolation.
>>>
>>> Please take a look at this faint ghost of a spec that aims to explain
>>> the threat model more and nail down what these isolation mechanisms are:
>>> https://wicg.github.io/isolation/index.html
>>>
>>> Any comments or feedback, either here or in the GitHub repo, would be
>>> very welcome.
>>>
>>> David Ross (cc'ed) might also want to share some thinking he's done
>>> about alternative shapes for the part of the proposal that deals with
>>> navigation restrictions.
>>>
>>> Thanks!
>>> Emily
>>>
>>
>