Risk
5/11/2011
12:54 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

CVE-2014-2392
Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

CVE-2014-2393
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in Open-Xchange AppSuite 7.4.1 before 7.4.1-rev11 and 7.4.2 before 7.4.2-rev13 allows remote attackers to inject arbitrary web script or HTML via a Drive filename that is not properly handled during use of the composer to add an e-mail attachment.

CVE-2011-5279
Published: 2014-04-23
CRLF injection vulnerability in the CGI implementation in Microsoft Internet Information Services (IIS) 4.x and 5.x on Windows NT and Windows 2000 allows remote attackers to modify arbitrary uppercase environment variables via a \n (newline) character in an HTTP header.

CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Best of the Web