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

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

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 24 Jun 2009 20:46:09 -0700
Message-ID: <7789133a0906242046j4b79358bxe0f34b9a8340532f@mail.gmail.com>
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 6:39 PM, Mark S. Miller<erights@google.com> wrote:
> On Wed, Jun 24, 2009 at 8:14 AM, Anne van Kesteren <annevk@opera.com> wrote:
> 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.

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.

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

The Sec-From header (the new name of Origin-for-CSRF-defense) helps
servers operators mitigate CSRF vulnerabilities using web application
firewall rules.  It is progress to reduce to the frequency of CSRF
vulnerabilities.

Adam
Received on Thursday, 25 June 2009 03:47:15 GMT

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