Cross Site Request Forgery (CWE-352) is one of the more common vulnerabilities in existent today. Although it is relatively common, not all instances of vulnerability provide sufficient incentive for an attacker to exploit the vulnerability.
The vulnerability is based on the fact that the web application assumes any request by the user is a legitimate request intended by the user. This assumption may sound logical but is not always correct. An attacker can craft a web page with a link to the vulnerable page, to the web page that is the victim, there is no indication that the user followed a link or instruction on another site to visit the victim page. When a user visit any web page, the browser automatically follow all the instructions like scripting or grabbing remote images from other sites. While the browser is following instruction, it might have triggered actions on another site without the user or the browser even noticing about it. CSRF attacks allow the attackers to perform actions on behalf of the victim (user), all without the knowledge and approval of the victim.
When CSRF attack happens, the attacker does not have ability to "see" the interaction between the attacker and the victim site. A request has to be crafted before the attack. Leveraging this fact, one of the CSRF mitigation is to generate a random token to be submitted with every input form so that only the user and the site knows the token, an attacker not being able to "see" the traffic would not know the correct token value and therefore would not be able to launch an attack. The best way to inject such token into every form should be done by standard API such as the OWASP CSRFGuard. If you are using ViewState with a .Net application, you can also use ViewStateUserKey to prevent CSRF attack.
One thing worth noticing is that XSS undermine the controls put in place to stop CSRF. With XSS, the browser is effectively being controlled by the attacker, any tokens set inside the browser can be retrieved by the attacker as well. XSS should be eliminated before CSRF protection becomes fully effective. CSRF is often combined in real life attacks so that the attacker can perform actions on behalf of the user and in turn benefit the attacker.
