Risk
5/11/2011
12:54 PM
Connect Directly
RSS
E-Mail
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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.