Continuing our previous post, where we discussed the basics of how OAuth 2.0 authentication worked, some known issues which arise due to either lack of understanding of the framework itself, or poor configuration of the same. In this blog, we’ll talk a little bit in detail of the vulnerabilities we had previously discussed.

Vulnerabilities in the OAuth client application

Client applications will almost always use a reputable, tried & tested OAuth service [Google in most cases], that is protected against a varied range of attacks. However, the client application on their own side, may misconfigure the implementation leaving it to be less secure.

As we’ve already mentioned, There are a lot of moving parts in an OAuth flow, with many optional parameters and configuration settings, i.e. there’s plenty of scope for misconfigurations.

1] Insecure Implementation of Implicit grant type

Vulnerability: User Impersonation

Given the known dangers introduced by sending access tokens via the browser, the implicit grant type is usually, only recommended for single-page applications. However, due to its relative simplicity it is often implemented in classic client-server web applications.

Consider this Scenario

1. Access Token is sent from the OAuth Service to Client Application in the URL via the browser.
2. The Client Application accesses the Token for further application flow.
3. The Client Application submits current user data as a POST request, assigning the user a session cookie.
4. The user continues to use the application normally.

In the above flow we can see implementation issues which can lead to a cause of concern:

• Problem 1: If the application wants to maintain a session or lead towards an authorization flow elsewhere all the submitted data in [2] & [3] needs to be stored, naturally this would be on the server.
• Problem 2: Since the flow has no data on the server that it can be validated against; This flow is to be implicitly trusted. This would not be the case in a classic authentication flow, like a password challenge where the server has a variable [namely, a password hash] to validate the submitted input against.

In this flow, acceptance of user data is through implicit trust, the POST request can be potentially be exposed via the browser. If the client application doesn’t validate that the access token matches the other parts of the data in the incoming request, simply changing the parameters sent to the server will allow impersonation of a user.

2] Flawed CSRF Protection

Vulnerability: User Account Takeover / Account Hijacking

Although many components of the OAuth flows are optional, some of them are strongly recommended unless there’s an important reason not to use them. One such example is the state parameter.

Consider this Scenario:

1. The Client Application allows traditional password-based login as well as Social-Media based OAuth login.
2. This mechanism lacks the use of a state parameter.

In the above flow we can see the lack of state can lead to a cause of concern; here’s how:

The state parameter should ideally contain an unguessable value [hash of something that can be tied to a user and their session(s)], when the initially logged in [beginning of the OAuth Flow]. This value is then reused client application and the OAuth service as part of a CSRF token for the client application.

Therefore, if the authorization flow does not use a state parameter, it means that anyone can attempt to initiate an OAuth flow themselves and trick a user’s browser into completing it, similar to a sense of a traditional CSRF attack. This could allow a hijack of a users account on the client application by binding it to their own account.

Two very interesting things to note here is that:

• The criticality of not using the state parameter reduces considerably if the application allows exclusive logins via OAuth only. Still, it is important to note that it can still allow malicious users to construct login-based CSRF attacks.
• The severity & the consequences of the lack of state parameter completely depends on how OAuth is being used in the application.

A non-technical explanation would be, this issue would be a impactful on a e-commerce website, rather than a website with static content and minimal additions to functions even after login, a blog for example.

Vulnerabilities in the OAuth Service

As previously discussed, the a lot of the implementations of OAuth are optional in nature, which is why knowing the controls & configurations is a must. If the OAuth Service provider doesn’t understand such controls fully, it could lead to vulnerabilities.

1] Leak of authorization codes and access tokens

Vulnerability: Broken Access

The most notorious OAuth vulnerability would be; when he OAuth service itself is misconfigured, enabling attackers to steal authorization codes / access tokens associated with other users’ accounts.

By stealing a valid code or token, the attacker may be able to access the victim’s data, completely compromising their account, potentially allowing free access as the victim on other client application(s) registered with this OAuth service.

A “callback” endpoint is called upon by the user’s browser, this endpoint is specified in the “redirect_uri” parameter. If the OAuth service fails to check this URL for modifications, an attacker may be able to construct a CSRF-like attack.

Hence, during the authorization code flow, an attacker can steal the victim’s authentication token before it was even used. This code can them be used to the client application’s legitimate callback endpoint i.e. original redirect_uri to get access to the user’s account.

In this scenario, even the lack of access token, won’t stop the attacker, as long as the victim has a valid session with the OAuth Service Provider. [The client application will validate the token exchange on the attacker’s behalf]

A] Auditing Flawed redirections

Some ways of understanding the OAuth flow and how the redirect url is handled are:

• If a flow allows multiple directories / subdirectories. Try appending or removing arbitrary paths. [See how much you can get away with without throwing the application into an error].
• Check if the URL validates appended values [https://example.com &@somethingmalicious.com ]
• Try sending duplicate redirect_uri via the URL too see if the application accepts it.
• In some cases, the implementation may give special preferences to “localhost” [a keyword] URLs’. Having an evil domain like localhost.somethingmalicious.com may work out in your favor in bypassing some checks

B] Some Checks If redirecting to a malicious domain fails.

• [ If vulnerable ] an attacker may attempt to chain directory traversal of the “callback” endpoint to:
  • Open Redirect: Used as a proxy forward to send tokens to a malicious domain.
  • HTML injection: Using crafted Referrer headers, or img element with a malicious domain

2] Upgraded Permissions Grant due to Insecure Scope Validation

Vulnerability: Escalation of privileges

Upgrading Permissions via the authorization flow

Consider the following Scenario:

A malicious client application requests access to the user’s email address scope [Allow application to read your email address]. Since the malicious user controls the client applications they can append additional scope permissions [example: profile, friend-list (incase of a social media application)]

If the server does not validate this against the scope of the initially authorized request, it will allow the generation of fresh access token using in the context of the modified scope and send this to the attacker’s client application

Upgrading Permissions via abuse of the implicit flow

Due to the implicit trust mechanism of the OAuth flow, a stolen access token can be used with a normal browser-based request to the OAuth service, manually appending newer scope to the request.

In a perfect world, every request must be validated against the scope which was used when the token was first generated. [The lack of this, may even allow the attacker to access additional data without further requiring user approval].

What to Watch for next?

In part three, we’ll be covering a practical demonstration.

Thanks for reading!

Haven’t checked out part one yet? Do it here!

References

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