What is OAuth?

OAuth is an authorization framework that lets an application access user’s data on another third-party application. This feature is implemented in such a way that users allow applications to fetch their account-specific details (email, name etc.) from third-party applications (Facebook, Gmail etc.) without revealing login credentials.Let’s get familiar with the Basics, first :-

1. Client application - Application that wants to access the user's data.
2. Resource owner - The user whose data the client application wants to access.
3. OAuth service provider - Third-party applications like Facebook, Gmail etc.

In a nutshell, OAuth working :

1. The client application sends a request to the authorization endpoint along with client_id, redirect_uri, response_type, scope and state as parameters.
2. Users are redirected to the login page and after login, they are presented with scope/data that the client application wants to access. They have to consent to proceed further.
3. After the user consents, they are redirected to the URL specified in the redirect_uri parameter in step 1. The HTTP response for this request contains the authorization code.
4. As soon as the application receives the authorization code, it shares it with the OAuth service provider to receive the access token in exchange.
5. The OAuth provider will validate the shared authorization code and then grant the client application access token with the scope specified in step 1.
6. Now with the access token in hand, the client application sends a request to the OAuth provider to fetch the user’s data.
7. The OAuth provider validates the access token and responds with the user’s data based on the specified scope.

From steps 4-7, everything is server to server communication, and not visible to the users.

Common vulnerabilities found in OAuth

1.Improper redirect_uri validationAs mentioned in step 3, redirect_uri is responsible for redirecting users to a host with authorization code as a parameter. If an attacker is able to redirect users to a domain he controls, he will have access to the authorization code which can be further used to take over an account.An attacker could try to bypass redirect_uri validation by following ways:

• Sending duplicate redirect_uri parameters, the application would consider one of these two parameters as valid and ignore the other one.
• While developing an application in a local environment, developers using whitelist “localhost” and forget to remove this from the production server. An attacker can leverage this by registering a domain and localhost.evil.com and bypass redirect_uri validation.
• Sometimes, changing one parameter can affect validation of others, for example tampering scope parameter may alter parsing of redirect_uri
• An attacker could try adding arbitrary paths, parameters or fragments to the original redirect_uri parameter. OAuth service may consider this valid and could redirect users to the attacker's domain.
• Even if there’s proper validation of redirect_uri parameter, an attacker could bypass it if the application happens to have an open redirection vulnerability, redirect_uri parameter is part of the authorization request (step 1) and an attacker could replace the original value of this parameter with something like this.redirect_uri=https://ALLOWED-DOMAIN/random-endpoint?redirect=ATTACKER-DOMAIN.com

Here, the redirect parameter in the end is vulnerable to open redirect.

2.Missing state parameter

Think of a state parameter as a parameter used to prevent CSRF attack. Missing state parameters could result in a potential CSRF attack. It's pretty straightforward and similar to how an attacker would exploit CSRF.Attack Scenario:

1. Attacker creates an account on an application and initiates OAuth flow by connecting his social media account.
2. He allows the OAuth provider to share data with the client application.
3. The OAuth provider responds with a redirect that contains a code.
4. Instead of using this code to link his social media account, the attacker preserves it and sends the link with code to the victim or embed it with an iframe on a website and send it to the victim. (Look at the 3rd step in the flow, a request is sent to callback endpoint with a code)
5. When the victim visits that site, the attacker’s social media account is linked with the victim’s account on the client application.
6. An attacker could simply login to the victim’s account using his linked social media account and then change the email or do whatever he wants.

As we can see, the authenticity_token parameter is highly unpredictable. This parameter, if verified properly on the server side, would ensure that no other malicious user would be able to forge the particular request in another unsuspecting user’s session.

Conclusion

Most apps these days rely on OAuth as an alternate login mechanism. Developers and security professionals must have a decent understanding of flaws in OAuth and mitigations to prevent them.In addition to this, developers must go through the OAuth provider's docs and understand the optional components. Sometimes vulnerabilities arise because of these missing components. For example, the state parameter is an optional component that isn't necessary to implement OAuth and because of this developers miss it, but not having it opens room for CSRF attacks.