OAuth (Open Authorization) is a standard authorization protocol. It is used all over the place with SSO providers to allow for a trusted entity, like Google or Facebook, to authenticate you to other sites. However, there are many footguns with this.
The flow for OAuth is as follows:
- User tries to login to some site. It wants proof of their identity via an SSO provider, like Facebook. So, a redirect is made there.
- Upon redirecting with a logged in SSO provider user, a secret is passed to the user. They are then redirected back to the main website.
- The website will take the secret and communicate with the website on who they are. Now, the identity can be made to get information like their email and other things from the SSO provider.
On Vidio, there was an issue with the verification of the access token for the redirect back to the main website. When Vidio would make a request to Facebook (the SSO provider in this case), there is an app identifier (AppID) for each app. However, it is the responsibility of the website (not Facebook) to ensure that the token belongs to their app.
So, by providing a token from another Facebook app that the user controlled, they can return an arbitrary email, which results in an account takeover. This same attack method worked on bukalapak as well. In the case of Grammarly, they used an auth flow that was not vulnerable to this issue by default. By brute forcing parameters they were able to find a flow that was vulnerable to the method mentioned above.
The SSO providers have custom attacks, which is super interesting. To me, it makes sense to force the app developer to specify the AppID instead of requiring manual verification; this is done on one of the Facebook flows already. Considering this, I'm sure many other providers and websites are vulnerable to this attack. Good vulnerability description!