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.
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.
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.
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.
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).
- 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