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.
Today Ed Felten and I (Bill Zeller) are announcing four previously unpublished Cross-Site Request Forgery (CSRF) vulnerabilities. We’ve described these attacks in detail in a technical report titled Cross-Site Request Forgeries: Exploitation and Prevention.
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 describe the four vulnerabilities below:
1. ING Direct (ingdirect.com)
Status: Fixed
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.
2. YouTube (youtube.com)
Status: Fixed
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.
3. MetaFilter (metafilter.com)
Status: Fixed
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.)
4. The New York Times (nytimes.com)
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.
Mitigation
Our paper provides recommendations for preventing these attacks. We provide a server-side plugin for the PHP MVC framework Code Igniter that can completely prevent CSRF. We also provide a client-side Firefox extension that can protect users from certain types of CSRF attacks (non-GET request attacks).
The Takeaway
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.
