At least once till date, you must’ve come across  sites that let you log in using your social media account [Facebook, LinkedIn, Google & various such platforms] The chances are that this feature is built using the well known OAuth 2.0 framework. This framework is liked by Pentesters because it is;

• Extremely common.
• Vulnerable due to implementation errors.

Allowing attackers to obtain sensitive user data; and in some cases, lead to a complete bypass of the authentication.

What is OAuth 2.0?

OAuth is an open-standard authorization protocol / framework that describes how unrelated servers and services can allow authenticated access to their assets without actually sharing the initial, related, single logon credential. In authentication parlance, this is known as third-party, user-agent, delegated authorization.

In simpler terms, it allows the user to grant access without exposing their login credentials to the requesting application, this also allows users to fine-tune which data they want to share rather than having to hand over full control of their account to a third party.

How does OAuth 2.0 Work?

It works by defining a series of interactions between three distinct parties, namely a client application, a resource owner, and the OAuth service provider.

• Client application – The application that wants to access the user’s data.
• Resource owner – The user whose data the client application wants to access.
• OAuth service provider – The website or application that controls the user’s data and access to it.

1. The client application connects to the OAuth service provider on behalf of the resource owner, using OAuth, providing the resource owner’s verified identity.
2. The OAuth service provider generates a one-time token and a one-time secret unique to the transaction and parties involved.
3. The client application gives this token and secret to the initiating resource owner’s client software.
4. The client’s software presents the request token and secret to their authorization provider.
5. The resource owner approves (or their software silently approves) a particular transaction type at the client application.
6. The resource owner is given an approved access token (notice it’s no longer a request token).
7. The resource owner gives the approved access token to the client application.
8. The client application gives the access token to the OAuth service provider as proof of authentication on behalf of the resource owner.
9. The OAuth service provider lets the client application access their site on behalf of the resource owner.
10. The resource owner sees a successfully completed transaction occurring.

*Note: If not already authenticated to the authorization provider, the client may be asked to authenticate. After authentication, the client is asked to approve the authorization transaction to the OAuth service provider.

A Diagrammatic representation of the above written flow

Why OAuth is vulnerable?

OAuth authentication vulnerabilities arise partly because

• The OAuth specification is relatively vague and flexible by design, there’s plenty of opportunity for bad practice to creep in.
• The general lack of built-in security features.
• security relies almost entirely on developers using the right combination of configuration options and implementing their own additional security measures on top.
• Highly sensitive data is also sent via the browser, which may entice an attacker to intercept it.

General Vulnerabilities in OAuth?

From what we gather above, it’s safe to say the OAuth vulnerabilities can be classified into two simple categories:

Vulnerabilities in the client application

• Poor implementation of the implicit grant type and / or permissions.
• Flaw in the setup of CSRF protection.

Vulnerabilities in the OAuth service

• Leak of authorization codes and / or access tokens .
• Issues in scope validation.
• Successful user registration for unregistered users.

How to prevent OAuth vulnerabilities?

We will break down these prevention pointers into the same categories as the vulnerabilities:

Vulnerabilities in the Client Application

• Using the state parameter even though it is not mandatory.
• Sending a redirect_uri parameter not only to the /authorization endpoint, but also to the /token endpoint
• Be careful with leak of authorization codes via the Referer header when external content [images, scripts, CSS, etc] is provided.
• In case if OpenID Connect is being used via the id_token variable, it is important to properly validate it with respect to JSON web signatures, encryption & OpenID guidlines.

Vulnerabilities in the OAuth Service Provider

• Client applications to register a whitelist of valid redirect_uris.
• Enforce use of the state parameter.
• Verify that the access token was issued to the same client_id that is making the request.

What to Watch for next?

In part two, we’ll be discussing the exploits in detail, and in part three practical demonstration.

Thanks for reading!

References

https://portswigger.net/web-security/oauth

https://www.csoonline.com/article/3216404/what-is-oauth-how-the-open-authorization-framework-works.html