Overview
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
Testing for CSRF is quite easy. You will need two different machines to test this.
- Find a machine you can remote into and use your own desktop.
- Now authenticate in one server (or both as different users)
- Copy the cookies from one machine to another and see if you can steal the users session. The Add n Edit Cookies Firefox extension makes this particularly easy.
If you can do this, you know that you can hijack their session and exploit CSRF vulnerabilities.
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".
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).
Use a Seconday 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.
False Sense of Security Solutions
Check the IP address and referrer header to make sure they match what is expected. Yes this helps, but these fields can be faked and any determined hacker will not be slowed down at all.