CN115189924B - OAuth2.0 open redirection vulnerability detection method and system - Google Patents

Abstract

An OAuth2.0 open redirect vulnerability detection method and system, characterized in that the method includes the following steps: Step 1, detect the URI field in the API interface of the third party authorized by OAuth2.0, discover and Record all callback parameters involved; step 2, based on the predefined callback parameter table, match the types of all callback parameters obtained in step 1, and match the parameters of the callback parameters based on the matching results The value is replaced; step 3, simulate a user request to call the API interface that has implemented parameter replacement, and implement the detection of vulnerabilities in the API interface based on the response result of the call. The method of the present invention is simple and effective, and can fundamentally detect the problem that URI parameters are modified during the open redirection process, thereby realizing the remediation and prevention of vulnerabilities.

Description

A detection method and system for OAuth2.0 open redirect vulnerability

Technical Field

The present invention relates to the field of integrated circuits, and more specifically, to a detection method and system for OAuth2.0 open redirection vulnerabilities.

Background technique

Currently, in the complex network ecosystem centered on open platforms, RESTful API is the main type of Web API. However, RESTful API has serious security threats in the authorization method based on the OAuth 2.0 protocol. When using Web API to integrate various Internet services based on the Web, the various integration services that appear usually have complex design and implementation scenarios in terms of functions and protocol processes. It is this complexity that creates new security threats in boundary interactions of various original Web systems. In the existing technology, Web API vulnerability mining mainly focuses on logical vulnerability mining. The security problems of RESTful API mainly include: interface abuse and consumption of system resources, data leakage, forgery/tampering of data, application imitation, etc.

The OAuth 2.0 protocol is a protocol designed to provide an open standard for authorization. It allows users to allow third-party applications to have limited access to the user's data stored in other applications without exposing information such as user names and passwords to third-party applications. As OAuth 2.0 becomes one of the most popular frameworks, more and more websites use the OAuth 2.0 protocol for authorization to provide resource services. One of the most common uses is for authorization of third-party logins. When a user visits a website and chooses to log in with a third-party account, the website will redirect him to the server where the third-party account is located. The user provides his account password to pass the verification of the third-party account server and agree to authorization. After the third-party authorization server successfully verifies the user's identity, an authorization code will be issued and the user will be redirected to the website. The website can then request a token based on the authorization code to access the resources of the user's third-party account. However, even if the OAuth protocol is adopted, there are still problems in the RESTful API such as redirect_uri being bypassed or being attacked and modified. When the redirecturi is bypassed, the OAuth token will be hijacked, resulting in a serious problem of user account hijacking.

Currently, the mainstream redirect_uri anomaly detection methods can usually only use open redirect vulnerabilities to trick users into visiting the URL of a trustworthy site and redirect them to a new site. In this detection method, the method usually ultimately detects whether the new website is a legitimate website, thereby determining whether the open redirect function is abnormal or not.

However, this method cannot fundamentally determine the safety of open redirection methods. Specifically, if the attacker modifies the parameter point of the callback URI, forges a callback URI as his own address and sends the forged user authorization link to the target user. Then, when the target user clicks on the forged link and authorizes the login, the server will send the user's credentials to the attacker, and the attacker can use this to log in to the user's account. In the existing technology, there is also a more threatening attack method for this modification method. The attacker can use a third party to modify the redirect_uri during the login process through the API to obtain unused authorization codes. At this time, the attacker may not modify the redirect_uri to the attacker's address, but in order to attack the third-party website, modify the redirect_uri to a URI address in another third-party website that has the same origin as the original address, thereby achieving the attack. In this case, simply considering the legality of the website address cannot fully prevent or avoid the threat to the website caused by modifying the parameters in redirect_uri.

In response to the above problems, the present invention provides a new OAuth2.0 open redirection vulnerability detection method and system.

Contents of the invention

In order to solve the deficiencies in the existing technology, the purpose of the present invention is to provide a detection method and system for OAuth2.0 open redirection vulnerabilities, by detecting the URI field in the API interface, looking for the URI callback parameters, and Modify the URI according to the preset callback parameter type and replacement method, and implement vulnerability detection in the API interface through new user requests.

