- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 24 Jun 2009 22:28:37 -0700
- To: "Mark S. Miller" <erights@google.com>
- Cc: Anne van Kesteren <annevk@opera.com>, Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>, Henry Thompson <ht@inf.ed.ac.uk>
On Wed, Jun 24, 2009 at 10:12 PM, Mark S. Miller<erights@google.com> wrote:
> The server can sensibly wish to reveal a particular piece of information to
> those parties that it thinks should be authorized to learn that information.
> Without assuming your conclusion, why should the server wish to identify
> those parties with ambient origins rather than designated secret tokens?
One reason is to avoid the hassle of sharing secret tokens.
How exactly do you envision secret tokens working? Suppose Google
Finance wants to let Acme Finance XHR for stock ticker information.
How does Acme Finance get the secret tokens? Presumably Acme has to
use a fresh token for each request so that Bob's Finance can't just
grab Acme's token from their home page. Now, for each request, Acme
Finance has to contact Google Finance on the backend and get a token.
Sounds like a pain.
By contrast, CORS makes this use case super easy.
> As security architects, shouldn't we promote mechanisms that encourage
> securable patterns of use?
I don't consider myself a security architect.
>> It is progress to reduce to the frequency of CSRF vulnerabilities.
>
>
> // in two threads concurrently
> loop {
> repeat 100 times {}
>
> //unprotected critical section begins
> *p += 1;
> //unprotected critical section ends
> }
>
> If we change the number of repetitions in the nested loop from 100 to 1000,
> we reduce the frequency with which this race condition bug corrupts the
> program. Is this progress?
I don't see the connection to what we're discussing. There's no
randomness in CSRF. In any case, this part of the discussion is a bit
off topic. The TAG asked about CORS, not CSRF.
Adam
Received on Thursday, 25 June 2009 05:29:37 UTC