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 anaccess token
on behalf of theresource owner
. In this example, this would be https://twitter.com - client application: The
client application
is the application requesting authorization from theresource owner
. In this example, this would be https://yourtweetreader.com. - authorization server: The
authorization server
is the server issuingaccess tokens
to theclient application
after successfully authenticating theresource 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 generateaccess_tokens
- response_type: The
response_type
is a value to detail which type of token is being requested, such ascode
- scope: The
scope
is the requested level of access theclient application
is requesting from theresource 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 theauthorization server
which will be in the query string parameter “code” in this request. This code is used in conjunction with theclient_id
andclient_secret
by the client application to fetch anaccess_token
- access_token: The
access_token
is the token that the client application uses to make API requests on behalf of aresource owner
- refresh_token: The
refresh_token
allows an application to obtain a newaccess_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.