W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

From: Tyler Close <tyler.close@gmail.com>
Date: Thu, 17 Dec 2009 10:41:49 -0800
Message-ID: <5691356f0912171041x2e5ae314p593117a35119a224@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Kenton Varda <kenton@google.com>, Adam Barth <w3c@adambarth.com>, Jonathan Rees <jar@creativecommons.org>, "Mark S. Miller" <erights@google.com>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Thu, Dec 17, 2009 at 10:08 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> My goal was merely to argue that adding an origin/cookie check to a
> secret-token-based mechanism adds meaningful defense in depth, compared to
> just using any of the proposed protocols over UM. I believe my argument
> holds. If the secret token scheme has any weakness whatsoever, whether in
> generation of the tokens, or in accidental disclosure by the user or the
> service consumer, origin checks provide an orthogonal defense that must be
> breached separately. This greatly reduces the attack surface. While this may
> not provide any additional security in theory, where we can assume the
> shared secret is generated and managed correctly, it does provide additional
> security in the real world, where people make mistakes.

The reason the origin/cookie check doesn't provide defense in depth is
that the programming patterns we want to support necessarily blow
holes in any origin/cookie defense. We want clients to act as
deputies, because that's a useful thing to be able to do. For example,
consider a web page widget that implements the Observer pattern: when
its state changes, it fires off a POST request to a list of observer
URLs. Clients can register any URL they want with the web page widget.
If these POST requests carry origin/cookies, then a CSRF-like attack
is easy.

There are lots of other ways we want to use the Web, as it is meant to
be used, that aren't viable if you're trying to maintain the viability
of an origin/cookie defense. For example, Ian correctly points out
that under an origin/cookie defense, using URIs as identifiers is
dangerous, see:

http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1247.html

But we want to use URIs to identify things, because its useful, and we
want it to be safe. For cross-origin scenarios, it can't be safe while
still maintaining the viability of origin/cookie defenses.

Basically, the programming patterns of the Web, when used in
cross-origin scenarios, break origin/cookie defenses. We want to keep
the Web programming patterns and replace the origin/cookie defense
with something that better fits the Web. We're willing to give up our
cookies before we'll give up our URIs.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Thursday, 17 December 2009 18:42:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT