Cross-site scripting request forgeries
Attack of the CSRF
Sometimes, even ING, YouTube, The New York Times, and Google get it wrong.
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).
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)
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.
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
Read full article as PDF:Security_Lessons_Cross-site_Scripting_Request_Forgeries.pdf (259.83 kB)
Linux Magazine will include the best of both magazines.
Popular open source encryption tool is vulnerable to attack
New “Yakkety Yak” edition emphasizes cloud and servers
Google finally enters the phone hardware business.
Innovative system adds a hard drive and Ubuntu Core to the RPi for an IoT hub.
Linux is two weeks younger than we thought!
The Apache Software Foundation considers retiring OpenOffice
Adobe won’t kill the plugin in 2017
Linux Foundation's big event celebrates the 25th anniversary of Linux