Overview

Webcast from the makers of AppScan (7 minutes long)

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.

Detection

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.

Prevention

There are ways of preventing this attack and some are more thorough than others. The best strategy is to implement all three, but usually one is "good enough".

Use a Secondary Authentication Mechanism (Preferred)

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.

"Double Cookie Submission"

The CSRF attack works by subverting what the browser will do with the cookie. Ideally, your cookies would be totally unavailable to anyone outside of your domain. This attack works because XMLHttpRequest in some page can use the cookies of some foreign domain when posting to that foreign domain. However the script can not read the cookie directly due to the cross-domain rules, so a slight modification of the hidden field solution is to read the session cookie using JavaScript and then adding to URLs, forms or the body of a POST request, and then checking in the server that the session cookie value that the browser sends in the header (which is subvertable) is the same as the session cookie in the request (this is not subvertable in the same way).

From CSRF Attacks or How to avoid exposing your GMail contacts. This is a newer concept and is not in wide use.

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" (by 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, the hacker cannot force the user to click on a submit button on a confirmation page (otherwise, 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.

Public Documents

CSRF (aka XSRF) Vulnerabilities