- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 24 Jan 2009 10:20:20 -0800
- 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 UTC