The present invention adopts the following technical solution.

The first aspect of the present invention relates to a method for detecting OAuth2.0 open redirection vulnerabilities, wherein the method includes the following steps: Step 1, detect the URI field in the API interface of the third party authorized by OAuth2.0, discover and Record all callback parameters involved; Step 2, based on the predefined callback parameter table, match the types of all callback parameters obtained in Step 1, and replace the parameter values of the callback parameters based on the matching results; Step 3 , simulate user requests to call API interfaces that implement parameter replacement, and detect vulnerabilities in API interfaces based on the response results of the calls.

Preferably, all callback parameters include at least the redirect_uri parameter and the destination parameter.

Preferably, the predefined callback parameter table includes not only the predefined callback parameter type, but also the matching relationship between the relevant parameters in the API interface and the callback parameter type, and the matching relationship between the callback parameter type and the replacement parameter value.

Preferably, in step 2, the parameter value of the callback parameter is replaced based on the matching relationship between the callback parameter type and the replacement parameter value in the callback parameter table.

Preferably, the user who generates the user request is an authorized user of the platform and is allowed to access an authorized third party based on OAuth2.0; the user request corresponds to a call to an API interface of an authorized third party that has implemented parameter replacement.

Preferably, the platform is a platform that implements third-party application authorization access based on OAuth2.0, including an OAuth2.0 server.

Preferably, when the response result of the call is inconsistent with the response result before the parameter value is replaced, it is determined that the parameter value has been replaced and there is a vulnerability in the API interface.

Preferably, the authorization code in the user request is obtained by: intercepting HTTP traffic based on ARP attacks, and parsing the plaintext authorization code from the HTTP traffic; or forging HTTP REFERER to obtain the authorization code; or intercepting HTTP based on burpsuite traffic to obtain unused authorization codes.

A second aspect of the present invention relates to a detection system for OAuth2.0 open redirection vulnerabilities, wherein the system is implemented using a detection method for OAuth2.0 open redirection vulnerabilities as described in the first aspect of the present invention.

The beneficial effect of the present invention is that, compared with the prior art, the OAuth2.0 open redirect vulnerability detection method and system in the present invention can detect the URI field in the API interface, find the URI callback parameter, and modify the URI according to the preset callback parameter type and replacement method, and realize vulnerability detection in the API interface through a new user request. The method of the present invention is simple and effective, and can fundamentally detect the problem of URI parameter modification in the open redirection process, thereby realizing the remedy and prevention of the vulnerability.

Description of drawings

Figure 1 is a schematic diagram of the steps of a method for detecting OAuth2.0 open redirection vulnerabilities in the present invention.

Detailed ways

The present application will be further described below in conjunction with the accompanying drawings. The following examples are only used to more clearly illustrate the technical solutions of the present invention, but cannot be used to limit the protection scope of the present application.

Figure 1 is a schematic diagram of the steps of a method for detecting OAuth2.0 open redirection vulnerabilities in the present invention. As shown in Figure 1, a method for detecting OAuth2.0 open redirect vulnerability, in which the method includes steps 1 to 3.

Step 1: Detect the URI field in the third-party API interface authorized by OAuth2.0, discover and record all callback parameters involved.

First, in the method of the present invention, in order to modify the specific value content of the relevant callback parameters in the URI field, it is necessary to first determine which callback parameters exist in the API interface.

Specifically, in the existing technology, most of the open platforms and third parties are used to implement various Internet services. The services implemented through this cooperation can simplify the complexity of the third-party application code writing process, and can also fully import users in the open platform into third-party applications. For the open platform, it can provide users with various customized services more conveniently.

Usually, an open platform will make API rules and provide API interfaces for third-party applications to call, thereby realizing business connection and user access.

However, due to the limited security of API interfaces, today's mainstream open platforms basically use OAuth2.0 to authenticate users and process user requests to access third-party applications. The method in the present invention is precisely aimed at detecting the risks existing in this process.

