Re: [webappsec] Rechartering: Sub-Origins

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 22:46:49 UTC