Cross-site request forgery

From Wikipedia, the free encyclopedia

Cross-site request forgery, also known as one click attack, sidejacking or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a type of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts.

Contents

[edit] Example and characteristics

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. 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 Bob's browser's attempt 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 that is authenticated by a cookie saved in his web browser could unknowingly send an HTTP request to a site that trusts him and thereby cause an unwanted action.

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

[edit] Effects

This attack relies on a few assumptions:

  • The attacker has knowledge of sites on which the victim has current authentication (more common on web forums, where this attack is most common)
  • The attacker's "target site" has persistent authentication cookies, or the victim has a current session cookie with the target site
  • The "target site" doesn't have secondary authentication for actions (such as form tokens)

While having potential for harm, the effect is mitigated by the attacker's need to "know his audience" such that he attacks a small familiar community of victims, or a more common "target site" has poorly implemented authentication systems (for instance, if a common book reseller offers 'instant' purchases without re-authentication).

[edit] Prevention

For the web site, switching from a persistent authentication method (e.g. a cookie or HTTP authentication) to a transient authentication method (e.g. a hidden field provided on every form) will help prevent these attacks. A similar approach is to include a secret, user-specific token in forms that is verified in addition to the cookie.

An alternate method is to "double submit" cookies. If an authentication cookie is read using JavaScript before the post is made, the 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 GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. On the other hand, this method forces users to enable JavaScript, negating the only way a user has to prevent most cross-site scripting vulnerabilities from being exploited.

The simple <img> example above would use a GET request. In this case, the CSRF can be prevented by following the HTTP specified usage for GET and POST, namely that GET requests should not change anything on the server; only POST requests are accepted for making changes. However, requiring POST instead of GET does not offer full protection because JavaScript can be used to forge POST requests across domains using HTML forms.

Checking the HTTP referrer 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 URLs. This strict Referer validation may cause issues with browsers or proxies that omit the referrer header (e.g. due to a user's privacy settings or because the referrer is an HTTPS page.) Also, depending on the browser and proxy being used, it may be possible to spoof a referrer header for a cross-site request by exploiting vulnerabilities in Internet Explorer or Flash.[1]

Although cross-site request forgery defenses typically require modifying the web application, individual users can help protect their accounts at poorly designed sites by logging off the site before visiting another. Site designers should help users do this by providing a log-off facility and encouraging its use. [2]

[edit] References

  1. ^ Amit Klein, Exploiting the XMLHttpRequest object in IE - Referrer spoofing, and a lot more..., 2005-09-24
  2. ^ Dark Reading, CSRF Vulnerability: A Sleeping Giant, accessed 2006-10-18

[edit] External links

[edit] See also