- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 30 Nov 2008 04:13:49 +0000 (UTC)
On Tue, 26 Feb 2008, Adam Barth wrote: > > Cross-site XMLHttpRequests include an Access-Control-Origin HTTP header > that indicates the principal who initiated the request: > > http://www.w3.org/TR/access-control/#access-control-origin0 > > If browsers attached this header to POST requests, servers could more > easily defend themselves against cross-site request forgery (CSRF) > attacks. > > Currently, browsers send the Referer header, which indicates the URL of > the page that initiated the request. The Referer header is unreliable > because many users and corporate installations suppress the header due > to privacy concerns. For example, suppose a company hosted a page on > its Intranet with the following URL: > > http://wiki/Competitive_Analysis_for_Secret_Project_XYZ > > which linked to competitors for Secret Project XYZ. The Referer header > would leak the existence of the secret project to its competitors. > Many proxies strip the Referer header as a matter of course. > > For these reasons, sites that attempt to use the Referer header to block > CSRF attacks permit cross-site requests that omit the Referer header. > Unfortunately, attackers can easily suppress the Referer header in all > major browsers, for example by initiating the request from an FTP page > or by first navigating to a javascript:"..." URL, and can mount CSRF > attacks against these sites. > > Attaching the Access-Control-Origin header to POST requests provides > better privacy/security trade-off than attaching the Referer header to > every request: > > 1) The Access-Control-Origin header contains only the information > required to make a CSRF security decision and not extraneous data, such > as the path and query parameters, that can contain sensitive > information. > > 2) Attaching the header only to POST requests reduces the information > leakage from simply clicking hyperlinks. Secret web pages are unlikely > to POST to untrusted web sites (although they often hyperlink to them). On Wed, 9 Jul 2008, Jonas Sicking wrote: > > The Access-Control spec adds an 'Origin' header that is submitted with > all requests. I propose that we specify that <form> POSTs should do the > same. This would be a very powerful mechanism to prevent CSRF attacks as > it would allow CSRF prevention to happen in the server, rather than in > the application layer. > > This way servers could be configured to reject all POST requests that > have an Origin header from a different site. > This wouldn't replace the normal CSRF protections sites need to do for > now, but eventually enough UAs implement this that servers can just > reject POSTs that doesn't have 'Origin' set. This would be especially > true if we can get this feature backported into old browsers (we'll > likely backport it to FF3). I'm all in favour of doing this, but isn't this something that belongs in the HTTP spec rather than HTML5? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 29 November 2008 20:13:49 UTC