Web Design & Development Guide

Cross-site request forgery

Home | Up

Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind 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.

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 to have authenticated. For example, one user, Bob, might be browsing a chat forum where another user, Alice, has posted a message with an image that links to Bob's bank. Suppose that, as the URL for the image tag, Alice has crafted a URL that submits a withdrawal form on Bob's bank's website. 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 Alice'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.

Here is an example of an attack on Digg. Here is another example of an attack on Amazon.com, and one on Google's Adsense.

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. This method only works with Ajax based requests, but it can be applied as a global fix without needing to alter a large number of forms. 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.

Contrary to popular belief, using POST instead of GET does not offer sufficient protection. JavaScript can be used to forge POST requests with ease. Nonetheless, requests that cause side effects should always use POST.^[1] Also, POST does not leave a trail of variable data in webserver and proxy server logs, while GET does leave such a trail. It is still clearly best to use POST when coding in a defense-in-depth approach.

Another approach is to check the HTTP Referer header to see if the request is coming from an authorized page. Unfortunately, this technique may not work reliably, since browsers sometimes omit the Referer header because of a user's privacy settings or because the Referer is a secure https page.

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, or clearing their browser's cookies at the end of each browser session.^[2]

Effects

This attack relies on a few assumptions:

• The attacker has knowledge of sites the victim has current authentication on (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
• The "target site" doesn't have secondary authentication for actions

While having potential for harm, the effect is mitigated by the attackers 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).

References

1. ^ RFC 2616 9.1.1
2. ^ Dark Reading, CSRF Vulnerability: A Sleeping Giant, accessed 2006-10-18

• Cross Site Request Forgeries aka CSRF
• Cross-Site Request Forgeries
• The Cross-Site Request Forgery FAQ
• Security Corner: Cross-Site Request Forgeries
• Foiling Cross-Site Attacks
• Security Tips for Web Developers
• Cross Site Reference Forgery (sic)
• What is Cross Site Request Forgery?
• Preventing CSRF efficiently
• Sla.ckers Forum
• CSRF Attacks and Protecting Your Site

Home | Up | Browser exploit | Cross-site cooking | Cross-site request forgery | Cross-site scripting | Cross-zone scripting | Directory traversal | Evil twin (wireless networks) | HTTP response splitting | IDN homograph attack | Referer spoofing | Session fixation | Session poisoning | Website spoofing

Web Design & Development Guide, made by MultiMedia | Websites for sale

This guide is licensed under the GNU Free Documentation License. It uses material from the Wikipedia.