...
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.
...
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 thurough thorough than others. The best strategy is to implement all three, but usually one is "good enough".
...
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 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, he the hacker cannot force the user to click on a submit button on a confirmation page (if he canotherwise, you have bigger issues).
...