- From: Collin Jackson <w3c@collinjackson.com>
- Date: Sat, 21 Jun 2008 16:46:11 -0700
- To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
- Cc: "Adam Barth" <public-webapi@adambarth.com>, "Web API WG (public)" <public-webapi@w3.org>, public-webapps@w3.org
On Sat, Jun 21, 2008 at 2:57 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > * Adam Barth wrote: >>We suggest that user agents attach an Origin header to POST requests. >>This balances the security benefits of easy CSRF protection with the >>privacy costs. If user agents attached this header, sites could >>protect themselves from CSRF by (2) undertaking state-modify actions >>only in response to POST requests and (2) implementing the below web >>application firewall rule (e.g., ModSecurity rule): > > Isn't that balance a little bit odd? You can virtually eliminate the > privacy concerns simply by saying no more than "This request has been > initiated from a site different from the one mentioned in the Host > header", say, `Pragma: cross-site`, without losing much flexibility. > The scan for "pragma contains 'cross-site'" is also easier to set up. You can already do something similar without any browser support -- set a "Pragma: Same-Site" or "X-Requested-By: XMLHttpRequest" header using the XMLHttpRequest API for all same-site POST requests, and use a firewall rule that blocks POST requests that don't have this header. The advantage of the Origin header is that it provides sites with functionality that can't already be emulated with XMLHttpRequest: it allows them to distinguish trusted (sub)domains from completely untrusted domains. Imagine if postMessage didn't send the origin, and instead only included a bit that said whether the message cross-origin -- there wouldn't be much point checking that bit, since postMessage is specifically designed for cross-origin communication. Collin Jackson
Received on Saturday, 21 June 2008 23:46:48 UTC