#10 Web application penetration testing tutorials - Oauth 2.0 security

Web application penetration testing tutorials = OAuth 2.0 security

OAuth 2.0 has an authorization framework for Web Applications. This allows selective Access to use resources without revealing passwords on the website Asks for the resource. 

It may look complicated at first but explain to me: Let's say you're at http://www.example.com (a third party) and want to sign up Generic details, such as first name, last name, by email, on their website Address, and so on, 

But we already have such information stored on a website, such as In the form of Facebook Through OAuth, http://www.example.com can ask to provide Facebook With user information so that the sign-up process can move forward in the original Manually enter everything in the sign-up form without the user The best part here is that http://www.example.com actually receives user information Know the user's Facebook login details. 

Approval process negotiation Choreographed carefully to take the minimum steps to accept or reject the request to give resources.

I'm sure you've seen many more examples of OAuth, like sign-ups Sign-up with Google+, or Twitter. They basically use different versions of OAuth Internally, such as 1.0 or 2.0 We will cover only version 2.0 in this chapter, which OAuth is a more popular version and it is widely used.

OAuth 2.0 has become a very real framework when it comes to user Authorization on the websites. As mentioned earlier, popular and high-profile Use OAuth 2.0 for websites, such as Facebook, Google, Slack and so on Resources for their users

In this Web Application Penetration Testing Tutorial, we will cover the following topics:

• Introduction to OAuth 2.0 models
• Receiving a grant
• Exploit OAuth for fun and profit

Introducing OAuth 2.0 Models

OAuth 2.0 basically allows a third-party website to access a limited or select set User information on a particular website There are different types of authority Flow is used in OAuth 2.0. 

The main reason that OAuth is present is in the fact that Classic authentication model, user's account credentials are usually shared together Third-party website, which results in many problems; These are documented Well in OAuth 2.0 RFC 6749

• The third-party can save credibility in plain text
• Third parties receive a large amount of data of users, usually complete account access
• There is no proper way to cancel access given to no third party Rejecting all other third parties because credentials are common to everyone third parties

If a third party is compromised, the result will be the agreement of goodwill end users. Now, start with OAuth 2.0.

OAuth 2.0 Roles

OAuth 2.0 mainly consists of four types of roles, which are as follows:

• Resource Owner
• Resource Server
• Clients
• Authorization Server

The picture below shows specific OAuth 2.0 roles and their interactions:

OAuth 2.0 roles 

Resource Owner

In the OAuth 2.0 stream, the resource owner belongs only to the user who is interested in it Giving a registered OAuth application to access their account. 

Again, there is no one Here the password is revealed or the full access to the account. 

To what extent User data can be reached by the scope defined by the scope. Different scopes are different Types of OAuth 2.0 permission dialogs. 

Generally, allow scope permissions such as Read or write access to account data, but it is up to the provider to declare that scope According to their usage, as shown in the following screenshots:

Thus, we see Facebook's OAuth 2.0 communication from the previous screenshot Suggesting the resource owner that his public profile and email address will be If the third party registered application is allowed, then it should be used.

Client

