On July 29, security researchers at Salt released details of an OAuth vulnerability that can reliably be chained with any XSS vulnerability to establish a long-lived account takeover. This is a general OAuth vulnerability, not particular to Clerk’s implementation.

At Clerk, we believe it’s our responsibility to protect our customers from vulnerabilities like this, so we worked quickly to understand the attack and devise a mitigation. Fortunately, we discovered that Clerk’s default configuration is not susceptible to this chaining, and over 99.7% of our customers were already protected. For the last 0.3%, we released an update today that mitigates the attack.

In this post, we dive into the technical details of the vulnerability, why most customers were protected by default, and how we mitigated the attack for the last few.

Understanding the Open Response Type vulnerability: a clever variation of the Open Redirect

The OAuth happy path

The OAuth flow starts by redirecting a user to the “authorization URL” of an identity provider, with redirect_uri and response_type in the query param, as well as an application identifier and the scope of authorization requested. Here’s a sample for Google:

On Google’s website, the user is asked to authorize the requested scope, which normally only includes profile information so the user can be signedin.

After authorization, the user is redirected back to the redirect_uri using the given response_type. In this case, the response type is code, which means a single-use secret code is appended to the redirect_uri as a query param:

The Open Redirect vulnerability

An “Open Redirect” is when an attacker tricks a user into visiting an authorization URL with a nefarious value passed to redirect_uri. For example, instead of passing https://myapp.com/oauth_callback, they can pass https://attackapp.com/oauth_callback. This accomplishes two things:

1. https://myapp.com/oauth_callback doesn’t receive the secret code, so its single-use nature does not provide any protection.
2. The attacker gets access to a secret code. With it, they can open a new browser on their own machine, and navigate to the valid redirect_uri with the code appended. This tricks the application into granting a session for the victim to the attacker.

Thankfully, the OAuth specification guides implmentors on how to prevent Open Redirects, and Google and other identity providers maintain a strict allowlist of acceptable redirect_uris. The allowlist ensures that the user, and the secret code, will not be sent to a URL the attacker controls.

The Open Response Type vulnerability

In OAuth, the response type dictates the format and mechanism for how the identity provider passes sensitive information back to the application. With code, a single-use token is passed by query param. With token, an access token is passed by the URL’s hash fragment.

Unlike redirect_uris, the response_type parameter is not strictly bound to a per-application allowlist. This lack of enforcement is pivotal to the attack, which is why we’re calling it the “Open Response Type” vulnerability. Here is Salt’s explanation of how the parameter was leveraged:

After changing the response type to code,token, the secret code is returned in the fragment instead of the query param. In all likelihood, the application implementing OAuth has not prepared for a secret code to be in the fragment, so it doesn’t consume it, and it remains in the URL instead.

Put another way: the open nature of response_type means an attacker has a reliable way to get a valid, unused secret code in the URL bar.

Thankfully, getting the code in the URL bar alone is not sufficient, since the attacker also must be able to read its value. This is not normally possible, but it is when an XSS vulnerability is present. Depending on the page the XSS is present on, it may be as easy as reading window.location.href. In Salt’s case, they opened a new tab to the Authorization URL via window.open, then polled the tab’s location until the OAuth flow completed.

The impact

You might be wondering: Do we really need to worry about Open Response Type if it needs to be chained with an XSS attack?

The answer is absolutely yes. When managing user sessions on the web, it’s critical to mitigate the effects of XSS as much as possible. After an XSS is patched, it should be impossible for the attacker to continue acting on behalf of any users.

This is why developers use the HttpOnly directive when managing session cookies: it ensures that session tokens cannot be extracted for the attacker to continue using after the XSS is patched. Without this feature, developers would need to revoke sessions after an XSS attack and force users to sign in again.

The challenge with the Open Response Type vulnerability is that it completely bypasses the protections afforded by HttpOnly. The attacker is able to generate new sessions, and those sessions will continue to be valid after the XSS is patched.

Mitigating the Open Response Type vulnerability

The Open Response Type vulnerability relies on two behaviors:

1. The user must land on a page with an unused code in the URL bar.
2. The application must have an open XSS vulnerability that allows them to programmatically read the URL bar.

Below, we list two techniques that can be used to suppress these behaviors.

Mitigation 1: Process the OAuth code on a separate origin

At the top of this post, we mentioned that over 99.7% of Clerk customers were protected by default. That is because Clerk forces developers to set the OAuth redirect_uri to be an endpoint on our API, which is normally hosted on a subdomain like https://clerk.yourdomain.com. When the Open Response Type attack is attempted against a Clerk customer, the user would land on URL on this subdomain, like:

Fortunately, this subdomain does not serve HTML, so it’s exceedingly unlikely to be the source of an XSS. An XSS on any other subdomain cannot read the URL of a tab on the Clerk subdomain, since it breaks the web’s cross-origin rules.

If your application also leverages a separate origin for processing the OAuth code (e.g. identity.yourdomain.com or auth.yourdomain.com), it will also be protected as long as that origin never introduces an XSS.

While this technique helps, it’s hard to guarantee that you will never introduce an XSS on the origin processing the OAuth code. For that reason, we recommend using Mitigation 2 instead.

Mitigation 2: Eliminate unexpected fragments

Some Clerk customers use a reverse proxy to host our API directly on their primary domain, so OAuth codes are not processed on a separate origin. For these users, and for a more robust solution overall, we needed to find an additional mitigation.

Our solution is to eliminate unexpected fragments from the URL bar before an XSS vulnerability has the chance to read them. To do this, we’ve added an extra redirect to any OAuth failure that eliminates the fragment.

Again, let’s consider a user that lands on this URL as a result of an Open Response Type attack:

Fragments aren’t sent to the server, so our server cannot tell that code is even present. But, this URL is expecting code in the query param, and since it’s missing, Clerk is going to return an error.

Instead of simply returning the error, we are now issuing a redirect first. We issue the redirect with status=301 and a Location header that has a trailing #, which clears any fragment that might exist: