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

On Mon, Jan 26, 2009 at 4:40 PM, Adrien de Croy <adrien@qbik.com> wrote:
>> 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.

It is impossible to secure all the users who visit your Web site.  You
cannot secure users with IE5 or Firefox 1.0, for example.  Moreover,
the header provides incremental value while it is being deployed.

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

Regardless of which has a vulnerability, some fraction of your users
will be secure as long as BOTH don't have a vulnerability
simultaneously.

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

One common way I expect sites to make use of the header is via
security consultants.  Consider the case of WhiteHat Security.  If you
run a large Web site, you can hire WhiteHat to help you secure your
site.  Their preferred mod of operation (as I understand it from
Jeremiah's blog posts) is to install a Web application firewall and
apply "virtual patches" (i.e., WAF rules) to block vulnerabilities
until the site's developers can fix the underlying hole (assuming the
developers actually get around to fixing the holes).  The Origin
header is a powerful tool to add to the WAF arsenal against CSRF.

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

It's helpful to think about this in cost/benefit terms.  The cost of
adding the rules to your WAF is small and the benefit scales with the
header's deployment.

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

You simply cannot secure your Web site in IE5 or Firefox 1.0.  It is
simply impossible because the client-supplied data from these browser
lacks confidentiality or integrity.  Ultimately, the secret token
defense also relies on the browser for security.

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

There is an entire industry of companies whose business plan involves
making it easy to deploy a WAF.

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

It provides value:

1) Between the time a CSRF vulnerability is discovered and when its fixed.

2) For those sites that don't have the will / engineering time / money
to implement a complex secret token-based defense.

Of course, once all the browsers your site supports implement the
Origin header, then you don't need to implement a secret token based
defense at all.

Adam

Received on Tuesday, 27 January 2009 01:19:03 UTC