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

On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Wed, 24 Jun 2009 13:29:38 +0200, Arthur Barstow <Art.Barstow@nokia.com>
> wrote:
>
>> 1. Please respond to at least this part of Henry's mail:
>>
>> [[
>> It appeared to us that a number of significant criticisms of the
>> appropriateness of CORS have been submitted to the Working Group, from
>> respected members of the Web Security community among others. These
>> convinced us that there is a real possibility either that server-side
>> deployment won't happen, or that even if it did the new functionality
>> provided would, on the one hand, be insufficiently secure while, on the
>> other, discouraging the provision of something more satisfactory.
>> ]]
>>
>
> I think the potential for security issues has been pointed out in the
> alternate proposals, not CORS itself. CORS has certainly not been found to
> be ideal, but something more satisfactory to all parties involved has not
> been proposed either. I would also classify the outstanding issues against
> CORS as minor.
>
> Having said that, if there is something in particular you are thinking of
> it would be nice to explicitly point that out (and in case that email
> received a reply it would be good to point out why that reply did not
> address the point in question).
>

As is widely recognized, CSRF is a form of confused deputy attack <
http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html>. From the beginning,
the diagnosis of the underlying problem leading to confused deputies is the
use of ambient authority rather than designated authority[1].   The
introduction of the CORS identified Origin header mechanism is justified as
a way to mitigate confused deputies. This not only fails to address the
underlying problem, it amplifies it by introducing yet another form of
ambient authority -- identified Origins which servers are expected to use to
make access control decisions.

The current prevelent practice for avoid CSRF problems is the "secret token"
defense. This is a form of designated authority, and can be used correctly
to avoid confused deputies. The main (only?) argument against it seems to be
that it is accident prone -- that it can be and has been used badly, thereby
failing to protect against confused deputies. This criticism is correct. It
would be wonderful if a sound safer alternative were known. However, what we
are offered in its place -- identified Origins -- can only be used correctly
by not using it to make access control decisions.

Adam is aware of this problem. When pressed, he agrees that identified
Origin only reduces the frequency of confused deputy problems, without
providing the developer any clear line between patterns that are safe and
those that are not. Is it progress to reduce the frequency of holes while
leaving these holes undiagnosable?

Adam, if I have not summarized your position accurately, please correct.
Thanks.

>
>
>
>  2. For those that have been active in defining the CORS model and/or CORS
>> implementers - particularly Adam, Anne, Jonas, Hixie, Maciej, IE guys
>> (whomever replaced Sunava) - please indicate:
>>
>> a) their level of interest in continuing to push the current CORS model;
>>
>
> I'm happy to continue as editor.
>
>
>  b) their implementation plans for CORS.
>>
>
> I cannot comment on behalf of Opera on this. I can point out that Safari 4
> and Chrome 2 ship with it and that Firefox 3.5 will too. (No implementation
> will support redirects yet though, as I understand things.) Internet
> Explorer 8 supports a subset of the protocol.
>

IIUC, the XDR subset IE8 supports does not include identified Origin or
preflight, and so avoids most of the problems created by full CORS. However,
it still presents user credentials (http auth, cookies, client-side certs,
referer), and so still has many of the same remaining ambient authority
problems. Nevertheless, it remains a more plausible starting point than
identified Origin.

An earlier proposal, JSONRequest <http://www.json.org/JSONRequest.html>,
which IIRC you dismissed for being non-RESTful, presents no user credentials
or preflight by design. Like CORS, it was originally speced to present the
originating page's Origin. But JSONRequest has since dropped that explicitly
in order to avoid introducing new sources of ambient authority. Given that
CORS makes RESTful programming too expensive to remain practical, it is
ironic that JSONRequest was dropped for being non-RESTful.



[1] See for example the section on confused deputy in <
http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf>. I thought David Wagner's Google
techtalk explained "ambient authority" especially clearly <David Wagner's
Google techtalk>. Tyler's "ACLs Don't" <David Wagner's Google techtalk>
explains well how these problems translate into a web context. Kragen
Sitaker's <
http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html> is
still worth reading for more than historic interest. Nine years later, we
are still discussing "defenses" that don't address the original problem.

-- 
   Cheers,
   --MarkM