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

The essential point which you are misunderstanding is this:

1) The attacker can force a user agent to suppress the Referer header,
mimicking a user behind a Referer-stripping proxy.

2) The attacker cannot force a supporting user agent to suppress the
Origin header and therefore cannot mimic a non-supporting user agent.

Fact (1) renders the Referer header useless as a CSRF defense, whereas
fact (2) allows the Origin header to be incrementally useful as a CSRF
defense.

On Sat, Jan 24, 2009 at 1:03 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Adam Barth wrote:
>>Which mod_security rules should a Web site implement to use the
>>Referer header as a CSRF defense without locking out some of its
>>users?
>
> Adapting the header name and regular expression should do.

That would not be an effective CSRF defense for any users.  The rules
you suggest implement lenient Referer validation, which does not
prevent an attacker from mounting a CSRF attack (as explained
previously in this thread).

> Of course the
> difference between the two would be that, and I am assuming proposal and
> implementations are perfect, the Origin header would protect a few users
> against all CSRF attacks, while the Referer header would protect nearly
> all users against some CSRF attacks.

An attacker has no trouble crafting an exploit against lenient Referer
validation.  It's pointless to consider defenses that can be defeated
by an adaptive adversary.

> Either way the web site would leave
> some users vulnerable to some CSRF attacks.

The rules you suggest leave all users vulnerable.

> The attraction of the Origin header is inversly proproptional to a site
> owner's willingness to leave a substantial, but over time diminishing,
> portion of his user base vulnerable to attack.

This is the case for any new browser feature designed to help with any
web security vulnerability.  We should not simply give up.  In fact,
the cost for a site to deploy an Origin-header based CSRF defense is
so low, I would expect many sites to deploy the defense, at first, to
supplement their existing CSRF defenses.

> If that is okay, you have
> a great solution. If it is not okay, you will implement some fallback
> defense, in which case you might just have used the Referer header to
> decide when to trigger the fallback, if it does not work always anyways.

You haven't stated precisely how you envision this working, but
suppose you rely on your fall back defense when the Referer header is
absent.  If you have a vulnerability in your fall back, then, with the
Referer approach, 100% of your users are vulnerable CSRF.  With
Origin, users with supporting user agents are protected from CSRF.

> In my book, the latter would be relying on the Referer header to build
> a CSRF defense, while the the former, relying on the Origin header, is
> not really a CSRF defense until perfect implementations are universally
> deployed.

In fact, the situation is precisely the opposite.  The Referer header
is useless as a CSRF defense until it reaches 100% deployment
(including not being removed by proxies), whereas the Origin header is
incrementally useful as a CSRF defense.

> But arguing about that is not very useful, my point was and is
> that you are oversimplifying and thereby overstating your case.

I do not believe I am oversimplifying or overstating my case.  The
Referer-based CSRF defense you suggest as an alternative doesn't
actually block CSRF attacks.  By contrast, the Origin-based CSRF
defense I suggest does actually block CSRF attacks.

Adam

Received on Saturday, 24 January 2009 23:16:57 UTC