W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] TAG request concerning CORS & Next Step(s)

From: Mark S. Miller <erights@google.com>
Date: Wed, 24 Jun 2009 22:12:37 -0700
Message-ID: <4d2fac900906242212u16573434y2f1dffa8a59ee338@mail.gmail.com>
To: Adam Barth <w3c@adambarth.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 8:46 PM, Adam Barth <w3c@adambarth.com> wrote:

> My understanding is that the CORS use of the Origin header is mostly
> to protect the confientiality of resources on the server.  For
> example, if (1) the server wishes to reveal a particular piece of
> information to some origins by not to others and (2) the server does
> not wish to reveal the list of allowed origins to everyone, then the
> server can use the Origin header to make the access control decision
> on the server.
>

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? As
security architects, shouldn't we promote mechanisms that encourage
securable patterns of use?



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

-- 
   Cheers,
   --MarkM
Received on Thursday, 25 June 2009 05:13:16 GMT

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