A Silent Threat - Open Redirects via OAuth Client Applications

If an OAuth Authorization Server (AS) supports self-registration of client applications, and also supports silent authentication, it likely is possible to utilize the AS as an open redirector.

Self-Registered OAuth Client Applications

A significant factor in OAuth’s wide adaptation is the ability for developers to register their own client applications on various platforms. This is often done via a self-registration process, which is a major part of OAuth’s flexibility and widespread adoption.

Platforms like Facebook, Google, and Microsoft allow developers to register their own OAuth client applications. This process typically involves the developer providing details about their application, such as its name, website, and the intended use of the OAuth integration.

Silent Authentication

Silent Authentication in the OAuth/OIDC context is a mechanism that streamlines the user experience by reducing the need for repeated logins and explicit consent every time an OAuth flow is initiated.

Suppose a user has already authenticated and granted permissions to a client app in a previous session. The next time this user interacts with the app, Silent Authentication can be used to request an auth code from the OAuth provider without interrupting the user with another login prompt or consent dialog. This is achieved by leveraging existing authentication sessions or tokens.

Leveraging Client App Self-Registration and Silent Authentication for Open Redirects

The combination of self-registered client apps and silent authentication in OAuth AS implementations can, in some cases, be leveraged to create open redirects.

How It Works

1. Client App Registration: An attacker registers their own client app on a platform that uses offers a self service developer portal (i.e. developer.example.com) with OAuth client apps. This process typically involves submitting basic information about the app and receiving OAuth credentials (client ID and secret).
2. Crafting the Open Redirect:

• The attacker, as the developer of the client application, registers a redirect_uri with their desired destination URL. This value determines where the user is allowed to be redirected to after authentication in a typical OAuth flow.
• Once the malicious app is registered and the desired destination is added as a valid redirect URI, the attacker leverages silent authentication, setting the value of the prompt parameter on the authorization endpoint to none: prompt=none

3. Execution and Impact: In an OAuth implementation where silent authentication is supported, opening the auth endpoint for the attacker’s client app as described will result in an error, either due to a lack of a valid session, or if the victim is authenticated, because the attacker’s app has not been authorized, and thus silent authentication is not possible. However, as silent authentication has been specified, the authorization sever will redirect without interaction to the URI specified in the redirect_uri parameter, adding in an error message as a url parameter rather than a auth code.

Security Concerns and Implications

On its own, an open redirect is relatively benign, and generally is not considered a vulnerability. However, this behavior has the potential to function as a useful gadget in more complex attack chains.

• SSRF Filter Bypass: Attackers might bypass filters designed to restrict the domain of a request made from a user supplied URL, potentially leading to Server-Side Request Forgery (SSRF) vulnerabilities.
• XSS: While less common, if the authorization server employs a client-side JavaScript-based redirection mechanism instead of a standard HTTP header redirect and does not properly sanitize the user input redirect URI, there may be implementations where the attacker can achieve execution of arbitrary JavaScript within the context of the authorization server.
• Phishing and Social Engineering: While the impact is often debated, it stands true that users could be redirected to phishing sites, resulting in a potential for credential theft or other fraudulent activities. More impactful scenarios exist, such as a chain with a deeplink vulnerability, where utilizing the open redirect to open the deeplink might create a prompt from the OS that example.com is requesting to open Example App, rather than attacker.com is requesting to open Example App.

Of note, I do not mention OAuth credential theft, as due to the behavior with url parameters, in my testing, it appears unlikely that an AS would carry the code parameter to the attacker destination.

Preventative Measures

The IETF draft on OAuth security topics speaks to this, albeit somewhat vaguely:

The AS MUST take precautions to prevent these threats. The AS MUST always authenticate the user first and, with the exception of the silent authentication use case, prompt the user for credentials when needed, before redirecting the user. Based on its risk assessment, the AS needs to decide whether it can trust the redirect URI or not. It could take into account URI analytics done internally or through some external service to evaluate the credibility and trustworthiness content behind the URI, and the source of the redirect URI and other client data.

I believe that whenever feasible, a review and approval process prior to public use of a newly created or significantly updated client application is ideal and part of a defense in depth strategy.