Additional OAuth Vulnerabilities

---

Now that we discussed common vulnerabilities that can occur due to improper implementation of the OAuth flow itself, let us move on to additional vulnerabilities that may arise in conjunction with improper OAuth implementations.

---

Cross-Site Scripting (XSS)

One of the most common web vulnerabilities is cross-site scripting (XSS), in particular, reflected XSS. As the name suggests, reflected XSS can occur whenever a value from the request is reflected in the response. This is common in OAuth flows.

If we take a look at the authorization request in our lab, we can see that there are three parameters from our request that are reflected as hidden values in the response:

If the web application does not properly sanitize these values, they may lead to reflected XSS. We can test these values by injecting a simple alert proof of concept payload:

To confirm that the parameter is vulnerable, we can access the request in a web browser:

Since the vulnerability is present in the authorization request, this XSS vulnerability impacts the authorization server and can potentially lead to a full account takeover of a victim's account.

---

Open Redirect & Chaining Vulnerabilities

As we discussed a couple sections ago, the redirect_uri parameter may be exploited to steal the victim's authorization code. However, this type of vulnerability can easily be prevented by implementing proper whitelist checks on the redirect URL. Typically, this is done by checking the URL's origin consisting of the protocol, host, and port of the URL against a whitelisted value. This way, the client is still able to move the callback endpoint without breaking the entire OAuth flow while preventing an attacker from manipulating the redirect URL to a system under their control. The redirect URL's origin must match the predefined whitelisted value provided by the client.

This may seem perfectly secure, and on its own, it is. However, this drastically changes when the client web application hosed on the whitelisted origin contains an open redirect. While some open redirects can be security vulnerabilities, other open redirects exist by design, for instance, redirect endpoints in social media. However, an open redirect can be exploited by an attacker to steal a victim's OAuth token.

To explore this in more detail, let us assume, the OAuth client academy.htb hosts its callback endpoint at http://academy.htb/callback and implements an open redirect at http://academy.htb/redirect that redirects to any URL provided in the GET parameter url. Furthermore, the authorization server hubgit.htb validates the redirect_uri provided in an authorization request by checking it against the whitelisted origin http://academy.htb/.

Now, an attacker can exploit this scenario to steal a victim's authorization code by sending a manipulated authorization request to the victim with the following redirect URL:

http://academy.htb/redirect?u=http://attacker.htb/callback

This URL passes the authorization server's validation. However, after successful authentication by the user, the authorization code is first sent to http://academy.htb/redirect, resulting in a redirect to http://attacker.htb/callback. Thus, the attacker obtains the authorization code despite the correctly implemented validation of the redirect_uri parameter. The rest of the exploit works just as described in the section Stealing Access Tokens.

This scenario resulted in a real world bug bounty report disclosed here.

---

Abusing a Malicious Client

So far, we have assumed the attacker to be a separate actor not present in the OAuth flow. However, typically, authorization servers support OAuth client registration, enabling an attacker to create their own malicious OAuth client under their control. The attacker can then use this client to obtain access tokens from unknowing victims, which may be used in improperly implemented OAuth clients for victim impersonation.

For instance, an attacker could create the web application evil.htb and register it as an OAuth client with hubgit.htb to enable OAuth authentication. If an unknowing victim logs in to evil.htb with their hubgit.htb account using OAuth, the attacker controlled client receives the user's access token to hubgit.htb. The attacker could now try to use this access token to access academy.htb. If the client academy.htb does not verify that the access token was issued for a different client and grants access, the attacker is able to impersonate the victim on academy.htb.

A scenario similar to this was discovered in the real world as described here.