June 29, 2022

Archives for September 2008

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.


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.

Quanta Case Preserved the Distinction Between Patent Law and Contract Law

Thanks to Ed for the invitation to contribute to FTT and for the gracious introduction. In addition to being a grad student here at Princeton, I’m also an adjunct scholar at the Cato Institute. Cato recently released the latest edition of its annual Supreme Court Review, a compilation of scholarly articles about the most recent Supreme Court term. It includes interesting articles on a broad range of topics considered by the high court this year, including the Second Amendment, detainee rights, and federalism. Arguably the most important decision from a technology perspective—and the case that was of most interest to me personally—was LG v. Quanta, which dealt with a doctrine known as patent exhaustion. Ironically, I have a somewhat different take on the decision than F. Scott Kieff, the legal scholar who contributed an article to the Review. In today’s post I’ll discuss where I think Kieff’s legal analysis goes astray. Tomorrow, I’ll discuss why the Supreme Court’s ruling turns out to be a good thing in policy terms.

What happened, in a nutshell, was this: Intel wanted to manufacture some chips that were covered by some patents held by LG electronics. Intel obtained a patent license from LG, manufactured the chips, and sold them to Quanta. The contract between LG and Intel stated that the patent license covered only Intel’s manufacturing of the chips, but did not extend to the use of those chips by downstream customers. And so LG sued Quanta for patent infringement, arguing that even though the chips had been manufactured with LG’s consent, Quanta was still guilty of patent infringement for using the chips in its own products.

At the heart of the case is the patent exhaustion doctrine, which says that once a patent holder has allowed the manufacture of a product covered by one of its patents, it exhausts its rights with regard to that product: the patent holder can’t sue downstream customers for patent infringement for using those same products. In a unanimous decision, the Supreme Court ruled that patent exhaustion applies in this case, and Quanta was not required to pay royalties to LG, despite explicit language in LG’s contract with Intel stating otherwise.

Kieff argues that this was a case about freedom of contract. He argues that by limiting the flexibility of patent licensing, it will force the initial licensee to pay the licensing fees for the entire supply chain. As a libertarian, I’m certainly a supporter of freedom of contract. But I think this analysis puts the cart before the horse. Remember that Quanta was accused of patent infringement, not a breach of contract. Therefore, an analysis of the case has to start with patent law. We must first determine whether Quanta’s actions constitute patent infringement under patent law, and only once we’ve determined that Quanta needed a license does it make sense to turn to contract law to see if it had one.

On the other hand, if patent law says that Quanta’s actions are non-infringing, then it’s completely irrelevant what a contract between LG and Intel might have said, because Quanta doesn’t need a license and wasn’t a party to Intel’s contract with LG. Freedom of contract means that parties are free to sign contracts with one another with the confidence that they will be faithfully enforced. It does not mean that contracts can bind third parties who never consented to them. And in this case, the only relevant contract was between LG and Intel. Whether Quanta infringed LG’s patents is a matter of patent law, not contract law.

One reason it’s important to clearly distinguish patent law from contract law is that the law provides patent holders with much stronger remedies than parties to contract disputes. Probably the most important difference is the one I’ve already alluded to: a patent is binding on everyone, whereas contracts only bind those who have explicitly consented to them. On top of that, patent holders can often get injunctive relief—an order from the judge to stop infringing—whereas breaches of contract often result only in money damages. Contract law also frowns on punitive contract terms, whereas patent law offers treble damages for willful infringement.

One way of looking at patent exhaustion, then, is as a doctrine designed to preserve the fundamental distinction between patent law and contract law. LG attempted to bootstrap its patents into an alternative contract-enforcement mechanism. The Supreme Court rejected this gambit, holding that patent law doesn’t allow patent holders to slice their patent licenses infinitely thin in order to force third parties to enter into an implicit contractual relationship with them.

LG is still free to use ordinary contract law to achieve the same result. It could, for example, contractually prohibit Intel from selling its chips to anyone who didn’t already have a licensing agreement with LG. But it must do so under the ordinary rules of contract law. In this case, that would mean requiring Intel to obtain consent to LG’s terms before selling chips, and it would be enforced by filing a lawsuit against Intel for any breach of contract. An important difference is that under this strategy, most of the transaction costs fall directly on LG, rather than being foisted on third parties through the magic of patent law. I think that’s the right result from a legal point of view. In my next post, I’ll explain why this turns out to be an important outcome from a policy perspective.

Election Machinery blog

Students will be studying election technology and election administration in freshman seminar courses taught by at Princeton (by me) and at Stanford (by David Dill).  The students will be writing short articles on the Election Machinery blog.  I invite you all to read that blog over the next three months, to see what a small nonrandom sample of 18-year-olds is writing about the machinery of voting and elections.