OAuth 2.0 Hacking

OAuth is an open authorization protocol, which allows accessing the resources of the resource owner by enabling the client applications on HTTP services such as Facebook, GitHub, etc. It allows sharing of resources stored on one site to another site without using their credentials. It uses username and password tokens instead. [1]

Elements which are important to understand in an OAuth 2.0 context [2]:

resource owner: The resource owner is the user/entity granting access to their protected resource, such as their Twitter account Tweets. In this example, this would be you.
resource server: The resource server is the server handling authenticated requests after the application has obtained an access token on behalf of the resource owner . In this example, this would be https://twitter.com
client application: The client application is the application requesting authorization from the resource owner. In this example, this would be https://yourtweetreader.com.
authorization server: The authorization server is the server issuing access tokens to the client application after successfully authenticating the resource owner and obtaining authorization. In the above example, this would be https://twitter.com
client_id: The client_id is the identifier for the application. This is a public, non-secret unique identifier.
client_secret: The client_secret is a secret known only to the application and the authorization server. This is used to generate access_tokens
response_type: The response_type is a value to detail which type of token is being requested, such as code
scope: The scope is the requested level of access the client application is requesting from the resource owner
redirect_uri: The redirect_uri is the URL the user is redirected to after the authorization is complete. This usually must match the redirect URL that you have previously registered with the service
state: The state parameter can persist data between the user being directed to the authorization server and back again. It’s important that this is a unique value as it serves as a CSRF protection mechanism if it contains a unique or random value per request
grant_type: The grant_type parameter explains what the grant type is, and which token is going to be returned
code: This code is the authorization code received from the authorization server which will be in the query string parameter “code” in this request. This code is used in conjunction with the client_id and client_secret by the client application to fetch an access_token
access_token: The access_token is the token that the client application uses to make API requests on behalf of a resource owner
refresh_token: The refresh_token allows an application to obtain a new access_token without prompting the user

Example of OAuth 2.0 Workflow is given below:

Now that we have got some understanding on OAuth 2.0, let talk about some of the common attacks.

redirect_uri Misconfiguration

Steps to follow:

Check if the `redirectUrl=` parameter takes arbitrary domain or subdomain of the application. If it takes arbitrary domain, then you can get the token easily without following the below steps. If not, you have to look for vulnerabilities in the allowed domain.
Look for Vulnerabilities that you can chain with the above misconfig to steal the tokens. They could be: Open redirect or XSS (not limited to these).
Then, send the malicious link to the victim to collect the token. After that, you can request and get a access token to access their resources.

2. XSS in redirect implementation

If the value of the `redirectUrl` is being reflected on the redirect page, then we may have XSS injection there.

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

3. CSRF — Improper handling of state parameter

If the state parameter is static or no being used, we can exploit the misconfig.

Steps to follow:

go through the authorization process on your own account, and pause right after authorising. You will then come across a request such as: `https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1`
You can then send this URL to a logged-in user, and it will add your account to their account.

4. Pre Account Takeover

If the program does not ask for email confirmation when a new account is created, try setting up an account without the victim’s knowledge using the attacker’s password and the victim’s email address. It’s likely that the program will perform a lookup, discover that the victim’s email address is already registered, and then link their Google account to the account the attacker made if the victim subsequently tries to register or sign in with a third party, such as Google. An attacker will have access to the victim’s account if they established it before the victim registered. This is known as a “pre account takeover.”

5. Access Token Stored in Browser

If the access token is stored in your browser, then there is a possibility that the attackers can access it when they have already found XSS on the website.

6. Shared Authorization/Refresh Token

If you can get the authorization code and use it with a different client then you can takeover other accounts.

7. Everlasting Authorization Code

To reduce the window of opportunity for theft and misuse, the authorisation code should only be active for a brief period of time.

Hay Yay!!!

you have learned how to hack OAuth 2.0 😊. Please give a clap if you found it use full and follows me to get more hacking knowledge.

Photo by Samuel Regan-Asante on Unsplash