Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced 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. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Key Concepts of Cross-Site Request Forgery

• Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.
• The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.
• The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.

Executing a CSRF Attack

In a Cross Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited the victim must be authenticated against (logged in) to the target site. For instance let’s say examplebank.com has online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack on examplebank.com but am not currently logged in, nothing happens. I am logged in however, the requests in the attack will be executed as if they were actions that I had intended to do.

Let’s look at how the attack described above would work in a bit more detail. First let’s assume that I’m logged in to my account on examplebank.com which allows for standard online banking features, including transferring funds to another account.

Now let’s say I happen to visit somemalicioussite.com. It just so happens that this site is trying to attack people who bank with examplebank.com and have setup a CSRF attack on their site. The attack will transfer $1500.00 to their account, which is account number 123456789. Somewhere on somemalicioussite.com attackers have added this line of code:

<iframe src="http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=123456789">

Upon loading that iframe, my browser will send that request to examplebank.com which my browser has already logged in as me. The request will be processed and send $1500.00 to account 123456789.

Limitations

Several things have to happen for cross-site request forgery to succeed:

• The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin bug that allows referer spoofing (which is rare).
• The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
• The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail.
• The attacker must lure the victim to a Web page with malicious code while the victim is logged in to the target site.

Note that the attack is blind; i.e., the attacker can't see what the target website sends back to the victim in response to the forged requests, unless they exploit a cross-site scripting or other bug at the target website. Similarly, the attacker can only target any links or submit any forms that come up after the initial forged request if those subsequent links or forms are similarly predictable. (Multiple targets can be simulated by including multiple images on a page, or by using JavaScript to introduce a delay between clicks.)

Given these constraints, an attacker might have difficulty finding logged-in victims or attackable form submissions. On the other hand, attack attempts are easy to mount and invisible to victims, and application designers are less familiar with and prepared for CSRF attacks than they are for, say, password-guessing dictionary attacks.

Preventing Cross-Site Request Forgery (CSRF) Vulnerabilities

The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user.

Individual Web users using unmodified versions of the most popular browsers can do relatively little to prevent cross-site request forgery. Logging out of sites and avoiding their "remember me" features can mitigate CSRF risk; not displaying external images or not clicking links in spam or untrusted e-mails may also help.

Browser extensions such as RequestPolicy (for Mozilla Firefox) can prevent CSRF by providing a default-deny policy for cross-site requests. However, this can significantly interfere with the normal operation of many websites. The CsFire extension (also for Firefox) can mitigate the impact of CSRF with less impact on normal browsing, by removing authentication information from cross-site requests. The NoScript extension mitigates CSRF threats by distinguishing trusted from untrusted sites, and removing payloads from POST requests sent by untrusted sites to trusted ones.

Web sites have various CSRF countermeasures available:

• Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions[1]
• Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
• Limiting the lifetime of session cookies
• Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls.
• Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies
• Verifying that the request's header contains a X-Requested-With (used by Ruby on Rails before v2.0 and Django before v1.2.5), or checking the HTTP Referer header and/or HTTP Origin header. These protections have been proven insecure under a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website, hence allowing a forged request.

An easy and effective solution is to use a CSRF filter such as OWASP's CSRFGuard. The filter intercepts responses, detects if it is a html document and inserts a token in to the forms and optionally inserts script to insert tokens in ajax functions. The filter also intercepts requests to check that the token is present.

A variation on this approach is to double submit cookies for users who use JavaScript. If an authentication cookie is read using JavaScript before the post is made, JavaScript's stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain.

Checking the HTTP Referer header to see if the request is coming from an authorized page is commonly used for embedded network devices because it does not increase memory requirements. However a request that omits the Referer header must be treated as unauthorized because an attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs. This strict Referer validation may cause issues with browsers or proxies that omit the Referer header for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary HTTP request headers using CRLF Injection. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an HTTP request.

To prevent forgery of login requests, sites can use these CSRF countermeasures in the login process, even before the user is logged in.

Sites with especially strict security needs, like banks, often log users off after (for example) 15 minutes of inactivity.

Using the HTTP specified usage for GET and POST, in which GET requests never have a permanent effect, is good practice but is not sufficient to prevent CSRF. Attackers can write JavaScript or ActionScript that invisibly submits a POST form to the target domain. However, filtering out unexpected GETs prevents some particular attacks, such as cross-site attacks using malicious image URLs or link addresses and cross-site information leakage through <script> elements (JavaScript hijacking); it also prevents (non-security-related) problems with aggressive web crawlers and link prefetching.

Cross-site scripting (XSS) vulnerabilities (even in other applications running on the same domain) allow attackers to bypass CSRF preventions.