Do web application firewalls help?
I, too, feel this stuff is getting way to complicate for us casual web developers. Plus, this is a completely different concern in its own and it would make total sense to put a general solution in place.
Anti-CSRF/XSRF IIS7 module anyone?
I agree with the remark about using HTTP authentication, we shouldn’t have to roll our own, but with an addendum.
Browser support is really sucky. If I make one mistake I have to quit and restart my browser to clear out the erroneous password.
Plus, the protocol really needs a ‘log out’ command. Otherwise you’re back where you were with cookies.
The nonce is absolutely the way to go. Protects against replay attacks/errors too.
@Matt on October 15, 2008 05:38 PM:
Why are browsers sending cookies when a logical session no longer exists?
For one thing, HTTP is a stateless or sessionless protocol. There may be some notion of a logical session in the web app, but you can only infer when to end it (i.e. explicit user log out, close the session after a timeout, etc.). And the only way to know whether a given HTTP request is part of a session is to look at stuff like cookies or a session ID in the URL [yuck]. These are pretty basic tools, and can easily be taken advantage of by any bit of JS running in the browser. (The second big problem with web apps is that the user’s browser is one big pool of web pages, i.e. it’s all one authentication or security environment.)
I think the cookie==form field technique is only strong if you set HttpOnly when setting the cookie, right? (http://www.codinghorror.com/blog/archives/001167.html)
All of this is very interesting, but in general, I find myself asking, why am I surfing the internet while I’m on my bank’s website? I guess I have a general distrust of allowing the unwashed masses of the internet onto my pc while I’m at an important website.
By refusing to use the general internet while on a banking/financial website, you at least give yourself absolute protection at the most critical times. It is not convenient, but it is an extra layer of defense while these XSRF attacks are still out there.
Cheese is binding. The hacker did you a favor.
You know, it’s funny, because I’ve been using a session key for every form since a long time. The reason I’m using it is to keep track of the form status to avoid resends due to back buttons. Never thought this would protect me agains cross-site scripting…
@GTFOH2008 JustaNo0b: This attack does not necessarily require the user to navigate to some shady website and start clicking random links.
This attack can also be launched from sites that are vulnerable to a more commonly abused exploit: the XSS (cross-site scripting). That’s where an attacker injects HTML in an existing page that contains the malicious code. (for example, through a comment form just like the one on this site, except which allows some HTML formatting. You see those everywhere and many are not well-secured).
Not sure if you wrote this on your own, but there’s a version of this as a helper and actionfilter in the MVC Preview 5 Futures on Codeplex.
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Is it possible to hack the Same origin policy for JavaScript of a browser ? Are they bulletproof from that point ?
i use something like this to make forms secure (like the hidden input with the key)
input name=formname[@md5hash@][fieldname] type=text /
to make sure all content that is submitted has a valid origin. If the Server does not recognize the form or the token is already used the request will be dismissed. Also a nice way to avoid exploitation of sloppy captcha implementations
It might be worth noting that Ruby on Rails has support for this method of form/request validation built-in, without the developer having to do anything. I wonder when other web frameworks will be on par with this?
A quick question: with Google Crome’s process-per-tab and sandboxing abilities, are users of it more immune to these kinds of attacks?
Thanks.
Never use browser tabs. Never use ctrl-N to create a new browser window. Always start a new browser window from you OS menu (ie. start).
When your finished on a site which you login always use the logout button and close the window.
Always bring and Umbrella when it looks like raining. Never eat cheese before you go to bed.
Chrome sandbox leaks sand.
No Chrome has the same problem. Session cookies on one tab leak to the other tab.
How to try it out…
Login to some site - like a message board a php based one which always displays your username will do the trick. Click some forum message post. Copy the url. Open a new tab. Paste the url. If the page you see the same page and it has your user id on it then your in trouble. DO the same trick but this time open a NEW browser (from OS menu) instead of a new tab and you won’t see the same behaviour.
Tabs in firefox/ie and chrome leak cookies to each other.
I know chrome has some patches which i’ve not applied - so perhaps it’s changed.
Of course, I’m exploring this myself for the first time - so I research the right to be wrong and/or corrected.
Wow…how long has this problem been going on? This is scary. How long has this sort of attack been out there? I’ve only been out of college for a little over a year and I don’t remember them mentioning this in any of my classes.
Jeff, I want to thank you - you’re a big part of my personal education from post to post 
I’ll be taking some time to personally research this issue further.
Joe. Your not also a plumber are you ?
A simple first step is to set your browser to clear all cookies when it exits.
That helps minimize the chance that you have random authentication cookies floating around in your browser. You can then only be exploited for websites you visited this session.
You still get most of the benefits of cookies, but are freed of some of the risks.
In this video tutorial, Stephen Walther explains how you can easily defeat JavaScript Injection Attacks and Cross-Site Scripting Attacks in your ASP.NET MVC applications by HTML encoding your content.
http://www.asp.net/learn/mvc-videos/video-400.aspx
Probably good enough as long as you’re not developing an online community web site centered around programming code samples!
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.