Facebook Connect flaws can't or won't be fixed: researcher

Facebook is unwilling or unable to fix two vulnerabilities affecting Facebook Connect, according to a security researcher, leaving any site that uses the feature at risk, and users' information exposed.

Self-described web security evangelist Egor Homakov has described the two vulnerabilities on his blog, the first of which deals with linking an attacker's Facebook profile with the service the victim is trying to use.

According to Homakov, an attacker can load an inline frame that automatically submits the username and password for an account under their control to Facebook. It is a relatively simple process, involving a few lines of inline JavaScript, but it does expose the credentials for the attacker's account.

When successful, a user could be tricked into unknowingly logging into someone else's account. The implications of doing so could include sharing information with this account, not knowing it is controlled by someone else.

"Every website with 'Connect your Facebook to main account to log in faster' functionality is vulnerable to account hijacking," Homakov wrote.

According to him, a solution to this problem would be to require a token that first ensures the site that the user is trying to connect to knows that the process started from them and not from an outside party.

Facebook responded to Homakov's concerns in an email, but noted that it would not be issuing a fix.

"This is one of those areas that we've been aware of for awhile, but don't really have a systematic solution," Facebook's reply email to Homakov said.

Facebook also addressed why Homakov's suggestion to implement a cross-site request forgery (CSRF) protection token would not be practical.

"Enforcing login CSRF protection is something that has been a non-starter here for a number of years, as every attempt to enable it has broken a huge number of extensions, integrations, and other shenanigans. I suspect it'll take a relatively severe issue to warrant the breaking change."

The second vulnerability exposes the access tokens for applications that are connected to Facebook.

When users authorise an application to connect with Facebook and subsequently log in, an access token is used to ensure that requests are authorised. If these tokens are stolen, an attacker would have the same privileges as the application they are attacking. In some cases, this can include posting to users' timelines, or viewing sensitive information.

Homakov points out a significant quirk in how most redirects work online, which supports this vulnerability.

For example, ZDNet's own redirector, ZD.Net, will go to ZDNet.com. The quirk in how redirects work, however, is that if a URL is appended with a #, which is often done to help navigate through sections of a webpage, that appended information is also forwarded to the final redirected location.

That is, http://ZD.Net#randomInformation, will ultimately send a user to http://www.ZDNet.com#randomInformation.

The redirect quirk is important because of the logging-in process. Facebook's API requires an Application ID, a redirect URI, and, optionally, a response type. If the response type is set to "token", then once a user is logged in, their browser will redirect to the redirect URL specified with the access token appended to the end of it.

Given that anyone can change the redirect URL, app developers are required to specify in their application's settings which URIs are permitted. This is meant to ensure that if the token is appended to the URL, it remains on their domain.

However, if an application's whitelist only contains the domain name, subdomains, and any URLs that have the domain name in it are considered acceptable places to redirect to immediately after login. This means that if a redirector is present on the domain, it too will be considered an acceptable redirect URL.

An attacker can then provide a redirect URL that points to the redirector on the domain (which is whitelisted), but which in turn points to their own server. This login request can be served to the victim in a number of ways, including via a phishing email. At this point, the access token is forwarded through the redirector to the attacker's server, allowing them to steal it by using some JavaScript on a crafted page. It would theoretically be possible for an attacker to further redirect the request back to the original endpoint, to provide the illusion that nothing had happened.

ZDNet has confirmed that access tokens captured in this way do expose user information at the same level to which the application has been granted access. Homakov claims that it would also be possible to log in to the linked service as if they had the user's Facebook credentials.

A Facebook security engineer responded on Hacker News that developers should be restricting which URLs can be redirected to in their application whitelist.

Given the measures that Facebook has put in place, coupled with the fact that open redirects beyond Facebook's control are at the heart of this vulnerability, the social network could be absolved of blame. However, Homakov notes that getting rid of redirects is a difficult thing for developers to do.

"Facebook clients like Soundcloud, Songkick, Foursquare are at the same time OAuth providers too, so they have to be able to redirect to third-party websites. Each redirect to their 'sub' clients is also a threat to leak Facebook's token."