Popular Websites Vulnerable to Cross-Site Request Forgery Attacks

By Bill Zeller - Posted on September 29th, 2008 at 6:19 am

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.

Tagged:

wzeller's blog

Don't forget OWASP CSRFTester and CSRFGuard

Comment by Jeff Williams on September 29th, 2008 at 8:53 am.

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.

Make it known

Comment by Pascal Kriete on September 29th, 2008 at 4:17 pm.

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

Comment by George on September 29th, 2008 at 7:33 pm.

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

Comment by Bill Zeller on September 29th, 2008 at 9:13 pm.

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.

Collect "logout" bookmarks, "open all" to, er, close all?

Comment by Hank Roberts on September 29th, 2008 at 10:05 pm.

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=&.d...
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.

It exists.

Comment by Phyzz on September 30th, 2008 at 12:34 am.

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

Comment by Anonymous on September 30th, 2008 at 9:54 am.

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

Pingback

Comment by Ajaxian &raquo; Report and Case Study on CSRF on September 30th, 2008 at 7:41 am.

[...] Zeller and Ed Felten have published a report on Cross-Site Request Forgery attacks on popular Web sites: We found four major vulnerabilities on four different sites. These vulnerabilities include what [...]

Pingback

Comment by Liquidmatrix Security Digest &raquo; Security Briefing: on September 30th, 2008 at 7:44 am.

[...] Popular Websites Vulnerable to Cross-Site Request Forgery Attacks | Freedom to Tinker [...]

Pingback

Comment by CompuSec.Org &raquo; Blog Archive &raquo; CSRF: Cros on September 30th, 2008 at 9:16 am.

[...] Ed Felton and Bill Zeller have found this vulnerability in some very popular sites. Here is the quick status to get right down to what interests you. [...]

Pingback

Comment by Ajax Girl &raquo; Blog Archive &raquo; Report and Ca on September 30th, 2008 at 10:23 am.

Pingback

Comment by Cristiano on Tech/Life &raquo; My Bookmarks For Septembe on September 30th, 2008 at 1:06 pm.

[...] Popular Websites Vulnerable to Cross-Site Request Forgery Attacks | Freedom to Tinker - You would be amazed how little developers know about CSRF attacks and more precisely, how to protect against them. [...]

Pingback

Comment by PabloG &raquo; Blog Archive &raquo; links for 2008-0 on September 30th, 2008 at 8:01 pm.

[...] Popular Websites Vulnerable to Cross-Site Request Forgery Attacks | Freedom to Tinker (tags: security browser hack web Internet webdesign) b94 [...]

Pingback

Comment by My Pen Test &raquo; Cross-Site Request Forgery Whitepape on September 30th, 2008 at 10:34 pm.

[...] researchers released a research paper yesterday which documents Cross-Site Request Forgery vulnerabilities in 4 well known commercial websites (ING Direct, NY Times, Youtube, and Metafilter). It makes for interesting [...]

Pingback

Comment by Javascript News &raquo; Blog Archive &raquo; Report on September 30th, 2008 at 10:46 pm.

Googles RatProxy

Comment by Mr-Yellow on October 1st, 2008 at 12:12 am.

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

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

-Ben

Pingback

Comment by Cross-Site Request Forgeries: Exploitation and Prevention | on October 1st, 2008 at 10:58 am.

[...] Popular Websites Vulnerable to Cross-Site Request Forgery Attacks [...]

Pingback

Comment by Schwachstelle in Banken-Site ermöglichte unautorisierte Über on October 1st, 2008 at 11:46 am.

[...] sind jedoch auch zahlreiche weitere größere Webseiten betroffen, wie auf freedom-to-tinker.com zu lesen ist. Diesen Post [...]

Pingback

Comment by CSRF Flaws Found On Major Websites, Including a Bank | Kaize on October 1st, 2008 at 11:52 am.

[...] 0. http://www.darkreading.com/document.asp?doc_id=164854&WT.svl=news1_1 1. http://www.freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerabl...... 2. http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Popularity: unranked [?] Listen [...]

Pingback

