OAuth 2.0 – Vulnerabilities and Preventions

Federation and Single Sign-On are used across almost every organization. It enables the employees to access different resources across the network, by signing-in only once by managing and mapping identities between Identity Providers (IdP) and the resources. There are many standards which are being used for implementing these standards such as OAuth, SAML and WS-Fed. 

OAuth 2.0 though serves the same purpose as OAuth but the mechanism is different and has also become the most commonly used OAuth protocol. 

There are two types of grant flow that are possible in OAuth 2.0 which are:

• Authorization grant flow: In this type, the communication between the parties i.e, user agent, resource or client application and OAuth service or IdP, takes place through a back channel or server-to-server communication, making it secure and less prone to attacks which arise from vulnerabilities in the user agent’s browser.

• Implicit grant flow: This is an easier implementation of the protocol which uses the user agent’s browser throughout the communication. Though easier to implement, it is prone to a number of attacks involving a compromised user’s network. This is used when  the application is hosted on a local server or when there is not much scope of storing sensitive token data such as client_secret(Identification of the client).

OAuth 2.0 like any other federation protocol is also just a framework to provide communication between the parties involved. Making it a secure one, is in the hands of the developers who have to implement it properly using all the necessary parameters and the appropriate combinations of the same.

The above diagrams represent the flow of requests and responses which contain particular parameters , some optional and some compulsory, according to the  framework. Some of the important parameters are:

• In the Authorization request (Step 2):
  • “client_id” for identification of client application
  • “redirect_uri” for destination for authorization code
  • “response_type” determining what is requested by the client application:
    • In the Authorization grant type, an authorization code is requested as the response type.
    • In the implicit type, a token is requested as a response.
  • “scope” is used to specify the subset of user data that the client application wants to access.
  • “state” stores the value associated with the Session between the user agent and the client application.
• In the Access token request (Step 5 in figure 1):
  • “client_id ” and “code” serve the same purpose discussed above.
  • “client_secret ” is the secret key provided by the client application to authenticate itself to the OAuth service.
  • “grant_type” is the same as the “response_type” but is sent again as the endpoint in the OAuth is now at /token.

The steps to analyse the communication using OAuth 2.0 to determine the vulnerabilities are as follows:

• Determining the grant type:
  • Analyse the GET and POST requests as well as the destination of the request (/authorization, /access or /userinfo). For example, the value of response_type will be different in both the cases. Authorization grant type will be the client application requesting for a response of authorization code while implicit type will have an access token response type.
• Vulnerability Assessment of Client Application or Service Provider(SP): There can be a number of misconfigurations on the client application side leading to session hijacking and data breach. Some of them are:

1. If the access token assigned by the OAuth service to the client application. The client application assigns a session to the user and sends it to the resource server to maintain the session through a POST request. This session can be manipulated/changed by using some other user details. 

Prevention: The resource server checks and compares the data being exchanged throughout the communication.

2. In an authorization grant type workflow, there is a parameter “state” which is used to maintain sessions between the involved parties. If there is any step using a URL between the communication process which does not contain this state, it may result in an CSRF attack.
   For example: There is a provision of linking of Social login to an already existing account. If in such an optional functionality, ‘state’ parameter is not being used, this request can be planted in the victim’s browser who has normal login rights. When the victim tries to login, this URL(having the linking request to the attacker’s social login account) will be activated and now the attacker’s social login will be linked to the victim’s account.

Prevention can be done by using the “state” parameter should be used with every authorization request.

• Vulnerability Assessment of OAuth Server or Identity Provider(IdP): There can be a number of misconfigurations on the OAuth Server leading to session hijacking and data breach. Some of them are:

1. Leaking authorization codes to external sources and not checking for consistent redirect_uri used.
   • While the client application sends an authorization request to the OAuth Server (checks the validity using client_id), this request can be intercepted to get the authorization code as a response by the attacker. Once an authorization code is given, one can use it to hijack the session previously formed between the victim and the authorization server.This happens when the OAuth provider doesn’t check the redirect_uri mentioned during the Authorization request and the one used during Access Token request. The access token request can’t be manipulated as it does not happen through the user’s browser (server-to-server communication).

Prevention: The redirect_uri should either be whitelisted or checked at every stage to avoid a fake client application server.

2. Flawed redirect_uri validation:
   • If the request_uri is vulnerable to directory traversal, it will get past the OAuth Server verification. The directory traversal may lead to redirects to resources that are present in the client application server (redirect_uri). If there is some vulnerability(like XSS, HTML injection or open redirect) there which can lead to the stored access tokens or authorization codes, the above discussed attacks can be performed.

Prevention: The redirect_uri should either be whitelisted and should not be prone to directory traversal or

any other vulnerability to prevent this attack

3. Scope parameter in the initial authorization request, defines what information the client application needs to log-in the user. The value of this scope parameter has to be validated carefully, otherwise may lead to information disclosure. This can be done in both the grant type:
   • Authorization grant type: If the client applications are not validated properly by the OAuth service, then a fake client application can be registered and used for gaining information about the user beyond what has been authorized by the user by manipulating the scope parameter.
   • Implicit grant type: As the communication is done through the user’s browser, the scope parameter can be easily manipulated at any stage , given that the user browser is compromised.

Prevention from this attack is done by verifying the scope of the authorization and monitoring it constantly.

4. There is another misconfiguration possible. The normal login (login with email option) and the social login accounts should be matched and recorded simultaneously so that two users don’t end up accessing the same account. This attack is possible only when Email verification is not done while signing-up.

Email verification should be done, so that accounts can’t be created with somebody else’s email address. Existing accounts should be verified and maintained simultaneously for both the “login with email” and “social account login”.

There are many such functionalities and parameters that need to be handled carefully both on the client application side and the OAuth service side in order to avoid the attacks even if the user agent’s device or browser is compromised.

How we can help?

Any of the frameworks would just provide a medium to communicate between the parties, but to make it a secure one, is the organization’s responsibility. With a trusted partner like SecurDI that has years of experience in this space, we can help you strategize and design the appropriate OAuth flows and the necessary implementation details, for your organizational needs using leading enterprise tools. Our seasoned professionals can help you choose the right technologies and vendors from the many standards and vendors out there, all providing the functionality of federation and SSO, for your targeted needs to ensure you are successful in your digital journey.

– Authored by Gayatri Priyadarshini

Background vector created by rawpixel.com – www.freepik.com