W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] CSRFs and Origin header and <form>s

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 30 Nov 2008 04:13:49 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0811300401070.17414@hixie.dreamhostps.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC