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

On Sun, Jan 25, 2009 at 3:51 PM, Adrien de Croy <adrien@qbik.com> wrote:
> My question then is should we be pouring effort into a solution that is only
> incrementally useful.

Several browser vendors have expressed interest in implementing a
feature to help sites defend themselves against CSRF.  By definition,
such as feature is only incrementally useful.

> A a site operator myself, I'm not particularly interested in very easily
> being able to protect a very small number of users.  We need to protect ALL
> our users.

This number will grow over time.  Most sites have a list of browsers
which they support (i.e., expend resources to ensure their site works
properly).  After a few browser update cycles, this list may well
contain entirely supporting user agents.  If we don't start now, we'll
never improve the status quo.

In a sense, the same argument could be advanced about any browser
feature (CSS, <canvas>, etc).  This shouldn't stop us from innovating.

> If this means we have to go to some secure token-based approach, then why
> bother with anything else as well?

In the near term, you might as well use both secret tokens and the
Origin header.  At some point, your secret token defense will have a
vulnerability (just due to its complexity), and users of supporting
browsers will be protected by the Origin header.

> As long as there is an appreciable proportion of our user-base using a
> browser that doesn't support Origin, we will need to cater to them.  By your
> argument, a show-stopper proportion is at least 3% or less.

The difference is, with a Referer-based CSRF defense, the site is
unusable by 3% of its users.  With the Origin header, the site is
usable, but contains vulnerabilities, just like your Web site contains
XSS vulnerabilities in IE5 and Firefox 1.0 that you don't patch.

> It just seems to make the Origin header a bit redundant.

In reality, things will likely play out as follows in the near term:

1) OMG, my site has CSRF!
2) Add Web application firewall rules that blocks CSRF for Origin
header supporting browsers.
3) Spend the engineering resources to implement a secret token CSRF defense.

How far a site operator gets down this list of steps depends on their
engineering resources, their risk tolerance, and the deployment of the
Origin header.  Adding step (2) to the equation improves the situation
dramatically, especially as user agents that support the Origin header
gain market share.

> Also, without any sort of decent crypto involved, any reliance on
> client-supplied data for real security seems destined to fail.

Unfortunately, you must rely on client-supplied data in order to build
a Web application.

> Even if you could get the major browsers to support it, getting servers to
> support it would be several orders of magnitude more difficult.  For many
> sites it would require patching scripts.. lots of them.

You should be able use the Origin header by adding a few rules to your
Web application firewall (see the three mod_security rules earlier in
this thread).  If you're not using a Web application firewall, you can
start using one by adding one line to your apache config file.

> Why would I go to
> all the effort to patch all our scripts to check Origin to only protect a
> vanishingly-small-maybe-growing-but-never-enough proportion of my users when
> I could get them all with a decent system?

One of the design goals of the Origin header is making is very easy to
use as a CSRF defense.  Compared the cost of implementing a secret
token based defense, implementing an Origin-based CSRF defense as well
is insignificant.

Adam

Received on Monday, 26 January 2009 00:15:00 UTC