A Brief History of CSRF

October 4, 2005 cyber world witnessed its fastest spreading worm called samy virus of all time that was designed to propagate across the MySpace social-networking site written by Samy Kamkar. Within just 20 hours of its release, over one million users had run the payload that displayed the string “but most of all, samy is my hero” on a victim’s MySpace profile and send Samy a friend request. This worm is well known as first Cross-Site Scripting (XSS) worms in the history which use Cross Site Request Forgery (CSRF) for its replication. Sounds cool. Isn’t it?

What is CSRF?
Cross Site Request Forgery (also known as XSRF, CSRF, Sea Surf, Session Riding and Cross Site Reference Forgery) is an attack that tricks victim into taking some action on the vulnerable application without the victim’s knowledge. This can happen when the victim visits a webpage that contains a malicious request, which then performs the chosen action on behalf of the victim.

Anatomy of CSRF
CSRF is a type of confused deputy attack which leverages the authentication and authorization of the victim when a forged request is being sent to the web server. Therefore, a CSRF vulnerability affects highly privileged users, such as administrators, could result in a full account takeover. During a CSRF attack, the victim’s browser is tricked into sending HTTP requests to the web application as intended by the attacker, normally, such a request would involve submitting forms present on the web application to alter some data. Upon sending an HTTP request (legitimate or otherwise), the victim’s browser will include the Cookie header. Cookies are typically used to store a user’s session identifier in order to avoid the user from having to re-authenticate for each request, which would obviously be impractical. If the victim’s authentication session is stored in a Cookie which is still valid (a browser window/tab does not necessarily need to be open), and if the application is vulnerable to CSRF, then the attacker can leverage CSRF to launch any desired requests against the website, without the website being able to distinguish whether the requests are legitimate or not.

CSRFs are typically performed using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.


FIG: Basic CSRF Anatomy

Let’s take an example: Alice, might be browsing a chat forum with Bob who has posted a message. Suppose that Bob has crafted an HTML image element that references a feature/Webpage on Alice’s bank’s website (rather than an image file), e.g.

<img src=”http://www.examplebank.com/transfer?acc=Alice555&amt=10000&cur=USD&for=Bob4444″>

If Alice’s bank keeps her authentication information in a cookie, and if the cookie hasn’t expired, then Alice’s browser’s attempt to load the image will submit the withdrawal form with her cookie, thus authorizing a transaction without Alice’s approval. In the above example Alice’s web browser is misled into withdrawing amount from Alice’s account for Bob.


FIG: Condition of successful CSRF attack

Who can be the victim of CSRF?
Web applications that perform action-based input from authenticated users without insisting the user to authorize the specific action are at risk.

CSRF attacks are more likely to be carried out on applications that are transaction oriented like online banking, e-Commerce Sites etc. Web applications that implement only simple query/retrieval features are in general not susceptible to CSRF attacks, as they do not perform any modification or updating on the user’s behalf. Nowadays, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, SSL certificates.

Applications that allow posting of user content like forums, messages etc. are often vulnerable to CSRF attacks. For example, a specially crafted message (embedded image request) on a message forum may compromise the account details of other users viewing message.

Applications that use persistent cookies are also vulnerable to CSRF attacks, since the users are “always logged in”. Users could trigger an action on the target application when they visit another blog/site that contains a specially crafted URL of the target application.

Some notable incident about CSRF:

  • The Netflix website in 2006 had numerous vulnerabilities regarding CSRF, which could have allowed any 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 CSRF attack that allowed illicit money transfers.
  • Gmail contained CSRF vulnerability. This vulnerability was reported on July 2007. Gmail provides email <href=”http://mail.google.com/support/bin/answer.py?hl=en &answer=6579″> filters that allow users to sort and forward mail, this feature was found to be vulnerable to CSRF.
  • Yahoo contained CSRF vulnerability that was reported on October 2007. It was possible to add or delete in the yahoo calendar entries from a malicious site. The specially crafted HTML on a malicious site adds a task and an event to the victim’s calendar.
  • 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.
  • 17-year-old boy unleashed a computer virus called Mikeyy Twitter Worm on 11th April 2009 which spreaded 10000+ tweets across twitter.com using XSS and CSRF combination

XSS – The Sleeping Giant:

The two attacks are different and are rivals when it comes to damage, popularity and ease of enacting, but they can also work together and when that happens, the consequences are far more lethal. In order to see how XSS can aid CSRF, we have to look at common CSRF countermeasures.

The simplicity of a CSRF attack, as well as the implications of the attack being successful, make it a serious security concern when it comes to developing web applications. Hence, countermeasures are taken to prevent CSRF: anti-csrf token-based countermeasures, referrer or origin verifications and user unfriendly methods such as CAPTCHA codes, re-authentication, etc.

However, if there is an XSS vulnerability, then malicious XSS payloads may allow attackers to execute code in the user context and render CSRF protection measures useless.

If you read the document thoroughly till now, you probably noticed various kind of worms hit cyberworld which use this lethal combination of XSS and CSRF like Samy worm (2005), Mikeyy Twitter Worm (2009) etc.

Reading cookie based Anti-CSRF token using XSS

If anti-CSRF tokens are stored in cookies, XSS attacks can be used to read the cookies and obtain the tokens which need to be embedded in the malicious requests in order for them to be successful. If the tokens are generated by the server, then XSS can be used to read (GET) a page on the server (XMLHttpRequest), record the valid token and embed it in the malicious requests, making CSRF possible.

By using XMLHttpRequest (XHR) objects to interact with servers, we can retrieve data from a URL without having to do a full page refresh. This feature enables any page to update just part of a page without disrupting what the user is doing. This is used heavily in Ajax programming.

