Re: Isolated Origins

>
> 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.


+1  It's going to be hard enough to defend attacks from evil.com -->
isolated.com.  It will be even harder to defend against attacks that
involve the non-isolated version of the origin as well as the isolated
version.

An admin interface or a banking UI would be the typical use case for
isolated origins.  The choice to use an isolated origin would be driven by
a desire to avoid XSS and XSRF that are otherwise pervasive issues on the
web, but with more severe consequences for admins / banking users in
particular.  I think these users would be just as concerned with
clickjacking.  Maybe it would make sense to do two things:

   - In isolated origins, change the X-Frame-Options / frame-ancestors
   default behavior to disable framing by default.  HTTP responses from an
   isolated origin would still be able to opt-in to framing using X-F-O /
   frame-ancestors.
   - Once an origin is isolated, always present the isolated version of the
   origin the user.  Even in framing scenarios.

This approach would avoid the problem Artur pointed out, but also provide
enough flexibility to an isolated origin so they can support specific usage
scenarios requiring frame-ability.


On Wed, Apr 26, 2017 at 5:28 AM, Artur Janc <aaj@google.com> wrote:

> 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
>>>>
>>>
>>
>