Cross-site request forgery

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF ("sea-surf"^[1]) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.^[2] 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.

Background

CSRF vulnerabilities have been known and in some cases exploited since the 1990s.^[3] Because it is carried out from the user's IP address, some Web site logs might not have evidence of CSRF.^[2] Exploits are under-reported, at least publicly, and as of 2007^[4] there are few well-documented examples. About 18 million users of eBay's Internet Auction Co. at Auction.co.kr in Korea lost personal information in February 2008.^[5] Customers of a bank in Mexico were attacked in early 2008 with an image tag in email and were sent through their home routers to the wrong website.^[5]

Example and characteristics

A National Vulnerability Database page describing a CSRF hole

The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have authenticated.^[1] For example, one user, Bob, might be browsing a chat forum where another user, Mallory, has posted a message. Suppose that Mallory has crafted an HTML image element that references a script on Bob's bank's website (rather than an image file), e.g.,

<img src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory">

If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.

A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob's Web browser which is confused into misusing Bob's authority at Mallory's direction.

The following characteristics are common to CSRF:

• Involve sites that rely on a user's identity
• Exploit the site's trust in that identity
• Trick the user's browser into sending HTTP requests to a target site
• Involve HTTP requests that have side effects

At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.

CSRF attacks using images are often made from Internet forums, where users are allowed to post images but not JavaScript.

Limitations

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

1. The attacker must target either a site that doesn't check the Referer header (which is common) or a victim with a browser or plugin bug that allows Referer spoofing (which is rare).
2. The attacker must find a form submission at the target site, or a URL that has side effects, that does something useful to the attacker (e.g., transfers money, or changes the victim's e-mail address or password).
3. 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.
4. 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": the attacker can't see what the target website sends back to the victim in response to the forged requests, unless he exploits a cross-site scripting or other bug at the target website. Similarly, the attacker can only "click" any links or submit any forms that come up after the initial forged request, if those subsequent links or forms are similarly predictable. (Multiple "clicks" 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.

Forging login requests

An attacker may forge a request to log the victim in to a target website using the attacker's credentials; this is known as "login CSRF." Login CSRF makes various novel attacks possible; for instance, an attacker can later log in to the site with his legitimate credentials and view private information like activity history that has been saved in the account.^[6] The attack has been demonstrated against YouTube. ^[7]

Other approaches to CSRF

Additionally, while typically described as a static type of attack, CSRF can also be dynamically constructed as part of a payload for a Cross-Site Scripting attack, as demonstrated by the Samy worm, or constructed on the fly from session information leaked via offsite content. CSRF tokens could also be sent to a client by an attacker due to session fixation or other vulnerabilities, or guessed via a brute-force attack^[8] rendered on a malicious page that generates thousands of failed requests.

Prevention

Individual Web users 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.

Web sites have various CSRF countermeasures available:

• Requiring authentication in GET and POST parameters, not only cookies;
• Checking the HTTP Referer header;
• Ensuring there's no crossdomain.xml file granting unintended access to Flash movies^[9]; and
• Limiting the lifetime of authentication cookies

Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site can't put the right token in its submissions.^[1]

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 can work, but 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 movies to generate GET or POST requests to arbitrary domains with legitimate cookies and forged Referer headers.

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.^[1]

See also

Software Testing portal

• Confused deputy problem
• Replay attack
• Session fixation

References

External links

• The Cross-Site Request Forgery FAQ
• XSRF animated tutorial
• Free Cross-Site Request Forgery Solution from OWASP
• Cross-Site Request Forgery from The Web Application Security Consortium Threat Classification Project