Cross-site scripting request forgeries
Attack of the CSRF

Sometimes, even ING, YouTube, The New York Times, and Google get it wrong.
Cross-Site Request Forgery (also referred to as Cross-Site Reference Forgery, CSRF and XSRF) is apidly becoming a serious security problem of which most programmers and users are blissfully unaware. CSRF is a web-based attack that has grown out of, and remains a close cousin to, the more traditional Cross-Site Scripting (XSS) attacks. In an XSS exploit, the attacker inputs malicious content into a web application (e.g., by creating a malformed URL or embedding hostile code in a response box) that results in hostile content such as JavaScript being inserted into otherwise safe content that then is served to the victim. CSRF attacks take it a step further by inserting hostile content that results in an action by the user's web browser, such as changing a filter setting within web-based email or initiating a money transfer from an online bank account.
A CSRF Attack Example
So you go to your favorite social networking site to chat with friends. Unfortunately, the site in question allows users to insert images into web-based conversations (e.g., avatars for a forum). Instead of using a URL such as:
<img src="http://random-site/ image.jpg">
The attacker uses a URL such as:
<img src="http://social-site/changepassword?newpassword= password000">
Thus when a user's web browser attempts to load the image it instead connects to the social networking site and executes a command to change the password.
This attack can also be leveraged from other sites. For example, if a user remains logged into the social network site while browsing the web in another tab and an image on another site points to the change password URL, that tab would execute the command, and unless the site had specific CSRF protections in place, the user's password would end up being changed.
CSRF attacks have become popular for three simple reasons. The first is the emergence of web-based services such as email, online commerce, banking, and so on. CSRF attacks can result in money being sent to an attacker through a web-based bank or stock trading site. Web-based email allows an attacker to reset or request copies of your passwords for various services such as DNS registrars and online commerce sites. Attackers can monetize these attacks by directing access to bank accounts, resetting a user's password, and so on. Something as simple as resetting a password can result in an attacker holding a user's account, domain, or service hostage. For a small fee, the attacker will reset the password and return it to the user (see Figure 1).
The second reason is the presence of tabbed browsing. When web browsers first came out, browsing the web was a largely serial experience. It didn't occur to me for some time that I would ever need more than one session because the content wasn't such that I wanted to stay with it (web browsing was quite literally web browsing). However, with the advent of web-based email, I now have three sessions just sitting logged in so I can send email quickly and be notified when new email comes in. This means that a CSRF attack is much more likely to succeed because I am always logged in to my web-based email (I use a separate browser for my email to prevent exactly this).
The third reason is that most web applications have no security. They are absolutely terrible at filtering user input properly, allowing attackers to inject malicious content (such as JavaScript) via any number of cross-site scripting vulnerabilities. Although I rarely visit hostile websites, I visit a lot of "trusted" websites that I know for a fact have poor filtering that can result in XSS attacks, ultimately allowing for CSRF attacks. Additionally, few web applications implement CSRF protections that will prevent such attacks.
Defenses for Programmers
The way to beat CSRF is simple in concept, and depending on your web-based application, anywhere from easy to almost impossible to implement properly. To beat CSRF attacks, an application simply has to verify that each request is made properly; in other words, your application needs to maintain state so that the content in browser tab 'A' that is logged into your web-based email is the only one allowed to send email, and a request made via content in browser tab 'B' that is accessing a hostile website does not result in email being sent or read. To do this, your web application has to maintain state information. But the web was designed as a stateless system from the very beginning, so any addition of state is going to require some technical trickery because the web browser itself can't help you directly.
To link content in a web page to a request made from that web page properly (i.e., the user fills out a form and hits Submit), you need to pass a one-time token in the content that the web browser then passes back with the request, allowing you to confirm that the request came from the right place.
Send and Receive Tokens
Now this one-time token can be sent and received in a number of ways.
- Hidden Form Fields
<input type="hidden" name="token" value="randomstring" />
The advantage here is that many applications support adding form fields and logic to process them. The disadvantage is that web pages that don't use forms but still allow interaction can't be addressed as easily by this technique.
- URL Components (Within Either the URL or Parameters)
http://example.org/newpassword?new=password&token=randomstring
This one has the advantage of making the data available to the server, so you could, in theory, have an Apache module that validates all requests and simply blocks any invalid ones, preventing the application from ever seeing them. The disadvantage (or potentially an advantage depending on your point of view) is that users can no longer bookmark a page because the one-time token will no longer be valid.
- Cookies
PHP: setcookie("TokenCookie", $randomstring);
Cookies must be enabled for this to work, and potentially they can be stolen by a clever attacker (various browser flaws have allowed for cookie stealing over the years). The advantage of this technique however is that it is largely invisible to the user and does not require either that HTML be displayed to the user or that the URL to be used be modified in any way.
- Requirements of the Back End
All of these examples require some form of back end to store the session data and create session tokens, compare them, and allow or disallow requests based on them. Additionally, web-based applications might need to be modified (e.g., if hidden form fields are used to pass the data). The good news is that more and more web applications are implementing this protection by default. For example, the popular Joomla! Framework has the JRequest::checkToken() function now.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Direct Download
Read full article as PDF:
Security_Lessons_Cross-site_Scripting_Request_Forgeries.pdf (259.83 kB)News
-
Another New Linux Laptop has Arrived
Slimbook has released a monster of a Linux gaming laptop.
-
Mozilla VPN Now Available for Linux
The promised subscription-based VPN service from Mozilla is now available for the Linux platform.
-
Wayland and New App Menu Coming to KDE
The 2021 roadmap for the KDE desktop environment includes some exciting features and improvements.
-
Deepin 20.1 has Arrived
Debian-based Deepin 20.1 has been released with some interesting new features.
-
CloudLinux Commits Over 1 Million Dollars to CentOS Replacement
An open source, drop-in replacement for CentOS is on its way.
-
Linux Mint 20.1 Beta has Been Released
The first beta of Linux Mint, Ulyssa, is now available for downloading.
-
Manjaro Linux 20.2 has Been Unleashed
The latest iteration of Manjaro Linux has been released with a few interesting new features.
-
Patreon Project Looks to Bring Linux to Apple Silicon
Developer Hector Martin has created a patreon page to fund his work on developing a port of Linux for Apple Silicon Macs.
-
A New Chrome OS-Like Ubuntu Remix is Now Available
Ubuntu Web looks to be your Chrome OS alternative.
-
System76 Refreshes the Galago Pro Laptop
Linux hardware maker has revamped one of their most popular laptops.