Re: Isolate-Me explainer

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.

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