Page Comparison

...

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 vulnerabilitiesTo 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.

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. If it was, see the "Reject non-Post Requests" for a quick solution.

Now construct a form:

Code Block
<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.

...

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