Specifically, in order to access a third-party application, the user will obtain the authorization code from the open platform, thereby obtaining the redirection address or field sent by the third-party application to the open platform. In the present invention, it is redirect_uri, where uri refers to the unified Resource identifier (Uniform Resource Identifier). During this process, when the user's client calls back the URI, if the parameter content in the URI is tampered with, the response result of the user's callback may be abnormal.

Therefore, in the present invention, in order to detect whether the parameter content in the uri has been tampered, the process of uri tampering is simulated, thereby realizing the detection of the vulnerability. In order to simulate the tampering process of the parameters in the uri, in step 1 of the present invention, all callback parameters in the uri of the API interface are first extracted. In the present invention, a scanner commonly used in the prior art can be used to realize the extraction of callback parameters.

Preferably, all callback parameters include at least the redirect_uri parameter and the destination parameter.

In the present invention, the contents of various callback parameters can be determined according to the contents of the API interface provided by the open platform. But generally speaking, the uri can include related callback parameters such as the redirected website address parameter redirect_uri and the intrusion detection destination address parameter destination.

Step 2: Based on the predefined callback parameter table, match the types of all callback parameters obtained in step 1, and replace the parameter values of the callback parameters based on the matching results.

Preferably, the predefined callback parameter table includes not only the predefined callback parameter type, but also the matching relationship between the relevant parameters in the API interface and the callback parameter type, and the matching relationship between the callback parameter type and the replacement parameter value.

It should be noted that the callback parameter table in the present invention can be stored in the form of a txt file. This file not only includes all the callback parameters included in the various API interfaces of the open platform, but also includes the types of various callback parameters, and if the callback parameter is found, the value of the callback parameter can be replaced. Default parameter values.

In addition, the name of the callback parameter, the API interface it belongs to, the callback parameter type and the preset parameter value for replacement can be recorded in a one-to-one correspondence manner. Therefore, this callback parameter table can be used for subsequent replacement of values in the callback parameter and the detection method of the present invention.

Preferably, in step 2, the parameter value of the callback parameter is replaced based on the matching relationship between the callback parameter type and the replacement parameter value in the callback parameter table.

In the present invention, the replacement of parameter values in different callback parameters is implemented formally based on the corresponding relationship recorded in the txt file.

Step 3: Simulate user requests to call the API interface that implements parameter replacement, and detect vulnerabilities in the API interface based on the response results of the call.

In the present invention, after completing the replacement of parameter values in callback parameters, vulnerability detection can be implemented.

Preferably, the user who generates the user request is an authorized user of the platform and is allowed to access an authorized third party based on OAuth2.0; the user request corresponds to a call to an API interface of an authorized third party that has implemented parameter replacement.

In the present invention, a user request is first simulated, and the user request can be a real user of a third-party platform, or a simulation of a real user implemented by a method in the prior art. If it is a simulation of a real user, the present invention needs to first obtain the authorization code given to the user by the open platform.

Through the user's authorization code, the user can request the open platform to realize the connection between the client and third-party applications. In the process of connecting to the third-party platform, the user will use the callback parameters provided by the open platform. If the callback parameters are replaced, then the URL fed back to the user by the open platform will have problems, at least as long as the callback parameters have not been replaced. The previous URL is different. This difference is not limited to addresses from different sources, but also includes different addresses from the same source.

Preferably, the platform is a platform that implements third-party application authorization access based on OAuth2.0, including an OAuth2.0 server. The platform described here is the open platform mentioned above, which at least includes an OAuth2.0 server to enable access to third-party applications.

Preferably, when the response result of the call is inconsistent with the response result before the parameter value is replaced, it is determined that the parameter value has been replaced and there is a vulnerability in the API interface.

Preferably, the method for obtaining the authorization code in the user request is: intercepting HTTP traffic based on ARP attack and parsing the plaintext authorization code from HTTP traffic; or, forging HTTP REFERER to obtain the authorization code; or, intercepting HTTP traffic based on burpsuite to obtain an unused authorization code.

