Failure to verify OAuth tokens enables account takeover on websites

Researchers have found yet another OAuth implementation error on various websites that allow users to authenticate with their identities from third-party services such as Facebook or Google. Some sites fail to complete an important step in the OAuth authorization chain that involves validating for which app an access token was issued by the identity provider.

By exploiting this security oversight an attacker could collect tokens issued to a decoy app or website they set up and then use them to access the accounts of the victims on sites that are vulnerable to this issue.

Researchers from security firm Salt Security demonstrated the problem on three popular websites: popular typing assistance service Grammarly, Indonesian video streaming site Vidio, and Indonesian e-commerce platform Bukalapak.

While these companies were privately notified and fixed the problem, all organizations should check their implementations to make sure they’re not exposing their users to similar attacks.

“Just these three sites are enough for us to prove our point, and we decided to not look for additional targets, but we expect that thousands of other websites are vulnerable to the attack we detail in this post, putting billions of additional Internet users at risk every day,” the Salt Security researchers said in their report.

Access tokens are tied to their requesting apps

OAuth is a highly popular Web authorization and pseudo-authentication standard, through which one website or app can ask an identity provider such as Google, Facebook, Apple, or Microsoft to verify that a user is who they claim to be. This makes the authentication process easier for users, as they don’t have to create and remember separate passwords for different sites and can choose to use their Facebook, Google or Microsoft identities.

In reality OAuth does more than just authentication. The mechanism allows users to grant external websites access to various information on their profiles with the identity providers via the provider’s API.

However, this issue found by Salt Security applies to the authentication part where a site asks the identity provider to confirm that the user is the owner of the identity (email address) they want to use. Also, the researchers demonstrated the issue using “Login with Facebook,” but it could technically work with any identity provider.

The OAuth process works like this: a user wants to create an account on a website and chooses Login with Facebook and provides an email address. The website redirects the user’s browser to Facebook to bring proof that the user indeed has an account under that email address with the identity provider.

When this happens for the first time, Facebook will show a permission prompt to the user asking them to confirm that the third-party website or app is allowed to access information about their account, like the email address. It will then generate a secret token and will redirect the user’s browser back to the requesting website with the token attached in the request URL.

Oauth develops permissions and remembers them

The website will take the token and will use it to access the Facebook Graph API on behalf of the user and ask Facebook what email address is associated with the token. Facebook will respond with the user’s email address and the website will have confirmation that the user is who they claim they are and will allow them to create their account.

For any subsequent login the process will repeat, but Facebook will no longer prompt the user to provide access since it has already been granted. The user will just click “Login with Facebook”, the site will redirect their browser to Facebook to obtain a token, Facebook will redirect the user’s browser back to the site with the token attached in the URL and the site will use the token to confirm the user’s email via the Facebook API and let them in.

However, there is one aspect that’s very important for the security of this process: Facebook, and any OAuth identity provider, ties the token to the app ID of the website that requested the token via the user’s browser. Every website or app that wants to provide the Login with Facebook feature has to first register with Facebook and will receive its own unique app ID in Facebook’s database.

The problem is that it’s the website’s responsibility to verify the token before accepting it and using it and this validation involves checking that the token was generated for its own app ID and not some other app. This is done by making a request to a special Facebook API endpoint before using the token to ask Facebook to validate the user’s identity and allowing the user to access their account.

If this step is skipped — and it turns out many websites skip it — user impersonation and account takeover is possible. For example, an attacker can create a legitimate website or app that provides a service, register it with Facebook to provide the “Login with Facebook” feature and then surreptitiously use it to generate and collect OAuth tokens from users who legitimately want to use the service.

The tokens Facebook will generate for users to validate their identities on the attacker’s website will be valid, even though they will be issued for the website’s app ID. However, if another website doesn’t check the app ID of the tokens they receive and just use them, the attacker could take a token a user generated for their website and use it on a vulnerable website to access the user’s account on that website.

If that site is an e-commerce platform like Bukalapak, the user might have billing and payment information stored in their profile. If it’s a service like Grammarly, the user might have sensitive documents and so on.

Other variations and implementation oversights

OAuth is a complex standard and allows for various implementation variants. For example, instead of using redirect URLs between the site and the identity provider, the site might choose to use the PostMessage feature, but the attack is still possible in such an implementation if the token is not validated.

Passing tokens via URLs is potentially vulnerable to man-in-the-middle attacks if an attacker has the ability to passively monitor traffic and just extract the OAuth token from the URL they observe. Because of this, OAuth also provides a more secure approach where the identity provider issues a one-time code instead of an access token, then the website takes that code together with an application secret only itself and Facebook knows and exchanges the code into a token using the Facebook API.

Grammarly actually used this more secure code-based approach when the Salt Security team tested its OAuth implementation. However, the researchers saw the Grammarly OAuth script took requests with the entry code in the request and wondered if it may include a function that takes tokens as well. Therefore, they tried making requests by replacing code with different words like token, facebookToken, FBtoken and different variations, until they found that access_token worked and was accepted.

In other words, they managed to downgrade Grammarly’s implementation to the more secure variant because the code to handle tokens directly instead of code was still left in the script as an option. And it turned out, there was no token validation step to check for the app ID.

The Salt Security researchers found other OAuth implementation flaws in major websites in the past, including some that could have given attackers access to Booking.com accounts. “It’s extremely important to make sure your OAuth implementation is secure,” the researchers said. “The fix is just one line of code away…. When OAuth is used to provide service authentication, any security breach in it can lead to identity theft, financial fraud, and access to various personal information including credit card numbers, private messages, health records, and more, depending on the specific service being attacked.”