A Cross-Site Request Forgery (CSRF, sometimes pronounced “Sea-Surf”) attack abuses the trust between the application and a given client (the victim) to perform an application level transaction on behalf of the attacker using the identity of the client. The attack is based on embedding URLs that represent specific transactions of the target application in an attacker controlled page and have this page accessed by the victim from a browser that has already established trust relationship with the target application (e.g. through authentication). Examples of such requests include the transfer of monetary funds, provisioning activities, application administration and even purchase transactions.
A user establishes trust with a target web application through different authentication and identification procedures (Basic authentication, Form authentication, X509 certificates, etc.). Once trust is established it is usually kept for the lifetime of the browser process (or until a properly implemented logout transaction is invoked by the client). Thus, repeated requests sent from the same browser to the target application do not require further human intervention with respect to trust (e.g. by using session cookies or automatically resending authentication header data).
A CSRF attack assumes that the same browser process that has an established trust with a given application is used for browsing an attacker's controlled page. This assumption has become a very reliable one since the introduction of multiple tabs functionality by browser software makers (Internet Explorer 7.0). An attacker's controlled page could be as complex and robust as an entire site created and maintained by the attacker as part of a fraud scheme or as simple as a forum page containing messages introduced by the attacker, a web-mail application that displays a spam message distributed by the attacker or even an ad banner.
The attack is mounted by embedding a URL that invokes a given transaction of the target application in an HTML attribute that automatically generates a request for the URL. The most obvious example would be the src attribute of an img element (e.g. <img src=”http://www.targetapp.com/doTransaction?param1=x¶m2=y) but the number of possible attributes is actually very large. When the victim's browser is rendering the page it will send a request to the target application with the attacker's created URL and with any trust attributes related to the target application. Thus the transaction injected by the attacker will be accepted and preformed under the identity of the victim. A more sophisticated CSRF attack can be mounted using known security glitches of the XMLHttpRequest object or Flash scripts when embedded in an attacker's controlled page.
Cross Site Request Forgery Prevention:
There are several ways to prevent CSRF attacks. One mitigation technique involves adding a nonce (large randomly chosen number) to each transaction. The value of the nonce attached to the request is validated against the value given for that specific user session. Thus an attacker cannot embed a URL representing a valid transaction in the attacker's controlled page. Alternatively additional human interaction could be requested for sensitive transactions in the form of repeated authentication or answering a CAPTCHA. However, such measures demand much modification of already-existing Web applications, so these techniques are unlikely to gain popularity among Web application developers. Another mitigation technique relies on checking the Referer header of HTTP requests and validating that it contains a URL from within the server's domain, rather than from an external source.