In the present invention, in order to simulate user requests, multiple different methods can be used to obtain the authorization code. In the process of obtaining the authorization code, one or more of the methods of obtaining the authorization code mentioned above can be used to realize that the simulated non-real user's request is accepted by the open platform.

If the method of the present invention finds that the relevant uri parameters in the API interface have been changed, the modified parameters and related information, such as the modified content, the corresponding API interface, etc., can be recorded in the database for subsequent follow-up. Improvements to API interface security.

In one embodiment of the present invention, six service platform providers capable of providing third-party login were selected for experiments, namely Tencent QQ, WeChat, Sina Weibo, Baidu, Renhe and Douban. After pre-screening among the top 500 Chinese websites, 233 websites implemented third-party login services for the above-mentioned 6 open platforms. Therefore, in the embodiment of the present invention, the account hijacking attack experiment is conducted based on these 233 websites.

Authorization for hijacking experiments must meet the following conditions:

(1) Whether redirect_uri can be modified is determined during the detection process based on the OAuth Callback module of the automated scanning system.

(2) In the present invention, the authorization code is obtained by intercepting HTTP traffic or inserting pictures. In the method of intercepting HTTP traffic and stealing authorization codes, when the parameter value of redirect_uri is modified to a website that uses the HTTP protocol for communication, the attacker intercepts any sent messages through an ARP (Address Resolution Protocol) attack on the same LAN. traffic to the target site, thereby parsing the authorization code from the intercepted traffic. In the method of inserting pictures, visiting a website that inserts pictures will send two requests. The attacker can issue a request to insert a remote picture and send the request to the remote server to obtain the authorization code through the Referer. In addition, since there is a binding relationship between the authorization code and the current session, the present invention can also use burpsuite to intercept traffic to obtain an unused authorization code, and then use the authorization code to reconstruct a new request to determine whether it can be successful. Log in.

This is because the reason why various callback parameters in the API interface, such as redirect_uri, can be modified is mostly because the developer did not impose strict restrictions on the authorized jump directory during the development of the API interface. When the redirect_uri can be modified by an attacker, the attacker usually changes the jump address to a website using the HTTP protocol. Therefore, theoretically, the proportion of API interfaces where the attacker can obtain authorization codes and the proportion of API interfaces with OAuth Callback vulnerabilities Much the same. In addition, the main reason why the website can embed remote images is that the website has not set up external image sources.

After implementing the automated vulnerability scanning framework, the OAuth Callback detection module was used to detect some websites. In this example, the inventor successfully discovered that the redirect_uri of the RESTful API of third-party logins of many websites could be modified, and then discovered that some websites There is a risk of account hijacking. In addition, this embodiment can also implement two different running modes of OAuth Callback scanning, one is to run directly through the command line, and the other is to operate through the web interface. Finally, the method of the present invention not only enables developers to detect whether there are vulnerabilities in the current RESTful API when developing RESTful APIs, but also realizes vulnerability detection of online API interfaces, greatly improving the security of the API interface and reducing the risk of inaccuracies. necessary losses.

Table 1 and Table 2 show the test results of the above embodiments. As shown in Table 1, the vast majority of 68.67% of websites in the existing technology have OAuth Callback vulnerabilities. At the same time, these websites can also be easily obtained by attackers to obtain user authorization codes. In addition, 12.87% of websites can be used by attackers to obtain authorization codes by embedding remote images. In addition, about 60% of users have the problem that authorization codes are not bound to the current session. To sum up, the number of websites that obtain authorization codes through various methods and are implemented and completed account hijacking attacks by attackers accounts for about 45.49% of all websites, which is still a very large number. Therefore, the vulnerability detection method in the present invention can enable the open platform or third-party application website to promptly discover problems that occur during the authorization process and code vulnerabilities, thereby realizing the repair and improvement of vulnerabilities.

category Number of websites/number ratio OAuth Callback vulnerability exists 160/68.67% Can obtain authorization code 160/68.67% Ability to embed remote images 30/12.87% The authorization code is not bound to the current session 139/59.66% Capable of completing account hijacking attacks 106/45.49%

