Popular Websites Vulnerable to Cross-Site Request Forgery Attacks

Update Oct 15, 2008 We’ve modified the paper to reflect the fact that the New York Times has fixed this problem. We also clarified that our server-side protection techniques do not protect against active network attackers.

Update Oct 1, 2008 The New York Times has fixed this problem. All of the problems mentioned below have now been fixed.

We found four major vulnerabilities on four different sites. These vulnerabilities include what we believe is the first CSRF vulnerability that allows the transfer of funds from a financial institution. We contacted all the sites involved and gave them ample time to correct these issues. Three of these sites have fixed the vulnerabilities listed below, one has not.

CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don’t verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.

If a user visits an attacker’s website, the attacker can force the user’s browser to send a request to a page that performs a sensitive action on behalf of the user. The target website sees a request coming from an authenticated user and happily performs some action, whether it was invoked by the user or not. CSRF attacks have been confused with Cross-Site Scripting (XSS) attacks, but they are very different. A site completely protected from XSS is still vulnerable to CSRF attacks if no protections are taken. For more background on CSRF, see Shiflett, Grossman, Wikipedia, or OWASP.

We found a vulnerability on ING’s website that allowed additional accounts to be created on behalf of an arbitrary user. We were also able to transfer funds out of users’ bank accounts. We believe this is the first CSRF vulnerability to allow the transfer of funds from a financial institution. Specific details are described in our paper.

We discovered CSRF vulnerabilities in nearly every action a user could perform on YouTube. An attacker could have added videos to a user’s "Favorites," added himself to a user’s "Friend" or "Family" list, sent arbitrary messages on the user’s behalf, flagged videos as inappropriate, automatically shared a video with a user’s contacts, subscribed a user to a "channel" (a set of videos published by one person or group) and added videos to a user’s "QuickList" (a list of videos a user intends to watch at a later point). Specific details are described in our paper.

A vulnerability existed on Metafilter that allowed an attacker to take control of a user’s account. A forged request could be used to set a user’s email address to the attacker’s address. A second forged request could then be used to activate the "Forgot Password" action, which would send the user’s password to the attacker’s email address. Specific details are described in our paper.

(MetaFilter fixed this vulnerability in less than two days. We appreciate the fact that MetaFilter contacted us to let us know the problem had been fixed.)

Status: Not Fixed. We contacted the New York Times in September, 2007. As of September 24, 2008, this vulnerability still exists. This problem has been fixed.

A vulnerability in the New York Time’s website allows an attacker to find out the email address of an arbitrary user. This takes advantage of the NYTimes’s "Email This" feature, which allows a user to send an email about a story to an arbitrary user. This emails contains the logged-in user’s email address. An attacker can forge a request to active the "Email This" feature while setting his email address as the recipient. When a user visit’s the attacker’s page, an email will be sent to the attacker’s email address containing the user’s email address. This attack can be used for identification (e.g., finding the email addresses of all users who visit an attacker’s site) or for spam. This attack is particularly dangerous because of the large number of users who have NYTimes’ accounts and because the NYTimes keeps users logged in for over a year.

Also, TimesPeople, a social networking site launched by the New York Times on September 23, 2008, is also vulnerable to CSRF attacks.

We hope the New York Times will decide to fix these vulnerabilities now that they have been made public. The New York Times appears to have fixed the problems detailed above.

We’ve found CSRF vulnerabilities in sites that have a huge incentive to do security correctly. If you’re in charge of a website and haven’t specifically protected against CSRF, chances are you’re vulnerable.

The academic literature on CSRF attacks has been rapidly expanding over the last two years and we encourage you to see our bibliography for references to other work. On the industry side, I’d like to especially thank Chris Shiflett and Jeremiah Grossman for tirelessly working to educate developers about CSRF attacks.

Comments

OWASP has made two tools available to help with CSRF problems. The first is CSRFTester which will allow you to test your website for CSRF problems. The tool allows you to create multi-step test cases and has been used to transfer funds, create accounts, issue checks, etc…

The second tool is called CSRFGuard, and it’s a Java EE filter that can be placed in front of an entire application to provide CSRF protection. CSRFGuard uses javascript to insert tokens into forms and links, and then validates the token in every request.

It would be helpful if you linked to the plugin on the CodeIgniter forums. I haven’t seen something like this posted, although EL said a while ago that they’re working on some sort of CSRF protection.
I think quite a few people in the community are not aware of the risks or don’t know how to best go about mitigating them. The way I see it, education is a real problem when it comes to webappsec. Since you provide an explanation as well as a solid solution, not even a lazy person can refuse to take a look.

If I am not mistaken, your CI plugin will not prevent a form from being processed if the user’s browser doesn’t accept cookies or the CSRF token cookie has expired. Shouldn’t the plugin reject all form submissions when there’s any token mismatch, including the missing cookie case?

That cookie exception was the result of a tradeoff between security and usability in non-cookie contexts. I agree with you that the plugin should reject all invalid requests, so I’ve changed it to reflect that. Developers concerned about this can disable (or not install) the plugin.

At least to some degree. If you go (on FF3 on windows) Tool>Clear Private Data (ctrl-shift-del) and select cookies and authenticated sessions (or if you’re feeling more paranoid more cache et all) it will take out almost all your logged in sites.

It just takes a commitment to building security into an application before it goes live. If companies like the NYT and ING Direct took a leadership position in being proactive rather than reactive, the rest would hopefully fall into line. Refusing to do business with organizations that don’t take web security seriously is another possible solution.

There is a problem with a static nonce who’s value isn’t checked server side.

I could have some fancy flash forge the headers. Lets say:
COOKIE[‘ci_token’] = csrf
POST[‘password’] = badguy
POST[‘ci_token’] = csrf
By not having a server side check, your ci plugin allows the attacker to set the nonce to whatever he pleases.

By using a variable nonce (or at least a static one) and storing them in the session variables, you can achieve the proposed outcome. I currently allow the last 5 generated tokens in an active session to be used (overwriting the oldest). These tokens expire after a set time even if the session remains active. This allows for user friendly sites (back button) as well as tabbed browsing.

Freedom to Tinker is hosted by Princeton's Center for Information Technology Policy, a research center that studies digital technologies in public life. Here you'll find comment and analysis from the digital frontier, written by the Center's faculty, students, and friends.