Overview
Webcast from the makers of AppScan (7 minutes long)
From Wikipedia
"Cross-site request forgery, also known as one-click attack, sidejacking or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Contrary to cross-site scripting(XSS), which exploits the trust a user has for a particular site, cross-site request forgery exploits the trust that a site has for a particular user."
CSRF is VERY dangerous. A hacker can pretty much assume the identity of a user by using the victims own browser and actions. It exploits your trust in the same-origin policy. A very simple description of the same-origin policy says that script from another site cannot access the contents of a page and more importantly, requests to a server can only pass cookies from the same host. For example, everytime you make a request to a "uci.edu" web page, all "uci.edu" cookies will be sent along with the request. This is where the vulnerability actually lies: triggering an inadvertant request which in turn inadvertantly sends all cookies (containing authentication values) and causes the server to think it is a legitimate request.
Testing
To test if an action is vulnerable, start at the page that contains the form that POSTs to the action in question. Fill out the form normally but before submitting the request, use a tool to intercept the request (such as Tamper Data). Take note of each parameter and the values passed in. Another way to do this is to use WebScarab. Once you have intercepted the request, switch the bottom section's tab to "text" and copy the post body. This will be exactly what you need to paste into the image tag.
Now construct an IMG tag with the src value set to the action in question and pass the parameters in the URL. View the page containing the image tag and see if the action was successful on the server. Another way is to simply paste the URL and parameters into the address bar of a browser. If it was successful, see the "Reject non-Post Requests" for a quick solution.
Now construct a form:
<body onload="document.getElementById('f').submit()">
<form id="f" action="http://host.uci.edu/action" method="post">
<input name="transferAmount" value="1000" />
</form>
</body>
From Coding Horror: Cross-Site Request Forgeries and You
If the action is still successful, see the "Require a Confirmation Screen Before Potentially Dangerous Actions" for a quick solution or "Use a Secondary Authentication Mechanism" for a fully comprehensive solution.
Preventing
There are ways of preventing this attack and some are more thurough than others. The best strategy is to implement all three, but usually one is "good enough".
Use a Secondary Authentication Mechanism
Send a securely randomly generated token with each request and require this token for the next request and then throw it away. This is the most effective, yet difficult to code, method.
Reject non-POST Requests
CSRF is usually exploited by hiding a request in an IMG, SCRIPT, or LINK tag. These tags initiate a GET request on behalf of the user. Blocking GET requests to sensitive actions stops this. However, a user can be "tricked" (Phished or using clever JavaScript) into submitting a form that posts to your server.
Require a Confirmation Screen Before Potentially Dangerous Actions
This way, even if the attacker gets the user to initiate the first request, he cannot force the user to click on a submit button on a confirmation page (if he can, you have bigger issues).
Snake Oil Solutions
Check the referrer header to make sure it matches what is expected. Yes this helps, but any field can be faked and a determined hacker.