Re: [webappsec] Rechartering: Sub-Origins

David,

 I think this is a very interesting approach to some of what I was
aiming at elsewhere in charter discussions, e.g. isolating social
widgets from impacting the containing resource.

 But I think what suborigins aims at is protecting a resource that has
opted-in to a label from being interfered with by other vulnerable
content that would be otherwise be considered same-origin without it.

 The threat model is a bit more like applying synthetic origins to
secure the traditional university setup of giving people their own
webroot at "/~username" than it is trying to isolate deliberately
imported JS modules.  (the latter is an important threat, probably
more important in my non-chair opinion, but a different threat)

-Brad

On Mon, Nov 10, 2014 at 2:46 PM, David Bruant <bruant.d@gmail.com> wrote:
> Le 10/11/2014 20:31, Michal Zalewski a écrit :
>>
>> The basic reasoning behind suborigins is to provide a very simple,
>> intuitive, and low-cost way to compartmentalize applications, reason
>> about the compartmentalization, and test it with automated tools.
>>
>> If I understand it correctly, your critique is that suborigins are a
>> bad idea because application compartmentalization can be achieved with
>> a bit more work with existing tools.
>
> My concern is more that this is yet another step toward finer-grain
> identity-centric access control. At this game, we've seen cookies fail,
> we've seen SOP fail, we've seen the Origin header fail.
> I'm willing to bet we'll see suborigins fail because for the same reasons.
>
>> But I think this applies to most
>> other mechanisms: we also do not strictly require CSP or referer
>> directives or most of the other security work. Almost all of its is
>> driven by the desire to just make things simpler, more intuitive, less
>> likely to fail, and easier to audit for.
>
> If one cares about security not coming at the price of performance (and
> "performance is a feature" - Ilya Grigorik), then CSP and referer directives
> are needed as part of the platform. CSP to only run trusted inline scripts
> (for the critical path), referer directives to avoid redirects (roundtrips
> are expensive especially on mobile).
>
> But suborigins do not fall into this category.
>
>> We're definitely acutely aware of Caja and similar solutions and have
>> spent years trying to convince product teams to use it in a variety of
>> settings :-) I *think* that suborigins will strictly improve status
>> quo and has a chance of working out, but of course, no promises.
>
> I'd be interested in hearing more. What was the resistance related to? Is it
> Google-only feedback?
> I'd love to see other authors and implementors express interest (in this
> thread or other standard mailing-list. I wasn't at TPAC, so maybe this
> interest was expressed there). Until then, it looks a bit like a Google-only
> thing. Well... Worst case, you'll just have wasted time working on this
> feature. Your decision, I guess.
>
> Note that I used Caja as an example, but I don't mind if something lighter
> is created. For instance, a library that only does code isolation could be
> enough in lots of cases:
>     isolate(code, sandbox);
> code is a string, sandbox an object playing the global object role.
> The "isolate" function can be written in maybe 100 lines of ES6 code (to
> describe the sandbox. The code loader is already part of ES6). Can be more
> than 100 lines of course depending on how subtle you want to get. The
> fallback is just to load the code normally (which is equivalent to suborigin
> fallback for browsers that ignore the Suborigin header).
> Among the benefits of this approach is that the communication between 2
> isolated components doesn't have to go through postMessage (with data copy
> and all). Functions can be called normally.
> Has this been considered by the product teams who were relunctant to Caja?
>
> David

Received on Monday, 10 November 2014 23:09:10 UTC