OAuth 2.0 Hacking Simplified — Part 2 — Vulnerabilities and Mitigation

Published in

InfoSec Write-ups

8 min readMay 27, 2021

Hello everyone,

I am back with another part of the OAuth 2.0 Hacking Simplified series. We have already gone through basics in the previous post. I highly recommend you to go through the Part 1. In this blog we will dive into how we can exploit and mitigate common OAuth vulnerabilities.

OAuth2 Vulnerabilities

OAuth vulnerabilities arise because the OAuth specification is relatively vague and flexible by design. The vast majority of the implementation is completely optional in OAuth. Also OAuth doesn’t have much built-in security features. Most of the security configuration and additional security implementation has to be done by developers.

Note: All the demos are from Portswigger Academy.

Vulnerabilities can arise in the client application’s implementation of OAuth as well as in the configuration of the OAuth service itself. Some of the most common vulnerabilities in both of these contexts are -

Vulnerabilities:

Improper implementation of the implicit grant type
Flawed CSRF protection
Leaking authorization codes and access tokens
Flawed scope validation
Unverified user registration
Host header injection
Reusable OAuth access token

Let’s talk about each one in detail-

Improper implementation of the implicit grant type

Once the OAuth provider sent the access_token to the client application, application has to maintain a session. To achieve this, client application will often submit this data to the server in a POST request and then assign the user a session cookie, effectively logging them in similar to traditional password-based login. However, the server doesn’t have any secrets or password to compare with the data submitted by client application, which means it is implicitly trusted.

In this situation, attacker can simply change the parameters sent to the server to impersonate any user as access token is valid. See below snapshots for understanding-

Normal valid POST request with token,

Attacker changes the mail to access the account of victim,

2. Flawed CSRF protection

If you have checked above definitions, you already know that state parameter serves as a form of CSRF Token for the client application. If the authorization request does not send a state parameter, this is extremely interesting from an attacker's perspective. It means that they can initiate an OAuth flow themselves before tricking a user’s browser into completing it.

Let’s take an example. As a user we can be able to login to a site using social media OAuth.

Now let’s login normally,

Observe that we are logged in as normal user. Let’s check the OAuth request by clicking “Attach a social profile”-

The state parameter is missing in the request, which means we can use the code assigned to us to attach our social media handle to victim’s account. Let’s get the code first by forwarding the request-

Copy the url and craft an iframe to deliver payload to the victim, make sure you drop the request after copying the valid code.

<iframe src=https://ac601f3d1fc2aa2580713e6f004f008c.web-security-academy.net/oauth-linking?code=mXgz2pFQWieUXb8ybK14P97gXZVk6_TVAT2Bitb9MaU></iframe>

Assume you send this script to admin privilege account and they executed the script, as an attacker you can be able to login to their account which will give access to all admin functionality. We can achieve ACCOUNT TAKEOVER!!

Let’s verify this by login using the social media account and you can see the role now changed to Admin

3. Open Redirection at redirect_uri parameter

When redirect_uri is not checked properly by the OAuth provider, it possible for an attacker to steal authorization codes associated with other users’ accounts. The code or access tokens can be redirected to attacker control website and can be used for further completion of the flow.

Let’s take an example. Start the OAuth flow and change the redirect_uri value to attacker control website.

Observe the response

The code has been redirected to attacker control website (here test.com). Now attacker can be able to use the code and complete the OAuth flow and takeover victim’s account.

In general scenarios, client applications provide a whitelist of their genuine callback URIs when registering with the OAuth service to mitigate this attack. But there can still be different ways to bypass this validation.

