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

The key point that you misunderstand is that the Origin header is
incrementally useful as a CSRF defense whereas the Referer header is
not.  This is a subtle, but important, point in the design of the
Origin header.

On Fri, Jan 23, 2009 at 5:17 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

[Re-ordered]

> The notion that we can introduce Origin
> now and reach anywhere near 97% correct deployment is absurd.

Suppose a browser with 10% market share implements the Origin header.
Then a Web site can protect 10% of their users from CSRF by adding
three rules to their Web application firewall (WAF).

> Regardless, Origin is not deployed and there is
> no reason to believe that it would ever reach the 97% deployment
> threshold.

There is no deployment threshold for the Origin header.

> So, what you are actually asking is
> that we standardize an entirely new header field in the vague hope
> that it will eventually be deployed correctly on better than 97% of
> browsers

The Origin header need not be deployed to 97% of browsers to be
useful.  The Origin header design achieves this by having three
states:

1) Present and containing a scheme/host/port serialization
2) Present and containing the string "null"
3) Absent

States (2) and (3) exist to distinguish supporting and non-supporting
user agents.  Sites can protect users of supporting user agents
without affecting those that use non-supporting user agents.

The Referer header has only two states:

A) Present and containing a URL
B) Absent

Because the Referer header collapses states (2) and (3) into (B), the
sites might lock out non-supporting user agents (or those behind
proxies that make them appear to be non-supporting) in order for users
of supporting user agents to reap the benefits of CSRF protection.
For this reason, the Referer header is not incrementally useful as a
CSRF defense.

> No, those 3% of users would have to use TLS/SSL, which the site could
> redirect to automatically (and should have been using anyway for a
> state-changing authenticated request.

Sadly, deploying HTTPS is not as easy as adding three rules to a WAF.
Consider a site like Digg.  Digg requires CSRF protection to prevent
stories from digging themselves and causing other mischief.  However,
implementing HTTPS requires Digg to pay its CDN more money for HTTPS
service, limits Digg to advertising networks that support HTTPS, and
prevents Digg from showing YouTube videos on its front page.

> Meanwhile, those same sites will implement this CSRF protection
> using Referer, if they need it, since 97% protection is obviously better
> than no success if they want to protect against CSRF.

The 3% lock-out rate for using the Referer header causes sites to use
other CSRF defenses that are expensive to engineer and difficult to
retrofit onto existing sites.  This prevents the bootstrapping effect
you envision for convincing proxies to change their behavior.

> Spend the
> effort on improving the definition of Referer instead so that it
> will be blocked by fewer proxies, and then help educate those
> proxy vendors as to why they shouldn't make their own users more
> vulnerable to CSRF attacks.

The timeline for this approach is unbounded.  The Origin header can
become useful within one or two browser update cycles.

> Sorry, the answer from this server developer is NO.

Then you are free to operate a non-participating server and ignore the
header.  Other server developers have expressed their interest in
operating a participating server.

> Heck, HTTP parsing isn't implemented correctly in far
> more than 3% of the browsers in the wild.

Yet somehow we muddle along.

>> What evidence do you have to back up this claim?
>
> 16 years of Web protocol implementations, 14 years being the editor
> of the HTTP specs, and 13 years in which my contact information has
> been supplied for people to send "why doesn't HTTP work?" messages
> for both standards and Apache httpd.

This is not evidence.  This is an argument from authority.

Thanks for your feedback,
Adam

Received on Saturday, 24 January 2009 03:04:55 UTC