RE: Isolate-Me explainer

Inline comments

From: Emily Stark (Dunn) [mailto:estark@google.com]
Sent: Tuesday, September 20, 2016 5:29 PM
To: Crispin Cowan <crispin@microsoft.com>
Cc: wilander@apple.com; Artur Janc <aaj@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 Tue, Sep 20, 2016 at 12:12 AM, Crispin Cowan <crispin@microsoft.com<mailto: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 ☺ 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.
[Crispin ] Hmmm. That strikes me as equivalent to HTTPS only suggesting that the channel should be encrypted, and it might not. I would suggest that isolate-me needs to be mandatory, else it presents a severe risk of the illusion of security.

- 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<http://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<http://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<http://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.
[Crispin ] Sorry, I was being imprecise. When I said “access to yourself, no other origins”, I should have said “access to yourself and other origins that SoP says you should have access to”, e.g. all of the global cookies and stuff that has been granted to your origin.



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> [mailto:wilander@apple.com<mailto:wilander@apple.com>]
Sent: Monday, September 19, 2016 3:05 PM
To: Artur Janc <aaj@google.com<mailto:aaj@google.com>>
Cc: Emily Stark (Dunn) <estark@google.com<mailto:estark@google.com>>; public-webappsec@w3.org<mailto:public-webappsec@w3.org>; Mike West <mkwst@google.com<mailto:mkwst@google.com>>; Joel Weinberger <jww@google.com<mailto:jww@google.com>>; Tanvi Vyas <tanvi@mozilla.com<mailto:tanvi@mozilla.com>>
Subject: Re: Isolate-Me explainer


On Sep 19, 2016, at 2:38 PM, Artur Janc <aaj@google.com<mailto:aaj@google.com>> wrote:

On Mon, Sep 19, 2016 at 10:55 PM, John Wilander <wilander@apple.com<mailto:wilander@apple.com>> wrote:

On Sep 16, 2016, at 8:15 AM, Emily Stark (Dunn) <estark@google.com<mailto: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.github.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 domains. 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