[whatwg] CSRFs and Origin header and <form>s
ian at hixie.ch
Sat Nov 29 20:13:49 PST 2008
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:
> If browsers attached this header to POST requests, servers could more
> easily defend themselves against cross-site request forgery (CSRF)
> 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:
> 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
> 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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg