Shulou(Shulou.com)05/31 Report--

This article introduces you to the common security problems in the OAuth implementation mechanism, the content is very detailed, interested partners can refer to it, I hope it can help you.

The following is a brief discussion of some common problems with OAuth implementation (specifically OAuth 2.0) from a security perspective.

Quick understanding.

When discussing OAuth, there are several different versions and authorization types. If you want to read the research, I suggest you read through https://oauth.net/2/to get some basic knowledge. In this article, I will focus on the most common OAuth 2.0 authorization code type pattern, which is also the most complete and rigorous authorization pattern in the authorization process. Essentially, OAuth provides an authorization mechanism for developers to allow applications to access user data or perform certain actions on user accounts from another application (authentication server) for the current user identity.

For example, https://yourtweetreader.com can provide Twitter users with the display function of all posts (including private posts). In order to achieve this function, https://yourtweetreader.com needs to deploy OAuth 2.0 mechanism, which will require authorization to access the user's Twitter permission to read the posted content. Before this, https://yourtweetreader.com will pop up an authorization page, specifying the specific content it requests from the user's Twitter account. If the user clicks agree, https://yourtweetreader.com will access the user's Twitter account as a user to obtain the posted content. In this case, https://yourtweetreader.com has very high permissions.

There are several key elements to understand:

The resource owner, the "user" who owns the application account;

A resource server, or application server, where the service provider stores user-generated resources, in this case https://twitter.com. It can be the same server as the authorization server mentioned below, or it can be a different server.

Client application: Also known as a client application, https://yourtweetreader.com in this case, it initiates an authorization request to gain access to a user's Twitter account;

authorization server: authentication server, i.e. server dedicated by service provider to process authentication. After user agrees to authorization request initiated by third party application, this server will generate an access token for third party application, i.e. https://www.example.com in this example; twitter.com

Client ID (client_id): The client ID number generated by the third-party application for the user. Generally speaking, it is a public unique identifier. The third-party application uses client_id to identify the user.

Third-party application key (client_secret): This is a key specially generated by the authorization server for the third-party application when the third-party application initiates an authorization request. It will be sent to the authentication server via POST along with other authentication parameters.

response_type: indicates the authorization type, in this case, the "code" authorization code type;

Scope: indicates the scope of authority that the third-party application applies to the authentication server;

redirect URI (redirect_uri): indicates the redirect URI, that is, the address to jump to after authorization is successful;

Client state: The current state of the client. You can specify any value. The authentication server returns this value intact. Because it can contain random characters or unique values, one of its important uses is as a CSRF defense in requests;

grant_type: indicates the authorization mode used, in this case "authorization_code";

Authorization code: After the user clicks authorization consent, the authorization server returns an authorization code to the third-party application, and then the third-party application uses the code in combination with the client_id and client_secret of the user to exchange for an access token from the authorization server;

access token: The third-party application uses this token information to initiate an access request to the resource server on behalf of the user of the resource owner;

Refresh_token: third-party applications use it in the background to get the next access token.

With this introduction, let's take a look at the simple OAuth process, using the above display tweet as an example:

1. Users visit https://yourtweetreader.com and click the "Integrate with Twitter" button;

2. https://yourtweetreader.com initiates an authorization request to https://twitter.com, hoping to read the tweets posted by the user on the Twitter resource server; the request that occurs after the user clicks the "Integrate with Twitter" button is roughly as follows:

https://twitter.com/auth ? response_type=code &client_id=yourtweetreader_clientId &redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback &scope=readTweets &state=kasodk9d1jd992k9klaskdh223

3. After that, an authorization page will pop up:

4. After clicking Authorization Approval, the link will jump to the redirect_uri part of the previous request, and will add the code and state parameters assigned by Twitter:

https://yourtweetreader.com? code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh223

https://yourtweetreader.com uses this code, in combination with client_id and client_secret, to initiate a POST request to the Twitter resource server to obtain an access token representing the user identity. POST requests are roughly as follows:

POST /oauth/access_tokenHost: twitter.com... {"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"}

Finally, after the above process is completed, https://yourtweetreader.com will use the obtained access token to read the user's post on Twitter.

OAuth issues found during vulnerability crowdtesting

Here are a few types of OAuth problems I found during vulnerability testing, which will have a security impact on OAuth implementation to a greater or lesser extent:

Misconfiguration of redirect url

This is a common security problem in OAuth implementations. The redirect url (redirect_uri) in the request is very important. The authorization code returned by the authorization server to the third-party application is appended to the redirect_uri. If the redirect url (redirect_uri) can be configured as a link controlled by other attackers, it means that the attacker can obtain the authorization code and indirectly hijack the user account.

This problem can exist in a variety of authorization servers, some of which only accept url links belonging to third-party applications, while others accept links to subdomains of third-party applications, or any domain name.

According to the various redirect url (redirect_uri) rules deployed by the authorization server, there are several ways to bypass the redirect_uri rule, assuming that the attacker controls the website https://evil.com and the redirect_uri exists in the following user authorization request:

https://api.twitter.com/oauth3/authorize? client_id=123050457758183&redirect_uri=https://yourtweetreader.com/callback

There are several ways to bypass the redirect_uri rule:

1. Open redirection: https://yourtweetreader.com/callback? redirectUrl=https://evil.com

2. Path traversal bypass: yourtweetreader.com/callback/../ redirect? url=https://evil.com

3. Construct a domain name link similar to the third-party application link in redirect_uri: yourtweetreader.com.evil.com

4. HTML injection and token stealing can be achieved by constructing request links and using the referrer header:

https://yourtweetreader.com/callback/home/attackerimg.jpg

Error handling of state parameter

This is also a common security issue in OAuth implementations, where the state parameter is often ignored entirely or incorrectly applied. If the state parameter does not exist in the request, or if its static value is always the same, then the OAuth process may have a cross-site request forgery problem (CSRF). Sometimes, even if the state parameter exists, it can be exploited by attackers if third-party applications do not verify it. Suppose that after the user clicks on the authorization request of the third-party application, the resource server assigns an authorization code to the user, and then the authorization code and the state parameter perform a jump in the third-party application, such as:

https://yourtweetreader.com? code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh223

I've seen that the state parameter location can be constructed as another URL to jump exploit, and after redirect_uri makes the first jump, the state parameter is made a second jump by the attacker. And this situation can occur in some authorized login scenarios, which can lead to account hijacking. Examples I have encountered include:

Attackers can use Slack's integrated authorization function to add accounts and indirectly steal the recipient's information and related message prompts;

Stripe's integrated authorization feature allows attackers to overwrite payment records and steal payment records from victim accounts.

An attacker could exploit PayPal's integrated authorization feature to add additional tied accounts to a victim's account, thereby stealing funds from the victim's account.

Previous account hijacking with email address

Another OAuth security problem is that some third-party applications not only allow authorized logins such as "Sign in with X," but also allow username and password logins. Here, there are two exploitable situations:

If a third-party app lacks email authentication at the time of user account creation, an attacker can create an app account with the victim's email address plus an arbitrary password as the victim, knowing the victim's email address, before the victim creates the app account. Later, once the victim tries to create or log in in the third-party application, because his email address has been previously created by the attacker, the victim's creation or login process link will be bound to the account previously created by the attacker. This is a typical "pre account takeover" attack, in which the attacker uses the victim information to create an account before the victim creates an account.

2. If the third-party application lacks email verification when signing up the user account, the above "pre account takeover" method can also be used to achieve account hijacking.

Disclosure of authentication flow parameter information

For various authentication flow parameters of OAuth, strictly speaking, it is necessary to distinguish which are confidential and should be protected. For example, if the client_id and client_secret of the user are leaked, it is very dangerous, especially client_secret. Attackers can use the entity identity of the trusted client to steal the access token and other private information of the victim, and even realize account hijacking. Returning to our example above, consider the following process:

https://yourtweetreader.com After requesting access_token from the resource server using the authorization code, client_id, and client_secret, the user's account permissions on the resource server will be obtained by using the obtained access_token.

If client_secret is compromised during client operations, an attacker could use it to obtain access_token representing the victim user identity, and with some social engineering tricks, an attacker could add more scope to OAuth authorization. And since the requests are from trusted client applications, they will all appear legitimate.

What are the common security issues in the OAuth implementation mechanism to share here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.