Re: Isolated Origins

On Wed, Apr 26, 2017 at 10:31 AM, David Ross <drx@google.com> wrote:

> 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.
>
>
Hmm, I don't think we can support having subframes in a different
StoragePartition than their parent page.  That's hard to implement and hard
to reason about.

I would strongly prefer to prevent iframing isolated sites if we can.
While Alex is right that you could treat the iframed version as a different
origin with a different StoragePartition than when loading it in the main
frame (which is what we did in the old isolated sites
<http://www.chromium.org/developers/design-documents/isolated-sites>
project), it made things confusing and potentially harder to secure, as
Artur noted.


>
> 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.
>>
>
Agreed-- it should be origin wide and not settable via <meta>, in order for
Chrome's process model to know which process and StoragePartition to use
before the page is committed.

Charlie


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