December 13, 2024

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.

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.

Comments

  1. 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.

    if (isset($_COOKIE[‘ci_token’])) {
    $ci_token = $_COOKIE[‘ci_token’];
    }

    Sending arbitrary HTTP requests with Flash 7/8 (+IE 6.0)
    http://www.securityfocus.com/archive/1/443391

    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.

  2. The article suggests that a POST request can be sent across domain from Firefox
    without extended privileges.
    I do not believe this is possible, unless there is a hole in the same origin policy.

    • This is only true for xmlhttprequest object.
      However, you can have a page with hidden forms that do posts on any server.

  3. 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 are some good resources about this in the following places:
    Blog post: The Web Browser – Security Threat Number One
    http://www.pcis.com/web/vvblog.nsf/dx/the-web-browser-security-threat-number-one

    Devfense web application security
    http://www.boonbox.net/devfense.htm

    White Paper: Implications of outsourcing web application security
    http://www.boonbox.net/pdf/WP_OutsourcingWAS_2008August.pdf

  4. One question, how can you make cross-domain post request from Javascript?

  5. Google released a cool proxy that you can surf your site through and then report potential issues.

    http://code.google.com/p/ratproxy

    -Ben

  6. Hank Roberts says

    How about this, I’ve been wondering why it’s not automagically created as a Firefox option:

    Manually:
    Create a folder for “logoff” bookmarks
    Save a copy of every “logout” link/button that you find to that folder, for example:

    http://www.nytimes.com/logout
    https://www.typekey.com/t/typekey?__mode=user_logout
    http://login.yahoo.com/config/login?logout=1&.src=&.intl=us&.partner=&.done=http://my.yahoo.com/index.html
    http://www.livejournal.com/logout.bml?user=yournamehere

    Whenever you feel the hair on the back of your neck start to stand up as you realize how exposed you might be, choose “Open All in Tabs” from the bottom of the folder contents.

    • 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.

      • not the same. the sessions will still exist on the servers. so if someone has your cookies, theyre still you.

  7. 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?

    • Hey George,

      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.

  8. 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.

  9. 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.

    You can find both free tools at http://www.owasp.org.