In the case of a common man, a customer is an application registered for the bus provider (say Facebook/Google +) and third parties (http://www.example.com) Access or manipulation of user or resource owner data It is concluded that a customer There is only one application which allows the third party to make a request on its behalf Resource Owner for OAuth Provider

Resource Server

A resource server contains protected information or user data that can be accessed Access through token Simply put, a resource server allows/denies access A special resource for an application

Authorization Server

An authorization server is able to give or deny access tokens to the client.

The authorization server certifies the resource and usually through different If everything goes well then the conversation issues a token for the customer.

A resource server and authorization server knit closely and when it is in the same web application, which is often referred to as the OAuth API.

The Application 

The application or client must be registered on the OAuth Provider's website. 

Third-party fill-out details, such as application in the registration process Name, website link, logo, configuration data, and so on. After registering, An application has been assigned a unique identifier called Client ID, as shown in the following screenshots:

Redirect URI

Once OAuth flows, each application must be redirected to a pre-defined URI complete. 

By default, the authorization server rejects a redirect_uri mismatch
Between the application configuration and the actual rendering. Redirect URI OAuth is an important component of the flow, and its kidnapping can have bad consequences The results, which we will see in the upcoming sections of this chapter.

Access Token

An access token is a secret token that has been allocated to the application and tied to a special one User with specific permissions The resource server expects every access token It has been requested to give time.

Client ID

Client ID is a unique identifier, which is returned when the application is registered Successfully This is not confidential information and is important in OAuth's work Applications Different OAuth implementations refer to the client ID individually, for Example, Application ID.

Client Secret 

The customer is a unique token generated during the secret registration process and it is tied For customer ID As the name suggests, a customer secret is personal information and should not be exposed. 

This is done internally while using the token.

Receiving Grants 

OAuth 2.0 basically allows a third-party website to access a limited or select set User information on a particular website There are different types of authority Flow, two of which are common:

• Authorization grant
• Indirect grant

We will take a look at them in the following sub-sections.

Authorization Grant 

An authority grant contains an authorization link, which looks like
Following:

https://www.example.com/oauth/authorize?response_type=code&client_ id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Let's break the various components here:

• response_type: When the code is set, the OAuth Authority Server expects Authorization grant type
• client_id: This application has a Client ID / App ID
• Redirect_urray: This is a URL in the percentage-encoded form and after that The initial flow is complete, the authorization server redirects the flow Specified URL
• Scope: It refers to the level of access required; This is an implementation Specific and different

For an example, visit the following link:

https://www.example.com/oauth/authorize?client_id=2190698099&redirect_ uri= https%3A%2F%2Fprakharprasad.com%2Fredirect&response_ type=code&scope=read

It gives a signal inside the browser. Take a look at the following screenshots:

As soon as the user permits, the page redirects to the following:

https://prakharprasad.com/redirect?code=af8SFAdas

Here, we look at the code parameter, which contains the authorization grant code Generated by the authorization server It can now be exchanged for one access Token; This is usually done on the server side and should include a client secret.

Access Token = Authentic Code + Client ID + Customer Secret + Redirected URI

Typically, a POST request is sent to the authorization server with the predecessor Information: Authorization Code, Client ID, and Client Secret.

https://www.example.com/ /oauth/token?client_id=2190698099&client_ secret=adb12hge&grant_type=authorization_code&code=af8SFAdas&redirect_ uri= https%3A%2F%2Fprakharprasad.com%2Ftoken

Now the token is returned to https://prakharprasad.com/token in JSON format, such as the following:

{ "access_token":" EAACEdEose0cBAE3vD" }

Authorization grant flow ends here. Third-party can now access resources Users by sending proper API calls with access tokens
Resource server The entire process can be summarized in the following flow diagram:

Implicit Grant 

Built-in subsidies are a common way of accessing tokens in web and mobile applications.

This grant does not require a closing point on the client to call the supply-authorization code and then the client receives the token access token. Implementation Grant is Easy to Understand
Compared with the previously explained authority grants. 

Let's look forward what's all this. The underlying grant link looks like the following:

https://www.example.com/oauth/authorize?response_type=token&client_ id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read,write

This authority possesses the same quality of grant, but here is the main difference response_type parameter, which is set to token. 

It directs the authorization The server that we are going to use is built-in; Other parameters are the same The way in which the authorization is in the grant.

See the following links for more information:

https://www.example.com/oauth/authorize?client_id=2190698099&redirect_uri = https% 3A% 2F% 2Fprakharprasad.com% 2Ftoken & response_type = scope of token = read, write

Load the preceding link result of previously seen permission. As soon as the prompt is allowed, the authorization server immediately redirects.

URL in the redirect_urior with access tokens before the URL hash(#), Similar to:

https://prakharprasad.com/token#access_token=EAACEdEose0cBAE3vD

From now on, you can communicate with the resource server using the third party This token

Now that we're ready with OAuth 2.0, then let's discuss some ways we can use OAuth for our benefit

The exploitation of OAuth for fun and profit

Now when we have learned about different OAuth systems, then go straight Exploitation techniques

Open Redirect - Defective URL

Suppose we are exploiting a phishing/client-side browser
Entrance Test Envoy for an Organization Our abuse page is located on http://exploit.example.com/ and they really trust some known websites.

In this example, we consider a trusted website as http://trusted.com.

Simply put, if we directly provide exploitation links to users, they can not click This, but there will be a better chance of a hit of www.trusted.com.

This is Open-redirects are all about; Redirecting user from www.trusted.com to exploit example.com will demonstrate our move as well as take advantage of users' trust.

In OAuth 2.0, some authorization servers suffer from a defect that results indirectly In an open redirect. 

Let's say www.trusted.com runs an OAuth 2.0 Authorization Server and allows its users to register at http://api.trusted.com An OAuth 2.0 Client Application Authority by filling in the appropriate details (Mentioned in the first mention section); Redirect_urory should be set to us The exploitation page is http://exploit.example.com.

Now the application is ready to roll, and the correct grant link looks like the following:

https://api.trusted.com/oauth2/authorization?response_type = code and client_id = 75e7i92lbwy4p4 and scope = read and redirect_ uri = https% 3A% 2F% 2Fexploit.example.com /

This will give the user a general indicator to allow or deny the request.

But because different providers have their own implementation of OAuth 2.0, it Gives a distorted grant link (non-existent or trash) to a scenario The scope of the server, the values ​​of client_ad, etc are the result of redirecting the user The redirect_uri parameter we set before, is the exploitation page.

The distorted grant link looks like the following:

Perverse value in the workspace:

https://api.trusted.com/oauth2/authorization?response_type=code&client_id=75e7i92lbwy4p4&scope=blahblahblah&redirect_uri=http://exploit.example.com/

Malformed value in client_id:

https://api.trusted.com/oauth2/authorization?response_type=code&client_id=idontexistbro&scope=read&redirect_uri=http://exploit.example.com/

Therefore, as soon as these authorities appear on the server, the Redirecting to our OAuth 2.0 application redirect error with error message And the description parameter, such as this one, which is for a distorted radius:

http://exploit.example.com/error=invalid_scope&error_description=The+scope+of+%22blahblahblah%22+is+unknown%2E+Please+check+that+it%27s+property+spelled+and+a+valid+value%2E#!

But regardless of these additional error parameters, we successfully managed its Redirect a trusted website to target the exploitation page and this is its beauty Technique. 

Focus on you, this will not always be the case; It differs from implementation In order to apply. 

The right way to address this thing is from the provider Show an error message instead on provider domain (authorization server) From redirection. 

Personally, I have figured out this flaw that it is quite furious and it Also exists in big websites. LinkedIn's current OAuth 2.0 implementation (At the time of writing) suffers from this issue.

Hijacking the OAuth flow – fiddling with redirect URI

So far, you may be aware of the inherent risks involved in using some of you Redirect_urray in a redirected state where it can be redirected to a different one From the accessed location, access token was abduction from. 

The beauty of OAuth is that once the application is granted to an application, the authority will do the server Do not display again in case of reattempts by the client application (Unless the scope differs from those already present). 

It opens a wide door: By hijacking redirect_urie, we can only obtain an access token for that client.

If the customer is a popular customer and he has many permissions (scope) already, We can use different tricks to fool the authorization server Redirect is given as a redirect_urior given in redirect link Configuration. 

Assume that there is already an OAuth application with too many scopes Given, and we are interested in hijacking redirects for profit. Application letter Only redirect_uri = http://example.com/token/callback is set to allow. 

Again We can use such tricks to circumvent the check and we can do the tokens to hijack us (Hijacker) domain or file.

Directory Traversal Tricks

Directory Traversal Tricks believes that we can save some files of our choice under Allowed domains; This case is common in web applications which allow uploading Files and so on

The following are the URLs that can effectively bypass validation of travelers Not considered:

http://example.com/token/callback/../../our/path
http://example.com/token/callback/.%0a./.%0d./our/path
http://example.com/token/callback/%252e%252e/%252e%252e/our/path
/our/path///../../http://example.com/token/callback/
http://example.com/token/callback/%2e%2e/%2e%2e/our/path

They use different methods such as percent encoding, double percent encoding, And CRLF characters to make the authorization server fool in accepting the specified server
redirect_uri

Domain tricks 

As previously mentioned, if the redirection is allowed http://example.com/token/ Callback, we use two set tricks related to the domain.

Naked Domain 

This means that the correct redirect_puri is a naked domain, which is a subdomain not specified. 

When some issue occurs, some implementations allow sub-domains Naked domains. I found a bug in Facebook that contained an OAuth Inaccurately performed applications in MailChimp service

Example bypass when the naked domain is specified:

https://controlledsubdomain.example.com/token/callback
https://www1.example.com/token/callback
https://files.example.com/token/callback

TLD suffix confusion 

If the appropriate top-level domain is specified, then we can bypass some checks. 

We can do it By redirecting it to a .com TLD, such as replace it with suffix .com .mx .com.br

Original	Suffixed
http://example.com/token/callback	http://example.com.mx/token/callback
http://example.org/token/callback	http://example.org.in/token/callback
http://example.net/token/callback	http://example.net.in/token/callback
http://example.com/token/callback	http://example.com.mx/token/callback

The basic idea here is to just leave the domain access so that the authorization server should verify it and add a valid suffix TLD to overlay the check.

Flow hijack through an open redirect on client 

Sometimes it is easy to find an open redirect on the client website (third party) and/or Its sub-domains are allowed in application configurations. 

We can take advantage of it In an underlying grant scenario, where access tokens will be redirected to the attacker 302 redirects through the domain.

Let's say the domain allowed for redirect_urray is http://www.example.com The configuration of the application, and we have an open redirect at http: //www.example.com; Then we can effectively steal the use token by redirecting to the attacker
Domain/file to grab the token.

• Redirect: http://www.example.com/exit/redirect.php?u=http://www.Google.com
• Exploit: redirect_uri = http: //www.example.com/exit/redirect php u = http: //prakharprasad.com/token/callback

Token will now be redirected to http://prakharprasad.com/token/callback this
The technique is widely known, and usually in the form of a secret, as a secret redirection.

Force a malicious app installation  

Until this point, we know that the authorization process is mostly related to the user Click either the Allow or Disallow button in the grant prompt. 

But using a technique UI-known as the Prevention or ClickJacking, we can only force a user to click Allow the button without recognizing them. 

The first criterion is to take advantage of this issue That grant should be free from any type of security, such as the X-FRAMEOPTIONS header or frame-busting code. 

Basically, we frame the grant sign page On the page in which we can control and hide its opacity value. 

Right up the Permission Button, we make a simple but attractive button on the original page Hope this will be clicked by the user. 

Then we index the button like This attractive button appears in the last and then the permission button The framed page comes first; This is usually done by z-index CSS properties. 

Now, I This point, the permission button is invisible to the user, but it is actually there, and in fact, It's just above the catchy button. 

So as soon as the user tries to hit the catchy Button, instead they click on the permission button and the game is over for them. The transparent version of this type of action resembles the following screenshot:

Just look at the image above, imagine if the OAuth Authority page is hidden, but At the top, more users hit the click here button. 

This will effectively allow Instead of the application, an access token will be given by the attacker the user. 

This technique is super useful because any potential OAuth scope can be provided Without the user watching it However, this scenario is not the most common Providers use some clickjacking protection, but occasionally misconceived, And this trick works in those cases.

Summary

OAuth 2.0 security is something I recommend researching. There are lots of Issues that are limited to only one provider because they make heavy modifications OAuth; These tweaks are more buggy. 

This Web Application Penetration Testing Tutorial deals with the useful basics of OAuth and various ways in which we can exploit OAuth Security There are some classic audio bugs, which I did not cover here but I recommend you to read about the state parameter OAuth2 CSRF.

Related:

• Web application penetration testing tutorials Common security protocols
• Web application penetration testing tutorials Information gathering
• Web application penetration testing tutorials SQL injection attack
• Web application penetration testing tutorials - Cross-site request forgery