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-7392
Published: 2014-07-22
Gitlist allows remote attackers to execute arbitrary commands via shell metacharacters in a file name to Source/.

CVE-2014-2385
Published: 2014-07-22
Multiple cross-site scripting (XSS) vulnerabilities in the web UI in Sophos Anti-Virus for Linux before 9.6.1 allow local users to inject arbitrary web script or HTML via the (1) newListList:ExcludeFileOnExpression, (2) newListList:ExcludeFilesystems, or (3) newListList:ExcludeMountPaths parameter t...

CVE-2014-3518
Published: 2014-07-22
jmx-remoting.sar in JBoss Remoting, as used in Red Hat JBoss Enterprise Application Platform (JEAP) 5.2.0, Red Hat JBoss BRMS 5.3.1, Red Hat JBoss Portal Platform 5.2.2, and Red Hat JBoss SOA Platform 5.3.1, does not properly implement the JSR 160 specification, which allows remote attackers to exec...

CVE-2014-3530
Published: 2014-07-22
The org.picketlink.common.util.DocumentUtil.getDocumentBuilderFactory method in PicketLink, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 5.2.0 and 6.2.4, expands entity references, which allows remote attackers to read arbitrary code and possibly have other unspecified impact via...

CVE-2014-4326
Published: 2014-07-22
Elasticsearch Logstash 1.0.14 through 1.4.x before 1.4.2 allows remote attackers to execute arbitrary commands via a crafted event in (1) zabbix.rb or (2) nagios_nsca.rb in outputs/.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Where do information security startups come from? More important, how can I tell a good one from a flash in the pan? Learn how to separate ITSec wheat from chaff in this episode.