OAuth is an open-standard authorization mechanism or framework that allows programs to have “secure designated access.” For example, you can inform Facebook that ESPN.com is permitted to view your profile or make updates to your timeline without providing ESPN with your Facebook login. This significantly reduces risk: even if ESPN has a breach, your Facebook login remains secure.
OAuth does not exchange password information, instead of relying on permission tokens to establish a connection between users and service providers. OAuth is an authentication mechanism that enables you to authorize one application to engage with another on your behalf without disclosing your password.
Vulnerabilities can occur in the implementation of OAuth in the client application as well as in the setup of the OAuth service itself. We’ll teach you how to attack some of the most frequent vulnerabilities in both of these settings in this section.
Vulnerabilities in the client application
- Improper implementation of the implicit grant type
- Flawed CSRF protection LABS
Vulnerabilities in the OAuth service
- Leaking authorization codes and access tokens
- Flawed scope validation
- Unverified user registration
Improper implementation of the implicit grant type
Because of the risks associated with transmitting access tokens through the browser, the implicit grant type is mostly suggested for single-page apps. However, due to its simplicity, it is also frequently used in traditional client-server web applications.
The access token is transmitted from the OAuth service to the client application as a URL fragment via the user’s browser in this flow. The token is then accessed by the client application through JavaScript. The problem is that if the program wishes to keep the session open after the user quits the page, it must save the current user data (often a user ID and an access token) someplace.
To address this issue, the client application will frequently send this data to the server in the form of a POST request, after which it will assign the user a session cookie, thus logging them in. This request is basically analogous to a form submission request issued as part of a traditional, password-based login. However, in this circumstance, the server lacks any secrets or passwords with which to compare the given data, implying that it is implicitly trusted.
This POST request is available to attackers via their browser in the implicit flow. As a result, if the client application does not adequately validate that the access token matches the other data in the request, this behavior might lead to a major vulnerability. In this situation, an attacker may impersonate any user by simply changing the parameters given to the server.
Flawed CSRF protection
Although many components of the OAuth flows are optional, some are strongly advised to be used unless there is a compelling reason not to. The state parameter is one such example.
When the OAuth flow is first initiated, the state parameter should ideally contain an unguessable value, such as the hash of anything related to the user’s session. This number is then transferred back and forth as a CSRF token for the client application between the client application and the OAuth service. As a result, if you observe that the authorization request does not include a state parameter, this is quite intriguing from the standpoint of an attacker. It might imply that, similar to a classic CSRF attack, they can commence an OAuth flow before deceiving a user’s browser into finishing it. This might have serious effects depending on how the client application uses OAuth.
Consider a website that allows users to log in using a traditional, password-based approach or by connecting their account to a social network profile via OAuth. If the application fails to utilize the state parameter in this situation, an attacker may be able to hijack a target user’s account on the client application by linking it to their own social network account.
It should be noted that if the site only permits users to log in using OAuth, the state parameter may be less important. However, not utilizing a state parameter allows attackers to build login CSRF attacks in which the user is deceived into signing in to the attacker’s account.
Leaking authorization codes and access tokens
The most well-known OAuth-based vulnerability occurs when the OAuth service’s setup allows attackers to steal authorization codes or access tokens linked with other users’ accounts. The attacker may be able to access the victim’s data by stealing a legitimate code or token. Finally, the attacker might possibly log in as the victim user on any client application that is registered with this OAuth service, entirely jeopardizing their account.
Depending on the grant type, either a code or a token is delivered to the /callback endpoint given in the redirect URI part of the authorization request via the victim’s browser. If the OAuth service fails to correctly validate this URI, an attacker may be able to design a CSRF-like attack, deceiving the victim’s browser into launching an OAuth flow that sends the code or token to an attacker-controlled redirect URI.
An attacker might possibly take the victim’s code before it is utilized in the authorization code flow. They can then use this code to get access to the user’s account by sending it to the client application’s legal /callback endpoint (the original redirect URI). An attacker does not even need to know the client secret or the generated access token in this case. As long as the victim has a valid OAuth session, the client application will simply finish the code/token exchange on the attacker’s behalf before signing them into the victim’s account.
It is important to note that utilizing state or nonce protection does not always prevent these attacks since an attacker can generate fresh values using their own browser.
When exchanging the code, more secure authorization servers will also need a redirect URI argument to be delivered. If this does not match the one obtained in the first authorization request, the server might refuse the transaction. Because this occurs via server-to-server queries across a secure back-channel, the attacker has no influence over the second redirect URI argument.
Flawed redirect_uri validation
Because of the kind of attacks discovered in the previous lab, it is recommended that client apps give a whitelist of their real callback URIs when registering with the OAuth service. When the OAuth service receives a new request, it can use this whitelist to check the redirect URI argument. In this situation, providing an external URI will almost certainly result in an error. However, there may be ways to avoid this validation.
When auditing an OAuth flow, you should play around with the redirect URI argument to see how it is checked. As an example:
- Some implementations allow for a variety of subdirectories by just ensuring that the string begins with the acceptable sequence of characters, i.e. an allowed domain. To explore what you can alter without causing an error, try deleting or adding arbitrary paths, query arguments, and fragments.
- If you can attach extra values to the default redirect uri option, you may be able to exploit differences in URI processing by the various components of the OAuth service. You can, for example, attempt the following techniques:
https://default-host.com &@foo.evil-user.net#@bar.evil-user.net/
If you’re unfamiliar with these tactics, we recommend reading our article on how to get around typical SSRF defenses and CORS.
- You may come across server-side parameter pollution flaws on occasion. You should try sending duplicate redirect uri arguments just in case:
https://oauth-authorization-server.com/?client_id=123&redirect_uri=client-app.com/callback&redirect_uri=evil-user.net
- Localhost URIs are also given special consideration by some servers since they are often utilized during development. In rare circumstances, any redirect URI beginning with localhost may be allowed in the production environment by mistake. By registering a domain name such as localhost.evil-user.net, you may be able to avoid validation.
It is vital to remember that you should not limit your testing to only querying the redirect uri option. In the wild, you will frequently need to experiment with various combinations of adjustments to numerous parameters. Changing one parameter might sometimes have an impact on the validity of others. Changing the response mode from query to fragment, for example, might sometimes totally change the processing of the redirect URI, enabling you to submit URIs that would otherwise be disallowed. Similarly, if the web message response mode is allowed, it frequently allows for a broader range of subdomains in the redirect URI.
Flawed scope validation
The user must allow the requested access in any OAuth flow depending on the scope indicated in the permission request. The resultant token grants the client application access to only the scope that the user has approved. However, owing to flaws in the OAuth service’s validation, an attacker may be able to “upgrade” an access token (either stolen or obtained through a malicious client application) with additional capabilities in some instances. The procedure for doing so varies depending on the type of award.
Unverified user registration
When using OAuth to authenticate users, the client application implicitly assumes that the information saved by the OAuth provider is accurate. This is a risky assumption to make.
Certain websites that provide an OAuth service enable users to create an account without validating all of their information, including, in some situations, their email address. An attacker can take advantage of this by creating an account with the OAuth provider using the same information as the target user, such as a known email address. Client apps may then enable the attacker to sign in as the victim using this bogus OAuth provider account.
ZOFixer.com security scan helps to find this vulnerability in your software and server, you can easily use it by registering on our website and activating the 30-day trial.