Yahoo "Sign in with Facebook" vulnerability


C Bansal, BITS Goa and INRIA Paris-Rocquencourt
K Bhargavan, INRIA Paris-Rocquencourt
S Maffeis, Imperial College London

Important Dates

November 10, 2011


Once a Yahoo user links her account with her Facebook account, any website she subsequently visits can steal her Facebook access token, and hence steal all of her Facebook profile data that would be visible to Yahoo. Furthermore, the attacker may post arbitrary status message, photos, videos or event chats on the user's Facebook account. This attack is enabled by a combination of Yahoo's weak domain registration at Facebook and an open redirector on Yahoo search.

Relevant Websites

login.yahoo.com, facebook.com

Impact: High

All yahoo users who have linked their accounts to Facebook, either by using the "Sign in with Facebook" feature or say from pulse.yahoo.com


When a user U clicks on "Sign in with Facebook" on login.yahoo.com, Yahoo and Facebook enter into the OAuth 2.0 protocol's explicit flow, and the normal sequence of messages is as follows:
  1. U is redirected to https://www.facebook.com/dialog/oauth with at least two params:
  2. Facebook checks that U has previously given permission to Yahoo application to access her profile and the redirects U back to the above redirect_uri with an additional param: code=AQAAR....
  3. Yahoo then (presumably) uses this code to obtain an access token for U at Facebook, uses the access token to obtain U's facebook identifier, and then logs U into Yahoo
The message flow described above skips many details (the state parameter, access permisions etc) but is enough to explain the vulnerability. Both the code and the token are sensitive. Anyone who obtains the code can try to log in to Yahoo as U. Anyone who obtains the token can access U's Facebook profile, steal her information and exploit her account. It is well known among the designers of the OAuth 2.0 protocol that the redirect_uri must be carefully checked by the authentication server (Facebook) and protected by the OAuth client (Yahoo). For example, suppose Facebook did not check the redirect_uri. Then the following attack would become possible:
  1. U visits an attacker-owned website W
  2. W redirects U to https://www.facebook.com/dialog/oauth with the param:
       app_id=90376669494 [Yahoo's Facebook App Id]
  3. Facebook redirects U back to
    with the param: code=AQAAR...
Hence, W would obtain U's Facebook authorization code for Yahoo. It is for this reason that Facebook only accepts a redirect_uri that matches the domain of the website that is making the request. In this example, Yahoo seems to have registered at Facebook with the domain yahoo.com, so any redirect_uri that matches the pattern http://*.yahoo.com/* is accepted by Facebook. However, this registered domain allows far too many redirect_uri's spread all over the yahoo.com webspace, and this laxity directly leads to our attack, in combination with an open redirector in yahoo search. The attack is described below and is as predicted by the OAuth 2.0 spec. Indeed, the OAuth 2.0 spec explicitly advises that the redirect_uri should be pre-registered and fixed (10.6) and especially that there should be no open redirectors in the redirection space (10.15).



Our attack requires a redirector on yahoo.com that would be willing to redirect the user to a malicious website. We use the redirection built into Yahoo search to demonstrate the attack, but any other open redirector would do. Every webpage W.com indexed by Yahoo search has a corresponding redirection link on www.yahoo.com, roughly of the form:
where the suffix http%3a//W.com is the website that this link redirects the browser to. This URL works across browsers and sessions irrespective of the state, and may be used by a malicious website as an open redirector (as long as the website is indexed by Yahoo.) The attack proceeds as follows:
  1. U visits an attacker-owned website W.com
  2. W extracts the redirection link from Yahoo search using a server side bot.
  3. W redirects U to https://www.facebook.com/dialog/oauth with the param:
       app_id=90376669494 [Yahoo's Facebook App Id]
  4. Facebook redirects U back to
    Note the code parameter AQCTz... sent by Facebook to Yahoo.
  5. Yahoo redirects U again to http://W.com?code=AQCTzpe3ypM[...] Note that the code parameter that was meant for www.yahoo.com has been mistaken attached (by the redirector) to the redirection link W.com instead.
Hence, W obtains U's Facebook authorization code for Yahoo. Using this code W may try to login to Yahoo (but it would need additional information, such as the state parameter.) Even worse, in step 2, W can directly request an access token from Facebook. Facebook then returns the access token as a fragment URI in step 3, which gets attached to the uri in step 4 and can be read by the JavaScript at W.com in step 5. We have built websites to demonstrate both attacks and can provide the code upon request. We also discovered separate but similar attacks on "Sign in with Google" which we will detail in a separate email.


The first and immediate fix to avert this attack is to change Yahoo's registered domain at Facebook to open.login.yahoo.com (or something even more particular, if possible). This would limit redirections to https://*.open.login.yahoo.com/* and prevent the search redirector. Then Yahoo must ensure that all pages under this prefix are free of open redirectors. To prevent token redirections from search.yahoo.com: see suggested fixes.