W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [webappsec] Rechartering: Sub-Origins

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Mon, 10 Nov 2014 16:28:33 -0800
Message-ID: <CALx_OUDHdzpD89S-9xKaR89OnkXk2ry5ZYacwBhi00L_5g3L_w@mail.gmail.com>
To: David Bruant <bruant.d@gmail.com>
Cc: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Mark S. Miller" <erights@google.com>
> 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 think this conflates a lot of things... cookies are an ancient
mechanism and it's certainly hard to call it "finer-grained" by
comparison with any other browser security mechanism. Further, it's
probably a bit bold to proclaim the failure of cookies and SOP - they
have a lot of interesting properties and failure modes, but they kind
of make the web work.

The Origin header is an odd creature and I'm not actually sure what
problem the current implementations try to solve. It can be used as a
very limited XSRF protection and it certainly works OK for that
purpose, albeit with limited browser support.

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

How so? In the context of XSS and most other types of content
policing, CSP is "unnecessary" if we can have developers consistently
leverage proper templating systems or even have them follow basic
engineering practices or run code checking tools on their apps.

Referer directives - likewise, referer stripping can be achieved with
little or no performance or complexity impact in most scenarios using
a relatively simple hack.

> I'd be interested in hearing more. What was the resistance related to? Is it
> Google-only feedback?

Anecdotally... I think it was some combination of having to:

- Refactor existing code to avoid certain coding patterns that are
incompatible with Caja,
- Having to follow less-familiar and perhaps more cumbersome design
practices within new code,
- Added complexity / failure modes / dependencies / learning curve for
already incredibly complex apps.

Now, most of these also apply for CSP, although perhaps to a more
limited extent.

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

It's certainly not my decision :-) I think the main reason why
suborigins are (seemingly) being pursued is that there has been a fair
amount of external interest when this was first proposed by Adam Barth
and others some time ago.

/mz
Received on Tuesday, 11 November 2014 00:29:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC