It’s fascinating how people, in the face of security advice and a continuous preaching of thinking in security terms, still fail to grasp the very basic concepts, like:
1.) If there’s a possible exploit, it will be exploited in an uncountable number of ways. When the first automated tool for that exploit is written, all hope is lost. GTFOH2008, with your attitude you will always be patching security holes after your software is screwed already.
2.) Things are usually more complicated than they seem. This is especially true for XSRF, and I’m not even talking about the commenters who confuse XSRF vs. XSS or SQL injection. These are totally unrelated. Unless you completely understand the problem, you cannot possibly claim that you are safe.
3.) Even then, you’re not safe until you have proven it. All those who claim woohoo, my homebrew ASP.NET on Rails uber-framework is safe since 1975, did you actually try to exploit your site(s)? Do you conduct regular tests? Do you have regression-testing in place for future maintenance work? As with cryptography, small and innocent-looking changes or mistakes can invalidate all your attempts. This is especially important for XSRF, as there is no perfect solution.
I can’t emphasize this enough: There is no single perfect solution to prevent XSRF. Double submit only works with JavaScript and Cookies enabled, both of which are security problems themselves, so security aware people are either unprotected or locked out. HTTP Referrer checking works these days, but only if you disallow empty referrers, so some people are, again, locked out. Both of them rely on up-to-date browsers that don’t have bugs in their security model (including all plugins, like Flash). Even the terribly cumbersome method to require the user’s password every time can go wrong (Is your site designed so that a user can clearly and easily see what she is about to do? If not, you’re hosed again.)
And all this is just XSRF. I’m not talking about XSS, Man-in-the-middle, social engineering, Clickjacking etc. So to anybody claiming smartly how secure he is, I’d suggest to accept the fact there will always be a new attack, always an attack vectors you can’t protect against, and - most importantly - always something that you could do, but didn’t do yet.
BTW, David Goodwin: This is old news. Long before the current XSRF hype, things like that already happened. I’m talking of 5 years ago. Real-world XSRF is around much longer than the term itself.
Jeff, as for your method to thwart XRSF: Isn’t it dangerous to include the nonce value in your HTML? After all, one of the reasons why double submit uses Cookies and JavaScript is that the same domain protection works better for cookies than for content bodies, given browser bugs, plugins etc.