Attacker can try @ (https://expected-host@evil-host)and #(https://evil-host#expected-host) characters in the redirect_uri parameter.
Attacker might be able to exploit discrepancies between the parsing of the URI by the different components of the OAuth service. For example, you can try techniques such as- https://default-host.com &@foo.evil-user.net#@bar.evil-user.net/
Attacker can try parameter pollution vulnerabilities by submitting duplicate redirect_uri parameters as follows- https://oauth-authorization-server.com/?client_id=123&redirect_uri=client-app.com/callback&redirect_uri=evil-user.net
Attacker can try localhost URIs as they’re often used during development. This could allow you to bypass the validation by registering a domain name such as localhost.evil-user.net

4. Flawed scope validation

Every time when user login to the authorization server, they will be presented with a list of data that the client application wants to access (Like Email, profile picture).

With the authorization code grant type, the user’s data is requested and sent via secure server-to-server communication. For attacker it is impossible to manipulate directly. However attacker can register their own client application with the OAuth service.

For the implicit grant type, the access token is sent via the browser. Attackers can steal tokens and use them directly by sending a normal browser-based request to the OAuth endpoint, manually adding a new scope parameter in the process.

5. Unverified user registration

Some websites that provide an OAuth service allow users to register an account without verifying all of their details, including their email address in some cases.

Attacker can exploit this by registering an account with the OAuth provider using the same details as a target user, such as a known email address and sign in as the victim via this fraudulent account with the OAuth provider.

6. Host header injection

If the host is not being validated at the server, there is possibility to redirect the token to malicious host via host header injection.

GET /api/twitter/login?csrf=token HTTP/1.1 
Host: attacker.com/victim.org
Referer: https://www.victim.org/
Cookie:cookie

As we changed the host header, it will redirect Oauth authorization link to the attacker’s host and leak the token that is issued.

7. Reusable OAuth access token

The token should expire from backend once user logs out from the application similar to the traditional session management functionality. If it is not the case it can be considered under bad security practices and can be exploited.

8. Client secret leak

Acquiring a client_secret may allow a malicious application to impersonate your application, and any authorization it has been granted. This might include replaying access and refresh tokens in order to access a user’s account without their permission.

The leaked client_secret can be exploited by an attacker to access user’s data that your application has been granted access to. The shared secret used in a 2-legged or 3-legged OAuth authentication flow might allow an attacker to initiate the SSO flow, and unwrap encrypted OAuth tokens.

Advanced Exploitation

Here is an awesome twitter thread and mind-map by @hackerscrolls to test OAuth 2.0 —

https://twitter.com/hackerscrolls/status/1269266750467649538

Zero-day in Sign in with Apple —

https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple/

Mitigation

One of the key issues with OAuth is the general lack of built-in security features. The security relies almost entirely on developers using the right combination of configuration options and implementing their own additional security measures on top, such as robust input validation.

It is important to note that vulnerabilities can arise both on the side of the client application and the OAuth service itself.

For OAuth service providers

redirect_uri validation : Only allow complete and exact matches rather than using pattern matching. This prevents attackers from accessing other pages on the whitelisted domains.
Enforce state parameter : Unguessable, random value can help protect users against CSRF-like attacks
access_token and client_id validation : verify that the access token was issued to the same client_id that is making the request.
scope validation : Check the scope being requested to make sure that this matches the scope for which the token was originally granted.

For OAuth client applications

state parameter : Use it even though it is not mandatory.
client_secret alternative : In case of development of mobile or native desktop OAuth client applications, use the PKCE (RFC7638) mechanism to provide additional protection against access code interception or leakage.
Be careful with authorization codes : they may be leaked via Referer headers when external images, scripts, or CSS content is loaded. It is also important to not include them in the dynamically generated JavaScript files as they may be executed from external domains via <script> tags.
Send a redirect_uri parameter not only to the /authorization endpoint, but also to the /token endpoint.

Hope you learned something new and enjoyed my blog. Stay safe, stay curious.

Thanks for reading!

~Nishith K

Connect with me:

Twitter

JavaScript is not available.

Edit description

twitter.com

LinkedIn

Nishith K. - Security Analyst - Net Square Solutions Pvt. Ltd. | LinkedIn

View Nishith K.'s profile on LinkedIn, the world's largest professional community. Nishith has 3 jobs listed on their…

in.linkedin.com