- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 27 Jan 2009 13:40:28 +1300
- To: Adam Barth <w3c@adambarth.com>
- CC: Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter <LMM@acm.org>, ietf-http-wg@w3.org, Lisa Dusseault <ldusseault@commerce.net>
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