Twitter: Bypassing Digits bridge origin validation

ID H1:110467
Type hackerone
Reporter filedescriptor
Modified 2017-04-30T15:41:17


Hi, I would like to report an issue in the bridge proxy in Digits which allows attacker to retrieve the OAuth credential data of an application victims authorized.


In the Digits Web SDK, the method getLoginStatus can be used to retrieve the OAuth credential data of an application if the user has already logged in Digits and authorized the app. The way it works is to inject an hidden iframe (I call it bridge because the URL is which acts like a proxy into the webpage and communicate using postMessage. Once the bridge receives the getLoginStatus command, it will make an AJAX request to /login_status and the response will contain the OAuth credential data of the user of an application. Then, the bridge will send back the data via postMessage to parent window.

For example:

+----------------------------------------------------------------------------------+ | | +----------------------------------------------------------------------------------+ | | | +----------------------------------------------------------------------------+ | | | | | | +----------------------------------------------------------------------------+ | | | | | | | ^ + | | | +----------------------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | + v | | getLoginStatus OAuth Credential | | | +----------------------------------------------------------------------------------+

If invokes Digits.getLoginStatus(), then an iframe will be injected where the host parameter is the invoker origin.

There's a protection in place which validates whether the host parameter provided matches the application registered domain. For example, /bridge?consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host= passes while /bridge?consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host= fails. This prevents others to use the same consumer_key to pretend to be the legit application to issue the command.

However, there is no validation to check whether the page which embeds the bridge proxy is from the registered domain. In other words, attacker can manually embed /bridge?consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host= into his/her webpage and issue command on behalf of the legit application.


It affects every application that has integrated Digits, and even official application (Periscope). Attacker can abuse the flaw to login to victim's account on the affected applications. In addition, this attack does not require user interaction. The only prerequisite is that the victim has already logged in Digits and authorized the application.


  1. Prepare a Periscope account which is associated with a phone number, and make sure you have logged in Digits ( with that number
  2. Go to
  3. Wait for a while
  4. You Periscope account will be renamed as "Pwn3d"

Video demo: (password: proxy)

And as always, since it does not require user interaction, it can be put into a player card to achieve maximum stealthiness.


It would be ideal to employ CORS instead of postMessage + proxy for that purpose. An alternative fix would be to check whether the page embedding the bridge proxy is from the registered domain by comparing referrer (pretty unsound though).