Cross-site request forgery
- 1 History
- 2 Example and characteristics
- 3 Forging login requests
- 4 HTTP verbs and CSRF
- 5 Other approaches to CSRF
- 6 Effects
- 7 Limitations
- 8 Prevention
- 9 See also
- 10 References
- 11 External links
CSRF 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 was also vulnerable to CSRF and it allowed attackers to change their company system. This is fixed in newer versions
New attacks against web-enabled devices were carried out in 2018, including attempts to change the DNS settings of routers. Some router manufacturers hurriedly released firmware updates to improve protection, and advised users to change router settings to reduce the risk. Details were not released, citing "obvious security reasons".
Example and characteristics
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 (for example, a discussion forum), or sent in an HTML email body or attachment. A real CSRF vulnerability in uTorrent (CVE-2008-6586) 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
- Change uTorrent administrator password
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 uTorrent version at the same time as opening these pages were susceptible to the attack.
When accessing the attack link to the local uTorrent application at localhost:8080, 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 (in this example, the local uTorrent web interface) at the time of the attack.
A cross-site request forgery is a confused deputy attack against a web browser.
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.
- It involves 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.
In the uTorrent example described above, the attack was facilitated by the fact that uTorrent's web interface used GET request for critical state-changing operations (change credentials, download a file etc.), which RFC 2616 explicitly discourages:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
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.
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 his 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 (due to the differences in their handling by the web browsers). 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 (
field1=value1&field2=value2) 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 (JSON, XML) a standard method is to issue a POST request using XMLHttpRequest with CSRF attacks prevented by Same-origin policy (SOP) and Cross-origin resource sharing (CORS); there is a technique to send arbitrary content from a simple HTML form using
ENCTYPEattribute; such a fake request can be distinguished from legitimate ones by
text/plaincontent type, but if this is not enforced on the server, CSRF can be executed
- In simplest form of POST with data encoded as a query string (
- other HTTP methods (PUT, DELETE etc.) can only be issued using XMLHttpRequest with Same-origin policy (SOP) and Cross-origin resource sharing (CORS) and preventing CSRF; these measures however will not be active on websites that explicitly disable them using
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.
Severity metrics have been issued for CSRF vulnerabilities that result in remote code execution with root privileges as well as a vulnerability that can compromise a root certificate, which will completely undermine a public key infrastructure.
This section does not cite any sources. (May 2018) (Learn how and when to remove this template message)
Several things have to happen for cross-site request forgery to succeed:
- The attacker must target either a site that doesn't check the referrer header or a victim with a browser or plugin that allows referer spoofing.
- The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
- The attacker must determine the right values for all the forms or URL inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will most likely fail (unless the attacker is extremely lucky in their guess).
- The attacker must lure the victim to a web page with malicious code while the victim is logged into the target site.
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 cracking dictionary attacks.
Most CSRF prevention techniques work by embedding additional authentication data into requests that allows the web application to detect requests from unauthorized locations.
Synchronizer token pattern
Synchronizer token pattern (STP) is a technique where a token, secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side. The token may be generated by any method that ensures unpredictability and uniqueness (e.g. using a hash chain of random seed). The attacker is thus unable to place a correct token in their requests to authenticate them.
Example of STP set by Django in a HTML form:
<input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />
STP is the most compatible as it only relies on HTML, but introduces some complexity on the server side, due to the burden associated with checking validity of the token on each request. As the token is unique and unpredictable, it also enforces proper sequence of events (e.g. screen 1, then 2, then 3) which raises usability problem (e.g. user opens multiple tabs). It can be relaxed by using per session CSRF token instead of per request CSRF token.
- On an initial visit without an associated server session, the web application sets a cookie containing a random token that remains the same for the whole web session
Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/
- The server validates presence and integrity of the token
csrf_token = HMAC(session_token, application_secret)
This technique is implemented by many modern frameworks, such as Django and AngularJS. Because the token remains constant over the whole user session, it works well with AJAX applications, but does not enforce sequence of events in the web application.
The protection provided by this technique can be thwarted if the target website disables its same-origin policy using one of the following techniques:
- Permissive Access-Control-Allow-Origin Cross-origin resource sharing header (with asterisk argument)
- clientaccesspolicy.xml file granting unintended access to Silverlight controls
- crossdomain.xml file granting unintended access to Flash movies
Double Submit Cookie
The advantage of this technique over the Synchronizer pattern is that the token does not need to be stored on the server.
Browser extensions such as RequestPolicy (for Mozilla Firefox) or uMatrix (for both Firefox and Google Chrome/Chromium) can prevent CSRF by providing a default-deny policy for cross-site requests. However, this can significantly interfere with the normal operation of many websites. The CsFire extension (also for Firefox) can mitigate the impact of CSRF with less impact on normal browsing, by removing authentication information from cross-site requests.
The NoScript extension for Firefox mitigates CSRF threats by distinguishing trusted from untrusted sites, and removing authentication & payloads from POST requests sent by untrusted sites to trusted ones. The Application Boundary Enforcer module in NoScript also blocks requests sent from internet pages to local sites (e.g. localhost), preventing CSRF attacks on local services (such as uTorrent) or routers.
The Self Destructing Cookies extension for Firefox does not directly protect from CSRF, but can reduce the attack window, by deleting cookies as soon as they are no longer associated with an open tab.
Various other techniques have been used or proposed for CSRF prevention historically:
- Verifying that the request's headers contain
X-Requested-With(used by Ruby on Rails before v2.0 and Django before v1.2.5), or checking the HTTP
Refererheader and/or HTTP
Originheader. However, this is insecure – a combination of browser plugins and redirects can allow an attacker to provide custom HTTP headers on a request to any website, hence allowing a forged request.
- Checking the HTTP
Refererheader to see if the request is coming from an authorized page is commonly used for embedded network devices because it does not increase memory requirements. However, a request that omits the
Refererheader must be treated as unauthorized because an attacker can suppress the
Refererheader by issuing requests from FTP or HTTPS URLs. This strict
Referervalidation may cause issues with browsers or proxies that omit the
Refererheader for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary HTTP request headers using CRLF Injection. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an HTTP request.
- POST request method was for a while perceived as immune to trivial CSRF attacks using parameters in URL (using GET method). However, both POST and any other HTTP method can be now easily executed using XMLHttpRequest. Filtering out unexpected GET requests still prevents some particular attacks, such as cross-site attacks using malicious image URLs or link addresses and cross-site information leakage through
- BREACH (security exploit)
- Confused deputy problem
- CRIME (security exploit)
- Cross-document messaging
- Heap spraying
- Replay attack
- Session fixation
- Web application security
- Shiflett, Chris (December 13, 2004). "Security Corner: Cross-Site Request Forgeries". php|architect (via shiflett.org). Retrieved 2008-07-03.
- Ristic, Ivan (2005). Apache Security. O'Reilly Media. p. 280. ISBN 0-596-00724-8.
- Burns, Jesse (2005). "Cross Site Request Forgery: An Introduction To A Common Web Weakness" (PDF). Information Security Partners, LLC. Retrieved 2011-12-12.
- Christey, Steve; Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. Retrieved 2008-06-07.
- Washkuch Jr., Frank (October 17, 2006). "Netflix fixes cross-site request forgery hole". SC Magazine. Retrieved 2019-02-11.
- William Zeller; Edward W. Felten (October 2008). "Cross-Site Request Forgeries: Exploitation and Prevention" (PDF). Retrieved 29 May 2015.
- Mike, Bailey (2009). "CSRF: Yeah, It Still Works…" (PDF). DEFCON.
- "Security Advisory: CSRF & DNS/DHCP/Web Attacks". Draytek. May 2018. Retrieved 18 May 2018.
- "Cross Site Request Forgery protection | Django documentation | Django". docs.djangoproject.com. Retrieved 2015-08-21.
- Adam Barth, Collin Jackson, and John C. Mitchell, Robust Defenses for Cross-Site Request Forgery, Proceedings of the 15th ACM Conference on Computer and Communications Security, ACM 2008
- Joseph Foulds, Passive monitoring login request forgery, Yahoo Archived 2014-12-22 at the Wayback Machine
- "Cross-Site Request Forgery For POST Requests With An XML Body". pentestmonkey. Retrieved September 4, 2015.
- Sheeraj Shah (2008). "Web 2.0 Hacking Defending Ajax & Web Services" (PDF). HITB. Retrieved September 4, 2015.
- "Security Fix - Weaponizing Web 2.0".
- Dynamic CSRF Archived 2010-02-13 at the Wayback Machine
- Owasp.org: Israel 2012/01: AJAX Hammer – Harnessing AJAX for CSRF Attacks
- Downloads – hasc-research – hasc-research – Google Project Hosting. Code.google.com (2013-06-17). Retrieved on 2014-04-12.
- "Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities".
- "Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF)".
- "Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet". OWASP. Retrieved 2019-07-19.
- "Valhalla Articles - Cross-Site Request Forgery: Demystified".
- "Cross Site Request Forgery protection". Django. Retrieved 2015-01-20.
- "Cross Site Request Forgery (XSRF) Protection". AngularJS. Retrieved 2015-01-20.
- "Making a Service Available Across Domain Boundaries".
- Adamski, Lucas. "Cross-domain policy file usage recommendations for Flash Player - Adobe Developer Connection".
- "Double Submit Cookie defence". OWASP.
- Origin Header Proposal. People.mozilla.org. Retrieved on 2013-07-29.
- "Django 1.2.5 release notes". Django.
- "Cross-Site Request Forgery (CSRF)". OWASP, The Open Web Application Security Project. 4 September 2012. Retrieved 11 September 2012.
- "Secunia Advisory SA22467". Secunia. 19 October 2006. Retrieved 11 September 2012.
- Schneider, Christian. "CSRF and same-origin XSS".