W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: The HTTP Origin Header (draft-abarth-origin)

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 24 Jan 2009 10:20:20 -0800
Message-ID: <7789133a0901241020i31d4d83eu8f3424ffeffa99a9@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: ietf-http-wg@w3.org

On Sat, Jan 24, 2009 at 8:44 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Adam Barth wrote:
>>I was trying to make the point that Web sites cannot rely on the
>>Referer header to build a CSRF defense.
>
> I believe that point is somewhere between misleading and incorrect, but
> for the sake of argument let me make this point instead: Web sites can-
> not rely on the Origin header to build a CSRF defense.

Why is that?  I missed the argument that supports this claim.  It
seems that sites can use the Origin header to defend themselves
against CSRF by implementing the following three mod_security rules:

SecRule REQUEST_HEADERS:Host !^www\.example\.com(:\d+)?$ deny,status:403
SecRule REQUEST_METHOD ^POST$ chain,deny,status:403
SecRule REQUEST_HEADERS:Origin !^(https?://www\.example\.com(:\d+)?)?$

A user who visits such a site with a supporting user agent (which, at
the moment, includes the Chrome dev channel and the WebKit nightlies)
will be protected from CSRF attacks.  A site can implement these rules
without impacting users of non-supporting user agents.

> Now I'd like to
> know how your point can reasonably believed to be correct, but my point
> reasonably believed to be incorrect, at some point within the next seven
> years.

Which mod_security rules should a Web site implement to use the
Referer header as a CSRF defense without locking out some of its
users?

Adam
Received on Saturday, 24 January 2009 18:20:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:00 GMT