Comment by New CSRF paper with vulnerability disclosure [Jeremiah Gross on October 1st, 2008 at 1:07 pm.

[...] Ed Felten and Bill Zeller recently released a very well-written paper about Cross-Site Request Forge..., including some real-world vulnerability examples from ING Direct, YouTube, MetaFilter, and The New York Times. As you all know so well, CSRF vulnerabilities are easy find when you just decide to look on basically any website. Don’t expect any ground breaking research per-say, but the papers content is really helpful to those unfamiliar with CSRF (and that’s still a lot people - especially developers). Ed and Bill also did some work on a potential client-side solution, like LocalRodeo I think, which I hope to find time to investigate further. We need as many smart people as we can trying to solve this problem in creative ways. CSRF certainly isn’t going to go away anytime soon. WhiteHat Security is a leading provider of web application security services. WhiteHat Sentinel, the companys flagship service, provides continuous web applications vulnerability assessment and management. [...]

Pingback

Comment by Dirk&#8217;s Blog &raquo; Popular Websites Vulnerabl on October 1st, 2008 at 4:03 pm.

[...] Read more here. [...]

Pingback

Comment by New CSRF paper with vulnerability disclosure [Jeremiah Gross on October 1st, 2008 at 7:32 pm.

One question, how can you

Comment by T. Galan on October 2nd, 2008 at 9:59 am.

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

Pingback

Comment by TrustMe Blogs &raquo; Web bug causing trouble on October 4th, 2008 at 11:09 am.

[...] out of a user’s account, or to create additional accounts of behalf of a victim, according to this post from Freedom to Tinker blogger Bill Zeller.” addthis_url = [...]

Pingback

Comment by Del.icio.us op 6 oktober 2008 | Michel Vuijlsteke's web on October 6th, 2008 at 11:05 am.

[...] - Popular Websites Vulnerable to Cross-Site Request Forgery Attacks | Freedom to Tinker (tags: [...]

Websites can be made secure

Comment by Bob on October 6th, 2008 at 3:47 pm.

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

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

same origin policy

Comment by Anonymous on October 9th, 2008 at 9:29 am.

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

Comment by Anonymous on October 17th, 2008 at 6:40 am.

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

Pingback

Comment by Preventing CSRF and XSRF Attacks &raquo; Good Idea, Bad on October 16th, 2008 at 2:11 am.

[...] the Freedom to Tinker blog, Bill Zeller offers one of the best, most concise explanation of XSRF that I’ve read to date: [...]

Pingback

Comment by Cross-site request forgery prevention | idea drought on October 16th, 2008 at 10:49 am.

[...] Bill Zeller offers a good description of what this is 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. [...]

Pingback

Comment by CSRF Riskindeki Siteler | KnbykL | Web Güvenliği, Güvenlik D on October 19th, 2008 at 1:37 pm.

[...] Referans: Freedom to Tinker [...]

Pingback

Comment by Preventing CSRF and XSRF Attacks - Programming on October 20th, 2008 at 3:03 pm.

[...] the Freedom to Tinker blog, Bill Zeller offers one of the best, most concise explanation of XSRF that I've read to [...]

Pingback

Comment by Cross-Site Request Forgery - rattlab.net on October 21st, 2008 at 12:39 pm.

[...] populäre Seiten betroffen sind, zeigt eine Ausarbeitung von Bill Zeller und Ed Felten. In einem Blog-Eintrag sprechen sie unter anderem über YouTube, wo so ziemlich alles anfällig war, aber auch über eine [...]

Pingback

Comment by Netmedia &raquo; Blog Archive &raquo; Cross-Site Req on October 31st, 2008 at 10:09 am.

[...] cross-site request forgery es una realidad y aunque usé a Amazon como un ejemplo, hay casos reales documentados y un muy buen paper del tema creado por William Zeller y Edward Felten que está con muchos más [...]

Pingback

Comment by List Your Blog &raquo; Blog Archive &raquo; Cross-si on November 6th, 2008 at 8:25 pm.

[...] see also Bill Zeller’s blog post describing the attack and the Wikipedia page for cross-site request [...]

Pingback

Comment by Cross-site request exploits | Tu msn on December 5th, 2008 at 3:22 am.

[...] see also Bill Zeller’s blog post describing the attack and the Wikipedia page for cross-site request [...]

Static Nonce

Comment by david on December 6th, 2008 at 5:47 am.

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.

Chirs

Comment by Sherwood park jobs on December 9th, 2008 at 10:36 pm.

This site is really interesting for excisting people.

Sherwood park jobs

OWASP

Comment by Anonymous on December 31st, 2008 at 12:49 am.

OWASP

Einladung

Comment by Sergej Klein on January 26th, 2009 at 2:25 pm.

come 2 me

Pingback

Comment by Pro Information Center &raquo; Blog Archive &raquo; on January 28th, 2009 at 3:15 am.

[...] of private data and other high value targets from end-users’ PCs to popular web applications, interest in CSRF and other web application vulnerabilities will only continue to [...]

Pingback

Comment by IE8 Security Part VII: ClickJacking Defenses | Techno Portal on January 28th, 2009 at 12:15 pm.

[...] of private data and other high value targets from end-users’ PCs to popular web applications, interest in CSRF and other web application vulnerabilities will only continue to grow. As we designed Internet [...]

fx infinity fx 主婦 4 億ディ

Comment by きろきろ on January 31st, 2009 at 9:05 pm.

カリビアンコム　姫川麗カリビアンコム　白石ひよりカリビ

Comment by Anonymous on February 7th, 2009 at 1:55 pm.

Pingback

Comment by Блог команды разработчиков Internet Explorer 8 : IE8 Securit on February 12th, 2009 at 6:19 am.

[...] пользователей к популярным веб-приложениям, интерес к CSRF и другим уязвимостям веб-приложений будет только [...]

Pingback

Comment by Блог команды разработчиков Internet Explorer 8 : Защита от C on February 16th, 2009 at 5:39 am.

Pingback

Comment by Блог команды разработчиков Internet Explorer 8 : Защита от C on February 16th, 2009 at 6:10 am.

Pingback

Comment by Cross-site request exploits | Locuras del web on February 21st, 2009 at 1:42 am.

[...] see also Bill Zeller’s blog post describing the attack and the Wikipedia page for cross-site request [...]

Action In Love

Comment by kkdai on March 9th, 2009 at 5:06 am.

我是一片孤傲的楓樹葉倔強的掛在秋後的樹枝上

Sorry, comments closed.

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.