Risk
5/11/2011
12:54 PM
50%
50%

Facebook Patches Access Token Leak

Users should change their passwords to mitigate threats posed by the accidental leak of perhaps millions of account identity details.

How Firesheep Can Hijack Web Sessions
(click image for larger view)
Slideshow: How Firesheep Can Hijack Web Sessions
Have Facebook advertisers and analytics firms been reviewing your private profile? On Tuesday, security researchers warned that, due to how the site handles access tokens, enterprising third parties would have been able to access users' private data and perform any actions with a user's identity, beginning in 2007.

"Third parties, in particular advertisers, have accidentally had access to Facebook users' accounts including profiles, photographs, chat, and also had the ability to post messages and mine personal information," said Nishant Doshi, a senior principal software engineer at Symantec, in a blog post. He discovered the flaw, together with Symantec's Candid Wueest.

Facebook has reportedly acknowledged and fixed the problem.

Whether anyone had exploited the flaw, however, remains an open question. "There is no good way to estimate how many access tokens have already been leaked since the release of Facebook applications back in 2007," said Doshi. "We fear a lot of these tokens might still be available in log files of third-party servers or still be actively used by advertisers."

To mitigate the threat posed by user credentials lingering in advertisers' log files, change your Facebook password. "Changing the password invalidates these tokens and is equivalent to 'changing the lock' on your Facebook profile," said Doshi.

The flaw resulted because of how Facebook iFrame applications handled access tokens. "Access tokens are like 'spare keys' granted by you to the Facebook application. Applications can use these tokens or keys to perform certain actions on behalf of the user or to access the user's profile," said Doshi. "Each token or 'spare key' is associated with a select set of permissions, like reading your wall, accessing your friend's profile, posting to your wall." Users grant specific permissions to an application when they install it.

But because of the way that Facebook validated tokens, it was also leaking data about those tokens to third parties. Notably, while Facebook now uses OAuth 2.0 to authenticate users, it also supports legacy authentication mechanisms, and thus must assess which type of authentication scheme is being used. During that process, Facebook would sometimes generate an access token by sending an HTTP request--containing the application token in the URL--to the application host. As a result, in some cases Facebook was literally sending its users' access credentials directly to advertisers.

Doshi estimates that almost 100,000 applications exhibited the token-leaking behavior, and that in the past few years, millions of access tokens could have been leaked. According to the social networking site, users install 20 million applications per day.

On a related note, on Tuesday, Facebook updated its developer roadmap. Notably, the roadmap now requires that all sites and applications that work on or with Facebook, by October 1, use only OAuth 2.0 for authentication, process signed requests, and use HTTPS, which requires that they obtain an SSL certificate.

"Over the past few weeks, we determined that OAuth is now a mature standard with broad participation across the industry. In addition, we have been working with Symantec to [identify] issues in our authentication flow to ensure that they are more secure," according to Facebook. "This has led us to conclude that migrating to OAuth & HTTPS now is in the best [interests] of our users and developers."

Facebook first began enabling SSL encryption across its site--but not requiring it for applications or providing it for mobile Facebook clients--in January, in the wake of the release of Firesheep, a free tool for hijacking Web sessions relating to a number of sites, including Facebook, for people using an unsecured wireless hotspot.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-0750
Published: 2015-05-22
The administrative web interface in Cisco Hosted Collaboration Solution (HCS) 10.6(1) and earlier allows remote authenticated users to execute arbitrary commands via crafted input to unspecified fields, aka Bug ID CSCut02786.

CVE-2012-1978
Published: 2015-05-21
Multiple cross-site request forgery (CSRF) vulnerabilities in Simple PHP Agenda 2.2.8 and earlier allow remote attackers to hijack the authentication of administrators for requests that (1) add an administrator via a request to auth/process.php, (2) delete an administrator via a request to auth/admi...

CVE-2015-0741
Published: 2015-05-21
Multiple cross-site request forgery (CSRF) vulnerabilities in Cisco Prime Central for Hosted Collaboration Solution (PC4HCS) 10.6(1) and earlier allow remote attackers to hijack the authentication of arbitrary users, aka Bug ID CSCut04596.

CVE-2015-0742
Published: 2015-05-21
The Protocol Independent Multicast (PIM) application in Cisco Adaptive Security Appliance (ASA) Software 9.2(0.0), 9.2(0.104), 9.2(3.1), 9.2(3.4), 9.3(1.105), 9.3(2.100), 9.4(0.115), 100.13(0.21), 100.13(20.3), 100.13(21.9), and 100.14(1.1) does not properly implement multicast-forwarding registrati...

CVE-2015-0746
Published: 2015-05-21
The REST API in Cisco Access Control Server (ACS) 5.5(0.46.2) allows remote attackers to cause a denial of service (API outage) by sending many requests, aka Bug ID CSCut62022.

Dark Reading Radio
Archived Dark Reading Radio
Join security and risk expert John Pironti and Dark Reading Editor-in-Chief Tim Wilson for a live online discussion of the sea-changing shift in security strategy and the many ways it is affecting IT and business.