- From: Tyler Close <tyler.close@gmail.com>
- Date: Thu, 17 Dec 2009 10:41:49 -0800
- 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 UTC