- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 13 Jan 2009 14:39:28 -0800
- To: "Adam Barth" <w3c@adambarth.com>
- Cc: "Anne van Kesteren" <annevk@opera.com>, public-webapps@w3.org, "Maciej Stachowiak" <mjs@apple.com>, "Sam Weinig" <weinig@apple.com>
On Tue, Jan 13, 2009 at 10:02 AM, Adam Barth <w3c@adambarth.com> wrote: > On Tue, Jan 13, 2009 at 7:31 AM, Anne van Kesteren <annevk@opera.com> wrote: >> On Tue, 13 Jan 2009 01:31:49 +0100, Jonas Sicking <jonas@sicking.cc> wrote: >>> My suggestion is to rename "Origin" to "Access-Control-Request-Origin" >>> or "Access-Control-Origin" if possible (depends on where current >>> implementers are in their ship schedule), or that we request that the >>> CSRF protection header be renamed to something other than "Origin". >> >> I'm fine with renaming it to Access-Control-Request-Origin as far as the >> Access Control draft is concerned. >> >> Maciej, Sam, Adam? > > I agree with Thomas that having two headers that are the same in the > common case will lead to author confusion and server vulnerabilities. > > One possibility is to change the Origin-header-for-CSRF-protection to > behave identically as the Origin-header-for-cross-site-XHR (i.e., > don't set it to "null" on cross-origin redirects). This would mean a > site couldn't use the header for CSRF protection if it generates POST > requests to untrusted sites. I suspect this is fairly rare (although > I don't have hard numbers at my fingertips). > > I don't think we should design the Origin-header-for-CSRF-protection > as the end-all, be-all CSRF defense. Instead, we should optimize it > to be an easy-to-use defense that works well for 90% of sites. It's not just POST that we need to worry about, ideally we should cover the GET case as well. Or at least it's quite likely that we will want to. It's quite common for sites to make GET requests to third parties, for example using <img>s displaying avatars etc. And even if we don't use Origin-header-for-CSRF-protection for GET, it's quite non-obvious that allowing POSTs to unrusted third parties is a security issue. So in short I don't think we want to make the CSRF protection behave as Access-Control does now. If we want the two to behave the same (so that we can use the same header), I think we should stick the whole redirect chain into the header. Which may not be possible depending on the IE 8 release schedule. / Jonas
Received on Tuesday, 13 January 2009 22:40:07 UTC