Cross-site request forgery, also known as a one-click attack or session riding and abbreviated
as CSRF 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, which exploits the trust a user has for a particular site,
CSRF exploits the trust that a site has in a user's browser.
History 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 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, 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.
CSRF attacks using image tags are often made from Internet forums, where users are allowed
to post images but not JavaScript.
Limitations 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.
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.
Note that the attack is blind; i.e., the attacker can't see what the target website sends back
to the victim in response to the forged requests, unless they exploit a cross-site scripting
or other bug at the target website.
Similarly, the attacker can only target any links or submit any forms that come up after
the initial forged request if those subsequent links or forms are similarly predictable.
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-guessing
dictionary attacks.
Severity 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.
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.
The attack has been demonstrated against YouTube.
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 on January 2012 - "AJAX Hammer - Dynamic CSRF".
Prevention Most CSRF prevention techniques work by embedding
additional authentication data into requests that allows the web application to detect
requests from unauthorised locations.
Synchronizer Token Pattern Synchronizer token pattern is a technique
where a token, secret and unique 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 unpredactibility and uniqueness.
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:
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,
but at the same makes it 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 tranfers or password change.
This may involve authentication at the same level as used initially to login to the website,
or higher level.
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.
Cookie-to-Header Token Web applications that use JavaScript for majority
of their operatons may use an anti-CSRF technique that relies on same-origin policy:
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=/
JavaScript operating on the client side reads its value and copies it into a custom HTTP
header sent with each transactional request
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
The server validates presence and integrity of the token
Security of this technique is based on the assumption is that only JavaScript running
within the same origin will be able to read the cookie's value.
JavaScript running from a rogue file or email will not be able to read it and copy into
the custom header.
Even though the csrf-token cookie will be automatically sent with the rogue request,
the server will be still expecting a valid X-Csrf-Token.
The CSRF token itself should be unique and unpredictable.
It may be generated randomly, or it may be derived from the session token using HMAC:
csrf_token = HMAC(session_token, application_secret)
The CSRF token cookie must not have httpOnly flag, as it is intended to be read by the
JavaScript by design.
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
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 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 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.
Other techniques Various other techniques have been used or
proposed for CSRF prevention historically: Verifying that the request's header contains
a X-Requested-With, or checking the HTTP Referer header and/or HTTP Origin header.
This however is insecure a combination of browser plugins and redirects which can allow
an attacker to provide custom HTTP headers on a request to any website, hence allowing
a forged request.
Checking the HTTP Referer header 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 Referer header must be treated as unauthorized because an
attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs.
This strict Referer validation may cause issues with browsers or proxies that omit the Referer
header for privacy reasons.
Also, old versions of Flash 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.
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 elements; it also prevents problems with aggressive web crawlers
and link prefetching.
Cross-site scripting vulnerabilities allow attackers to bypass CSRF preventions.
See also Web application security
Confused deputy problem Replay attack
Session fixation Heap spraying
Cross-document messaging CRIME
BREACH References
External links Cross-site request forgery vulnerability on
Nasa.gov Domains 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
XSS Cheat Sheet 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