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

On 25/01/2009, at 10:16 AM, Adam Barth wrote:

> 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.

Can you walk us through this attack, please? Or give a reference...

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

This supposes perfect implementation...

> 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  
> <> 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

Mark Nottingham

Received on Friday, 30 January 2009 08:24:42 UTC