A web application's vulnerability to CSRF is due to the following conditions:

1. The use of certain HTML tags will result in automatic HTTP Request execution.
2. Our browsers have no way of telling if a resource referenced by an tag is a legitimate image.
3. The loading of an image will happen regardless of where that image is located.
4. Code within the web application performs security sensitive operations in response to requests without validation of the user.

GET requests are especially vulnerable to this type of attack, but POST requests are not immune. An attacker could write their own website and use JavaScript to auto submit their form to a target location on a victim's website. While using a POST request to perform this attack makes it much more difficult to implement than performing a GET request, the attack is still possible.

There are a couple of mitigations that developers can make within their code that will reduce the likelihood of a successful CSRF attack. The most common defense is to append challenge tokens to each request. These challenge tokens must be associated with the user's session. This will prevent an attacker from providing a valid token of their own to utilize within the attack. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user. Another mitigation that will reduce the chances of a CSRF attack is to rely on the HTTP Referrer header. While this field can be spoofed, they can provide the user protection if the CSRF attack is coming from a link that was clicked within an email.

Testing for Cross-Site Request Forgery vulnerabilities:
Now that you've seen how damaging a CSRF attack can be, let's look at how you would test for this type of vulnerability in your application.

1. Look for areas in your application that will perform an action on the user's behalf, using their security context, in response to an HTTP GET request.
2. Create a URL address for the malicious action to be performed. For example: http://malicious.com/[action]
3. Create an email that contains HTML that references that URL address. For example, the img tag could be used:
4. Log into a valid testing account as the "victim".
5. After successfully authentication has occurred, click on the malicious testing link in the email that was previously created.
6. Observe the results. If the web server executed the request contained within the malicious email, a CSRF vulnerability was found!

This test makes use of the fact that the resources were available via the HTTP GET request. POST requests can also be vulnerable to CSRF, but these requests must be done using a scripting language that will auto-submit a form that includes the malicious tags.

One of the common mistakes that users make is that the CSRF attack will take advantage of the fact that many users forget to logout of web applications when they are finished using them. Doing this doesn't give the web applications a chance to clear their session IDs or other types of session information from the cookie, allowing the CSRF attack to be successful even when the user is not actively browsing vulnerable websites.

Additional Resources:

For more about CSRF, check out the Cross Site Request Forgery FAQ at: http://www.cgisecurity.com/articles/csrf-faq.shtml

Another great site for information about CSRF is: http://www.owasp.org/index.php/CSRF