Re: The HTTP Origin Header (draft-abarth-origin)

On Jan 22, 2009, at 9:33 AM, Larry Masinter wrote:

> The document  http://tools.ietf.org/html/draft-abarth-origin
> proposes a new HTTP header and rules for its use as a way of  
> addressing
> Cross-Site Request Forgery (CSRF) attacks. This was part of the
> HTML5 work in WhatWG and W3C HTML working group.

I have no interest in implementing or standardizing this header.

1) CSRF is not a security issue for the Web.  A well-designed Web
service should be capable of receiving requests directed by any host,
by design, with appropriate authentication where needed.  If browsers
create a security issue because they allow scripts to automatically
direct requests with stored security credentials onto third-party
sites, without any user intervention/configuration, then the obvious
fix is within the browser.

2) It doesn't prevent CSRF attacks because it doesn't prevent the
Origin header field from being spoofed.  It therefore only improves
a very small situation: a new browser that has implemented this new
header *and* allows cross-site scripted requests *and* prevents any
manipulation of the request header fields *and* is still stupid
enough to include stored credentials in the cross-site request.
It does nothing for existing browsers and actively interferes with
existing non-browser user agents.

3) It requires servers to maintain a table of "compliant" user
agents in order to distinguish spoofed or dropped origin fields,
which is known to be harmful to the introduction of new clients
and results in all clients using copycat user-agents fields,
thereby defeating the purpose of the table.

4) Even if such a feature becomes necessary, it can be far
easier accomplished by changing the operational behavior of
browsers such that they always send Referer and simply reduce
the value of that field (similar to that specified for Origin)
in those cases where it is currently not set at all.  No change
would then be needed to HTTP and existing agents that already
send Referer for these cases would already comply.

5) The author seems to be unaware that URL is a deprecated term
defined in RFC 3986. The field values would be better defined
in terms on the standard URI grammar and terminology.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Thursday, 22 January 2009 23:07:45 UTC