- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 22 Jun 2008 00:49:57 -0700
- To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
- Cc: "Collin Jackson" <w3c@collinjackson.com>, public-webapps@w3.org
On Sat, Jun 21, 2008 at 6:51 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > The stated goal was to balance easy protection against session riding > attacks without compromising privacy too much. Allowing session riding > via some sites but not others is something that cannot be done securely > today without major effort as whatever information is used to tell good > requests apart from bad requests may either be absent or faked. The Origin header is hard to fake because XHR2 doesn't allow it to be set across domains and XHR1 is for same-origin requests only. A supporting browser will not omit the Origin header for POST request. In situations were no origin is appropriate (say from for a data URL), a supporting browser will send the value "null". Consider a site like Facebook or Slashdot that uses a number of subdomains (e.g., stanford.facebook.com or it.slashdot.org). It is entirely reasonable for the site to POST requests between these origins. Sending "Pragma: cross-site" doesn't let the site use this feature to defend against CSRF, but sending "Origin: http://it.slashdot.org" does. > That'll remain so until any browser that does not set the header can be > blocked. There are three cases: 1) Origin header missing: This is a non-supporting browser. Fall back to existing CSRF defenses. 2) Origin header has a trusted value: Accept the request. 3) Origin header has an untrusted value: Reject the request. This is the behavior of the ModSecurity rule earlier in this thread. Users of supporting browsers get enhanced CSRF protection. Attackers cannot forge the Origin header in cross-origin requests in today's browsers. Site can use the header immediately, without having to wait for non-supporting browsers to become unused. > I would hope that at that point, other means of cross site and document > communication are more attractive to developers than what is currently > not affected by same-origin restrictions, and hope that new ways of by- > passing the same-origin restrictions will not rely on the Origin header > alone, so I don't think there is any real advantage. Perhaps I'm missing > something? Not all web sites are contained within a single origin. This feature is not intended to enable cross-origin communication via POST requests. The feature is intended to make it easy for site developers, or web application firewall vendors, to defend against CSRF attacks. Adam
Received on Sunday, 22 June 2008 07:50:36 UTC