Cross-site request forgery
Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
- 1 History
- 2 Example and characteristics
- 3 Forging login requests
- 4 Other approaches to CSRF
- 5 Effects
- 6 Limitations
- 7 Prevention
- 8 See also
- 9 References
- 10 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 are few well-documented examples. About 18 million users of eBay's Internet Auction Co. at Auction.co.kr in Korea lost personal information in February 2008. Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank.
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 been authenticated. For example, one user, Alice, 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 an action on Alice's bank's website (rather than an image file), e.g.,
Mallory: Hello Alice! Look here:
If Alice's bank keeps her authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Alice's browser to load the image will submit the withdrawal form with her cookie, thus authorizing a transaction without Alice's approval.
A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Alice's Web browser which is confused into misusing Alice'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 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.
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.
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.
According to the United States Department of Homeland Security, the most dangerous CSRF vulnerability ranks as the 909th most dangerous software bug ever found. Other 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.
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 fail.
- 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 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 his 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 single 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. At the same time, it is difficult to implement web applications that make heavy use of AJAX.
Additional authentication and CAPTCHA
Some websites choose to repeat user authentication before security-critical operations, such as money transfers or password change. This may involve authentication at the same level as used initially to login to the website (e.g. login and password), or higher level (two-factor authentication). Some websites also require the user to complete a CAPTCHA before security critical operations.
Both methods are effective against CSRF, but require additional user interaction.
- On login, the web application sets a cookie containing a random token that remains the same for the whole user 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
Client side safeguards
Browser extensions such as RequestPolicy (for Mozilla Firefox) 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 payloads from POST requests sent by untrusted sites to trusted ones. 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
Cross-site scripting (XSS) vulnerabilities (even in other applications running on the same domain) allow attackers to bypass most CSRF preventions. However, methods such as additional authentication and CAPTCHA are still effective.
- Web application security
- Confused deputy problem
- Replay attack
- Session fixation
- Heap spraying
- Cross-document messaging
- CRIME (security exploit)
- BREACH (security exploit)
- 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 and Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. Retrieved 2008-06-07.
- "Hacker Steals Data on 18M Auction Customers in South Korea". DarkReader. February 2008. Retrieved 13 April 2012.
- "List of incidents for which Attack Method is Cross Site Request Forgery (CSRF)". Web Application Security Consortium. February 2008. Retrieved 2008-07-04.
- 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
- Inferno Security Blog Brute-forcing CSRF tokens
- Weaponizing Web 2.0
- Dynamic CSRF
- 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.
- US-CERT vulnerability list by severity metric
- cPanel Remote Root
- OpenCA CSRF
- "Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet". OWASP. Retrieved 2014-07-24.
- 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.
- Client access policy file to allow cross-domain access by Silverlight controls
- Cross-domain policy file usage recommendations for Flash Player
- 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.
- "Article about CSRF and same-origin XSS"
- "OWASP cheat sheet discussing XSS"
||This article's use of external links may not follow Wikipedia's policies or guidelines. (April 2015)|
- Cross-site request forgery (CSRF) vulnerability on Nasa.gov Domains
- How To Prevent CSRF and XSRF Attacks
- A Most-Neglected Fact About Cross Site Request Forgery
- Using XSS to bypass CSRF protection
- eLearning: Cross-Site Request Forgery Explained
- The Cross-Site Request Forgery FAQ
- Free Cross-Site Request Forgery Solution from OWASP
- Cross-Site Request Forgery: Demystified
- Cross-Site Request Forgery from The Web Application Security Consortium Threat Classification Project
- How to prevent CSRF in Java based web applications
- Spring MVC support for CSRF prevention
- CSRF and state mutation on read requests
- CSRF/XSRF Online generator
- Hurdles to getting CSRF protection correct (in Java web-apps)