Cross-site Request Forging

Lately, there has been a lot of stink on [XC]SRF - Cross-Site Request Forg(ing|ery). There's a whitepaper on the subject, but it's nothing new. Unfortunately, since it's making headlines again, there are going to be a lot of misconceptions about it. I'm going to cover my take on the matter here.

First, even at SPICON, it was covered during an AJAX session of a seminar. While AJAX calls on the attacker site might make it somewhat more useful (somehow dealing with the image response on the client, then sending info about that back to the attacker), XmlHttpRequest is not a requisite for successful attacks. Here's how to protect yourself:

Users

1. Don't visit pr0n or war3z sites. That doesn't entirely protect you, however.
2. Avoid using "remember me" or "stay logged in" functionality for websites. While these things are conveniences for you, they're also conveniences for the badguys.
3. When doing really critical stuff, like making credit card transactions, banking, changing your grades, etc., log out of the application, and close your browser (all windows of that application) before going to do your trivial stuff (live visiting my blog).

Developers

1. Avoid implementing "remember me" and "stay logged in" functionality. I understand your managers may have some say in the issue. If you can avoid it, do.
2. All really sensitive operations should require some proof that there's really a user there. The best, most dangerous XSRF example is a change password page that doesn't require the old password - require the user to enter their password, or a CAPTCHA - whichever makes more sense depending on the operation.
3. Add a level of indirection to verify that the user viewed the form before submitting it. The downside to JUST doing this is that in the Netflix example (I'm not bashing them - it's been fixed) if I try to attack one with a level of indirection, I'll be adding something the user has already seen - or you could still use the attack to empty somebody's queue - see 4.
4. Add token checking. Store a token in the session, then send that token to the user. Next request, the server should check the token, then remove it from the session. If the token matched, allow the operation (they provided proof they visited step 1 before proceeding to step 2) if the token doesn't match or wasn't there, the user did something wrong. (Struts token is an example of a framework-supplied mechanism, but it's not hard to implement by hand.)
5. For cryin' out loud, when a user logs out, truly destroy the session! If you can do it without abandoning your users, force them to log out after some hard period, regardless of activity.
   

Hopefully, some folks will read this and realize it's a vulnerability that's been around forever (session persistence) and won't have the huge scream they had for awhile about response splitting and request smuggling. I'm not saying these aren't vulnerabilities, but there's nothing new under the sun.