Three more OAuth flow vulnerabilities

First some quick background, Oauth flows to apps can use a custom URI as a whitelisted callback url, the challenge is that any application can register that same handler and recieve the callback. So Facebook does apply some defenses against this.

1. If in a webview from within the Facebook or Workplace applications they whitelist redirects with specific schemes and block some of their generic ones like fb{APP_ID://
2. If using a mobile browser they ask for confirmation rather than immediately redirecting.
3. Check for certain headers that indicate its a native login using the ProxyAuth activity expored by com.facebook.katana
4. If the headers are found, then an addition key calling_package_key or android_key needs to be provided which indicate the application that started the ProxyAuth activity

Stealing a Workplace Account First-Party Access Token

The Workplace OAuth flow didn’t implement the confirmation prompt (second defense from the list above) so one could pull off the traditional attack flow against the work.workplace.com/dialog/oauth endpoint by first registering a fb{{First-party Workplace App id}}://authorize URI scheme, and then trigger an OAuth login redirecting to it.

Abusing ProxyAuth Activity

The ProxyAuth activity usually will generate an android_key to send along with the request to indicate the calling application. In some cases ProxyAuth will fail to generate a key which results in an empty key being send. While the m.facebook.com/dialog/oauth endpoint would result in a authorization dialog, the workplace endpoint would immediately redirect successfully.

Bypassing WebView URI Whitelist

The author found that if xd_arbiter or dialog/return/arbiter endpoints were specified in the redirect_uri and used a fb:// schema then it would redirect to fb://www.facebook.com which an attacker could potentially control.