Re: Isolate-Me explainer

On Tue, Sep 20, 2016 at 12:12 AM, Crispin Cowan <crispin@microsoft.com>
wrote:

> I still think there is an understanding gap between what John is thinking
> about, and what crispin and chrome/Emily are thinking about.
>
>
>
> For me, site isolation has *identical* semantics to the Same Origin
> Policy. The difference is:
>
> ·         In browsers today, the SoP is enforced by the browser content
> process. If you RCE the browser, you can just lie about the origin of a
> hypothetical nested iFrame in your page and access any cookies or state you
> want.
>
> ·         In site isolation, *every* origin is in a separate sandbox, and
> a cookie broker outside the sandbox provides cookies to each sandbox, in
> accordance with the SoP. If you RCE a sandbox, you only win access to
> yourself, no other origins.
>
> ·         In Isolate-Me, any site that opts in to isolate-me is as
> isolated as it would be in pure site isolation. In contrast, sites that do
> *not* opt in to isolate-me get rendered in a cesspool J of other sites,
> and if any of them get RCE’d, then everyone in the cesspool is vulnerable
> to having their state disclosed.
>
>
>
> Emily please confirm if this is also your understanding.
>

That's close to what I'm thinking but I want to make a couple caveats:
- We've been thinking of Isolate-Me as a useful signal that the browser
might use to turn on site isolation, but not by any means a guarantee to
the site that it will get its own process. The browser might be able to
provide process isolation to an Isolate-Me site: for example the browser
might not implement site isolation at all, or the browser might be out of
resources to provide a separate process, etc.
- Your second point ("you only win access to yourself, no other origins")
is not, according to my understanding, completely accurate. Even if site
isolation is fully turned on, sites are still allowed to make cross-origin
requests. So if an attacker RCEs an evil.com process, the attacker could
issue a cross-origin request to (hypothetically)
https://www.facebook.com/my_profile_image.jpg, which would be authenticated
with the victim's cookies and return the victim's facebook profile photo to
the compromised evil.com process. I believe there are some restrictions
planned to limit the scope of the damage (for example, I think the
compromised evil.com process will not be allowed to make an authenticated
request to https://www.facebook.com and read the response) but there will
still be ways that cross-origin information can leak.


>
>
> In contrast, I think John means more than that by “single trust”, but I am
> not at all sure of that. John, please comment.
>
>
>
> *From:* wilander@apple.com [mailto:wilander@apple.com]
> *Sent:* Monday, September 19, 2016 3:05 PM
> *To:* Artur Janc <aaj@google.com>
> *Cc:* Emily Stark (Dunn) <estark@google.com>; public-webappsec@w3.org;
> Mike West <mkwst@google.com>; Joel Weinberger <jww@google.com>; Tanvi
> Vyas <tanvi@mozilla.com>
> *Subject:* Re: Isolate-Me explainer
>
>
>
>
>
> On Sep 19, 2016, at 2:38 PM, Artur Janc <aaj@google.com> wrote:
>
>
>
> On Mon, Sep 19, 2016 at 10:55 PM, John Wilander <wilander@apple.com>
> wrote:
>
>
>
> On Sep 16, 2016, at 8:15 AM, Emily Stark (Dunn) <estark@google.com> wrote:
>
>
>
> Hi webappsec! Mike, Joel, and I have been discussing an idea for a
> developer facing opt-in to allow highly security- or privacy-sensitive
> sites to be isolated from other origins on the web.
>
>
>
> We wrote up the idea here to explain what we're thinking about, why we
> think it's important, and the major open questions: https://mikewest.gi
> thub.io/isolation/explainer.html
>
>
>
> Please read and comment/criticize/etc. Thoughts welcome, either here in
> this thread or as GitHub issues. Especially interested to hear from Mozilla
> folks as it relates to and is heavily inspired by containers.
>
>
>
> Interesting! This is more or less what we proposed under the name *single
> trust* at the face-to-face. I have been asking Mike to bring into Secure
> Contexts v2. :)
>
>
>
> We believe this would not only be good for site security but could also
> allow more powerful APIs which is why we thought Secure Contexts is a good
> fit. You could envision security sensitive features such as
> auto-fill/auto-login to only be available in single trust.
>
>
>
> Hey John,
>
>
>
> Note that, at least currently, some of the main goals of the proposal deal
> with preventing the exploitation of common classes of Web vulnerabilities
> (XSS, CSRF, cross-origin data leaks). These are orthogonal to the issue of
> single trust, because you can have a "single trust" application that is
> logically completely self-contained, but on the current web attackers can
> interact with it by force by navigating to arbitrary endpoints, sending
> messages (postMessage), setting arbitrary cookies (e.g. with an XSS on an
> other subdomain or by an HTTP MitM), etc.
>
>
>
> The security gain of Emily's isolation proposal lies in protecting an
> application from unwanted interactions from the outside, rather than
> enforcing restrictions on components that the application itself wishes to
> load. In practice, attacks on webapps generally don't come from such
> trusted components, and for places where this is a concern there are
> already other solutions such as SRI or sandbox frames. Because of this, the
> most promising aspect of the recent isolation proposals (including
> Mozilla's Containers) is the ability to prevent unrelated, external sites
> from affecting the state of the protected application -- and personally, I
> have high hopes for this kind of approach.
>
>
>
> That makes it more clear. Thanks!
>
>
>
> Then our proposal of single trust stands as is, clearly geared toward “If
> you want this privileged thing you cannot pull in arbitrary sub resources
> because the user puts his/her trust in you and you only.” Seems to go well
> along with site isolation too.
>
>
>
> I’d love for all authentication pages to be single trust. Dream scenario
> being the password input type is only available for single trust pages. :)
>
>
>
>    Regards, John
>
>
>
>
>
> Cheers,
>
> -Artur
>
>
>
> Or the ability to talk to localhost as has been discussed here at length.
>
>
>
> The reason we have discussed this as single trust is the academic research
> done in *mixed trust*. Browsers only show a green bar/padlock for the top
> frame domain where in reality there could be a hundred other organizations
> the user is implicitly trusting through sub resource and sub frame loads
> and redirects. Hence, mixed trust.
>
>
>
> This naturally leads us to one of the other proposals we brought up at the
> face to face – *associated domain*s. Under §4. Isolation Policy you bring
> up the fact that sensitive sites still might want to interact with or
> include third party content. But such content may not really be from a
> third party but from a different domain owned by the same organization – an
> associated domain. The host is simply a poor differentiator of first and
> third party. If we could come up with a safe way to declare ownership
> and/or control we could allow associated domains to cooperate while being
> isolated from the rest of the world.
>
>
>
>    Regards, John
>
>
>