Table 1 Redirect uri detection results of 233 websites

In addition, the present invention analyzes different open platforms, that is, six different service providers, and finds out the extent to which the callback parameters in the API interfaces provided by them can be modified. Among them, the callback parameters of only two service providers will not be modified by the detection method of the present invention, while the other four platforms can all be modified. In addition, popularity data refers to the degree to which these platforms are accessed by third parties in the form of third parties among the top 500 websites in this invention.

service provider Popularity Callback uri can be modified Platform A 211/90.56% 0 Platform B 146/62.67% 38/26.03% Platform C 192/82.40% 143/74.47% Platform D 10/4.29% 5/50.00% Platform E 13/5.58% 9/69.23% Platform F 9/3.86% 0

Table 2 Analysis results of account hijacking on 6 platforms

The beneficial effect of the present invention is that, compared with the prior art, the OAuth2.0 open redirect vulnerability detection method and system in the present invention can detect the URI field in the API interface, find the URI callback parameter, and modify the URI according to the preset callback parameter type and replacement method, and realize vulnerability detection in the API interface through a new user request. The method of the present invention is simple and effective, and can fundamentally detect the problem of URI parameter modification in the open redirection process, thereby realizing the remedy and prevention of the vulnerability.

The applicant of the present invention has made a detailed explanation and description of the implementation examples of the present invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above implementation examples are only preferred embodiments of the present invention, and the detailed description is only to help readers better understand the present invention. It is not intended to limit the protection scope of the present invention. On the contrary, any improvements or modifications made based on the inventive spirit of the present invention should fall within the protection scope of the present invention.

Claims (7)

1. A method for detecting OAuth2.0 open redirect vulnerability, characterized in that the method includes the following steps: Step 1: Detect the URI field in the third-party API interface authorized by OAuth2.0, discover and record all callback parameters involved; Step 2: Match the types of all callback parameters obtained in step 1 based on the predefined callback parameter table, and replace the parameter values of the callback parameters based on the matching results; The predefined callback parameter table includes predefined callback parameter types, matching relationships between relevant parameters in the API interface and callback parameter types, and matching relationships between the callback parameter types and replacement parameter values; Based on the matching relationship between the callback parameter type and the replacement parameter value in the callback parameter table, replace the parameter value of the callback parameter; Step 3: Simulate user requests to call the API interface that has implemented parameter replacement, and implement vulnerability detection in the API interface based on the response results of the call; Step 4: Record the uri parameters and corresponding API interfaces modified during the vulnerability detection process into the database, and use the detection results as a basis for improving the API interface. 2. A method for detecting OAuth2.0 open redirection vulnerabilities according to claim 1, characterized by: All callback parameters include at least redirect_uri parameters and destination parameters. 3. A method for detecting OAuth2.0 open redirection vulnerabilities according to claim 2, characterized by: The user who generated the user request is an authorized user of the platform and is allowed to access authorized third parties based on OAuth2.0; The user request corresponds to a call of the API interface of the authorized third party that has implemented parameter replacement. 4. A method for detecting OAuth2.0 open redirection vulnerability according to claim 3, characterized by: The platform is a platform that realizes authorized access of third-party applications based on OAuth2.0, including an OAuth2.0 server. 5. A method for detecting OAuth2.0 open redirection vulnerability according to claim 4, characterized by: When the response result of the call is inconsistent with the response result before replacing the parameter value, it is determined that the parameter value has been replaced and there is a vulnerability in the API interface. 6. A method for detecting OAuth2.0 open redirection vulnerability according to claim 5, characterized by: The method of obtaining the authorization code in the user request is: Intercept HTTP traffic based on ARP attack and parse the plain text authorization code from the HTTP traffic; or, Forge an HTTP REFERER to obtain said authorization code; or, Intercept HTTP traffic based on burpsuite to obtain unused authorization codes. 7. A detection system for OAuth2.0 open redirection vulnerability, characterized in that: The system is implemented using an OAuth2.0 open redirect vulnerability detection method as described in any one of claims 1-6.