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

Adam Barth wrote:
> On Sun, Jan 25, 2009 at 3:51 PM, Adrien de Croy <adrien@qbik.com> wrote:
>   
>> 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.
>   

this is security we're talking about though, not additional nice-to-have 
features.  Again, we still need to secure all users, and can't wait 
until deployment of some new header.

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

I think the converse is more likely.  But even if the token-based 
approach is found to be insecure, the solution would be to simply fix that.

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

a) there is a WAF.
b) people will even think about / know about Origin.  The set of people 
who are site developers is completely different to the set of people who 
are browser developers.  Even if you got 100% coverage of all browsers 
out of the box, it would still take a very long time to get the message 
out to every site operator.

I also think, that anyone who even does know about the Origin header 
will still look at the deployment level when deciding whether a more 
secure approach is necessary.

>> 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.
>   
for security you don't need to rely on it.  You can use methods to 
greatly increase your confidence in submitted data.

>   
>> 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.
>
>   
what about people who aren't running apache?

>> 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.
>   
sure, the additional cost might be very small, but unless it can be 
completely relied on, it can't replace any other scheme, therefore 
doesn't save any expense.

Adrien

> Adam
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 27 January 2009 00:38:24 UTC