As for example: https://www.mybank.com/transfer protects all the POST requests with a token. If there is an XSS vulnerability on the same domain (let’s say https://www.mybank.com/accounts) then an XSS attack can be used to read the tokens used by https://www.mybank.com/transfer:

//get token by opening a page where POST is protected by the token
varpage = new XMLHttpRequest();
//open any page protecting POST with token
page.open(“GET”, “https://www.mybank.com/accounts/home”, false);
var ID = page.responseText;
var i = ID.indexOf(“tokenidentifier”);
ID = ID.substring(i,ID.length).substr(x,y);

//embed token into CSRF request
page.open(“POST”, “https://www.mybank.com/accounts/transfer.asp”, false);
var params = “sum=100&amp;target=D093487324&amp;tokenidentifier=”+ID;
page.setRequestHeader(“Content-length”, params.length);


FIG: Reading Anti-CSRF token using XSS

Reading Anti-CSRF token stored within page
To remediate the devastating effect of XSS and CSRF together, many developers used to store anti-CSRF token within response pages. If anti-CSRF tokens are stored within client side response pages then it is possible to read that token. That token can be located anywhere within the response page i.e: meta tags, hidden fields etc. To read this token one mandatory condition is: In that web application anti-CSRF token should be used only for form based data modification (POST).

Let’s assume web developers of mybank.com now remove anti-CSRF token from cookies value and store the token within the page in meta tag.


FIG: Anti-CSRF token in Meta tag

To read the token attacker first hit the home page https://www.mybank.com/accounts/home which returns the requested page with anti-CSRF token within the page. Attacker dynamically grab the token and pass the token to the transfer.asp which will ask for money transfer by using legitimate anti-csrf token.

var viewUrl = “https://www.mybank.com/accounts/home”;
var transferURI = “https://www.mybank.com/accounts/transfer.asp?sum=100&target=D093487324”
function getMetaTagValues(metaTagName){
var x = document.getElementsByTagName(“META”);
var txt = “”;
var i;
for (i = 0; i < x.length; i++) {
if (x[i].name==metaTagName)
return (x[i].content);
function loadXMLDoc() {
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById(“message”).innerHTML =”Page Loading…”;
document.getElementById(“demo”).innerHTML = this.responseText;
_csrf = getMetaTagValues(‘_csrf’);
_csrf_header = getMetaTagValues(‘_csrf_header’);
xhttp.open(“GET”, viewUrl, true);
function postCSRF(_csrf_header,_csrf){
document.getElementById(“message”).innerHTML = “Getting Resources…”
var params = “”;
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById(“message”).innerHTML = “CSRF Completed…”;
xhttp.open(“POST”, transferURI, true);
document.getElementById(“message”).innerHTML =”Transfer Done …”;

CSRF Generation Tools

  • OWASP CSRFTester: This tool has been developed by OWASP for testing CSRF in any websites. It is a Java based freeware.
  • Pinata CSRF Tool: Pinata was developed to assist with the explanation of the Cross Site Request Forgery and how a vulnerable application can be exploited – this is often useful when you are making a PoC of CSRF
  • Burp Suite Pro: In free version of Burp, “Generate CSRF PoC” is disabled. In Pro edition this feature is enabled and helps user to create a html-based Proof of Concept to reproduce the CSRF scenario.


CSRF Prevention – Anti-CSRF tokens – Final Approach

The recommended and the most widely used prevention technique for preventing Cross-site Request Forgery (CSRF) attacks is known as an anti-CSRF token, also sometimes referred to as synchronizer tokens.

When a user submits a form or makes some other authenticated request that requires a Cookie, the anti-CSRF token should be included in the request. The web application will then verify the existence and correctness of this token before processing the request. If the token is missing or incorrect, the request can be rejected.

It’s highly recommended that you use an existing, well tested and reliable anti-CSRF library. Depending on your language and framework of choice, there are several high-quality open source libraries that are ready-to-use.

The characteristics of a well-designed anti-CSRF system involve the following attributes:

  • The anti-CSRF token should be unique for each user session
  • The anti-CSRF token should be stored browser’s local/session storage
  • The anti-CSRF token should be used for each and every HTTP(S) request
  • The session should automatically expire after a suitable amount of time
  • The anti-CSRF token should be a cryptographically random value of significant length
  • The anti-CSRF token should be cryptographically secure, that is, generated by a strong Pseudo-Random Number Generator (PRNG) algorithm
  • The server should reject the requested action if the anti-CSRF token fails validation.


FIG: CSRF token usages statics



  • https://www.paladion.net/blogs/csrf-the-hidden-menace
  • https://www.incapsula.com/web-application-security/csrf-cross-site-request-forgery.html
  • https://en.wikipedia.org/wiki/Cross-site_request_forgery
  • https://www.cdnetworks.com/resources/whitepapers/sg/Whitepaper22.pdf
  • https://www.slideserve.com/maja/cross-site-request-forgery-csrf-attacks
  • https://www.owasp.org/images/8/8c/OTD2011-SK.pdf
  • https://www.acunetix.com/blog/articles/cross-site-request-forgery/
  • https://trends.builtwith.com/docinfo/CSRF-Token
  • https://en.wikipedia.org/wiki/Samy_(computer_worm)
  • https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest


Co-Author: Soumen Maitra

Soumen Maitra has 10+ years of web development experience. He is in InfoSec field for last 2 year. Being a web developer profile, made Soumen technically strong in Web Application Penetration Testing. He is currently working in an Multinational Company as Senior Security Analyst.

Email: maitra.soumen@gmail.com


Leave a Reply

Your email address will not be published. Required fields are marked *

Secured By miniOrange