Selcouth Cyber Security Services Private Limited

OAuth 2.0 – Part one

AppSec + InfoSec + Web Attacks acc3ssp0int todayJanuary 22, 2021 610

share close

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!

At Selcouth, We believe that achieving cyber security is a continuous journey in which we partner with our clients to address the everchanging threat landscape. To address such threats, get in touch with us! You can also view our full range of service offerings here

Written by: acc3ssp0int

Rate it
Previous post

InfoSec acc3ssp0int / October 19, 2020

PowerShell History File

Hello everyone, we are all aware about Linux systems, its .bash_history and how it provides information about file locations, passwords passed in command arguments, a variety of scripts and so on. But did you know, something similar to it now [...]

Similar posts

AppSec w1r3sh65rk / February 22, 2021

Secure Code Review – Part One

Before we travel through the Secure code review in SDLC phase. Let us first understand what is Secure Coding, why it should be the part of early phase of SDLC, importance and best practices, available tools. Security Code Review: A secure code review is a part of the code review process to identify missing best ...

Read more trending_flat

AppSec acc3ssp0int / February 15, 2021

OAuth 2.0 – Part Three

Hello everyone, in this final installation of the OAuth blog series, we’ll be covering two vulnerabilities in the OAuth implementation. If you haven’t checked out the previous parts you can check out part one here and part two here. Before we get started, a big thanks to PortSwigger and their Web Security Academy Labs! The ...

Read more trending_flat

Post comments (0)

Leave a reply