What is CSRF?

RSnake had a post on that question. The gist was not what it fundamentally was, but what types of things ought you be able to do with it in such a way that it would actually be a bad thing.

For the last few days I’ve really been trying to figure out what CSRF (Cross site request forgeries) are. I know that might seem like a pedantic or academic question but it’s really not. Here’s what I’m really concerned with. Without being able to define it we can’t even start talking about how to defend it. Stopping all cross site calls would break the internet and unfortunately wouldn’t solve a lot of the CSRF attacks out there anyway (since many are really SAME site request forgeries).

I'm more interested in fixing the problems than defining the threats for the developers. So if fixing certain vulnerabilities makes the threat of [XC]SRF a non-issue, then defining what constitutes it is not that big of a deal. Unfortunately, we have to be able to make up a new term for something and make everybody really scared of it in order to get the developers to write their code properly - which they knew how to do anyway, just didn't do it.

My response to RSnake's post follows:

[XC]SRF is a threat. The vulnerabilities (there are multiple) that contribute to it are at least threefold:
1) long session timeout:
reducing the session timeout will only reduce the window when the attack would actually function. It's hard to lure a user to "Log into your sla.ckers.org account, then come visit my site". But it could still happen.
2) allowing critical changes over GET:
this begins to sound like what you're driving at - define "critical". But only allowing the stuff to go through POST actually reduces the possibility of [XC]SRF.
3) lack of flow control:
sites ought to have some other control to verify that the user is either aware of the change that's going to take place, or that they've visited the change page prior to submitting the change page. The classic examples are things like - require your current password to enter a new one, or enter a CAPTCHA to perform some other critical operation, or to at least use a token in a hidden form that's matched to the same value in the session.

For the sake of correcting developers, I'm really beginning to look at real vulnerabilities, not just the threats that exploit them.