Automatic test method, device and equipment for unauthorized vulnerabilities and storage medium

Abstract

The invention belongs to the technical field of artificial intelligence, and discloses an automatic test method, device and equipment for an unauthorized vulnerability and a storage medium, and the method comprises the steps: obtaining API request information of a normal function case and corresponding initial response information, and configuring corresponding login information for users with different permissions; automatic login is carried out according to the configured login information of the users with the different permissions, and authentication information of the users with the different permissions is acquired after automatic login succeeds; replacing original authentication information in the obtained API request information of the normal function case with authentication information obtained after automatic login succeeds, and resending the API request information; and presetting a rule for judging whether the API of the normal function case has an unauthorized vulnerability or not, analyzing the initial response information and the response information obtained after the API request is resent, and judging whether the API of the normal function case has the unauthorized vulnerability or not. According to the invention, the test efficiency of the unauthorized vulnerability is effectively improved.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to an automated testing method, device, equipment and storage medium for unauthorized vulnerabilities. Background Art

[0002] Security is a crucial link in the software development life cycle. From code writing to maintenance after software release, security vulnerabilities may be introduced at each stage. In order to effectively prevent these security vulnerabilities, automated testing tools such as IDE security plug-ins, dynamic application security testing tools, static application security testing tools, and interactive application security testing tools are introduced. These automated testing tools can detect traditional SQL injection vulnerabilities, cross-site scripting attack vulnerabilities and other security vulnerabilities before software is released.

[0003] However, unauthorized vulnerabilities belong to the category of logical vulnerabilities, which mainly refers to the ability of users to access or operate resources or functions beyond their authority without obtaining the corresponding authority. Unauthorized vulnerabilities exist because of defects in the design and implementation of the system's authentication and authorization process, authentication logic, or business logic. Existing automated testing tools cannot detect unauthorized vulnerabilities. Major companies use manual detection of unauthorized vulnerabilities. However, manual detection is prone to miss some security vulnerabilities and the detection cost is high. Summary of the invention

[0004] The present invention provides an automated testing method, device, equipment and storage medium for unauthorized vulnerabilities, so as to solve the technical problem that existing automated testing tools cannot detect unauthorized vulnerabilities.

[0005] First, an automated testing method for an unauthorized vulnerability is provided, including:

[0006] Obtain API request information and corresponding initial response information for normal functional use cases, and configure corresponding login information for users with different permissions;

[0007] Automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after successful automatic login;

[0008] Replace the original authentication information in the API request information of the normal function use case with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information;

[0009] Preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules to determine whether the API of a normal functional use case has an unauthorized vulnerability;

[0010] A scan report is generated based on the judgment result of whether the API of the normal functional use case has an unauthorized access vulnerability, and post-processing of the API unauthorized access vulnerability is performed based on the generated scan report.

[0011] In a second aspect, an automated testing device for an unauthorized vulnerability is provided, wherein the device is used to implement the automated testing method for an unauthorized vulnerability as described in any one of the first aspects, including:

[0012] The acquisition module obtains the API request information of normal functional use cases and the corresponding initial response information, and configures corresponding login information for users with different permissions;

[0013] The login module is used to automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after successful automatic login;

[0014] A replacement module is used to replace the original authentication information in the API request information of the normal function use case obtained with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information;

[0015] The analysis module is used to preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules;

[0016] The processing module is used to generate a scan report based on the analysis results of the initial response information and the response information obtained after resending the API request, and perform post-processing of the API unauthorized vulnerability based on the generated scan report.

[0017] In a third aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the steps of the automated testing method for the above-mentioned unauthorized vulnerability are implemented when the processor executes the computer program.

[0018] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the automated testing method for the above-mentioned unauthorized vulnerability are implemented.

[0019] In the scheme implemented by the above-mentioned automated testing method, device, equipment and storage medium for unauthorized access vulnerabilities, it is possible to obtain API request information and corresponding initial response information of normal function use cases, and configure corresponding login information for users with different permissions; automatically log in according to the configured login information of users with different permissions, and obtain authentication information of users with different permissions after successful automatic login; replace the original authentication information in the obtained API request information of normal function use cases with the authentication information of users with different permissions obtained after successful automatic login, and resend the API request information after replacing the authentication information; preset rules for judging whether the API of normal function use cases has unauthorized access vulnerabilities, and perform the initial response information and the resent authentication information according to the preset rules. Analyze the response information obtained after sending the API request to determine whether the API of the normal function use case has an unauthorized vulnerability; generate a scan report based on the judgment result of whether the API of the normal function use case has an unauthorized vulnerability, and post-process the API unauthorized vulnerability based on the generated scan report. In the present invention, the original authentication information in the API request information of the normal function use case is replaced with the authentication information of the user with different permissions obtained after the automatic login is successful, and the API request information is resent after the authentication information is replaced. According to the preset rules, the initial response information and the response information obtained after the API request is resent are analyzed to determine whether the API of the normal function use case has an unauthorized vulnerability, thereby effectively improving the testing efficiency of the unauthorized vulnerability. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0021] Figure 1 It is a schematic diagram of an application environment of an automated testing method for an unauthorized vulnerability in one embodiment of the present invention;

[0022] Figure 2 It is a flow chart of an automated testing method for an unauthorized vulnerability in one embodiment of the present invention;

[0023] Figure 3 yes Figure 2 A schematic flow chart of a specific implementation of step S30;

[0024] Figure 4 yes Figure 2 A schematic flow chart of a specific implementation of step S40;

[0025] Figure 5 yes Figure 4A schematic flow chart of a specific implementation of step S43;

[0026] Figure 6 yes Figure 5 A schematic flow chart of a specific implementation of step S432;

[0027] Figure 7 yes Figure 2 Flow chart of the result judgment of the unauthorized access vulnerability in step S40;

[0028] Figure 8 yes Figure 2 The result judgment flow chart of the vertical over-authorization vulnerability in step S40;

[0029] Fig. 9 yes Figure 2 Flow chart of the result judgment of the horizontal privilege escalation vulnerability in step S40;

[0030] Fig.10 It is a structural schematic diagram of an automated testing device for unauthorized vulnerability in one embodiment of the present invention;

[0031] Fig.11 is a schematic diagram of a structure of a computer device in one embodiment of the present invention;

[0032] Fig.12 It is another structural schematic diagram of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0034] The automated testing method for unauthorized vulnerabilities provided by the embodiment of the present invention can be applied in the following aspects: Figure 1 In the application environment, Figure 1It is a schematic diagram of an application environment of an automated testing method for unauthorized access vulnerabilities in one embodiment of the present invention; wherein, the client communicates with the server via a network. The server can obtain the API request information and the corresponding initial response information of a normal function use case through the client, and configure corresponding login information for users with different permissions; automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after the automatic login is successful; replace the original authentication information in the obtained API request information of the normal function use case with the authentication information of the users with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information; preset rules for determining whether the API of the normal function use case has an unauthorized access vulnerability, and perform a test on the initial response information and the response information obtained after resending the API request according to the preset rules. The information is analyzed to determine whether the API of the normal function use case has an unauthorized vulnerability; a scan report is generated based on the judgment result of whether the API of the normal function use case has an unauthorized vulnerability, and the API unauthorized vulnerability is post-processed according to the generated scan report. In the present invention, the original authentication information in the obtained API request information of the normal function use case is replaced with the authentication information of the user with different permissions obtained after the automatic login is successful, and the API request information is resent after the authentication information is replaced, and the initial response information and the response information obtained after the API request is resent are analyzed according to the preset rules to determine whether the API of the normal function use case has an unauthorized vulnerability, thereby effectively improving the testing efficiency of the unauthorized vulnerability. The present invention is described in detail below through specific embodiments.

[0035] See also Figure 2 As shown, Figure 2 A schematic flow chart of an automated testing method for an unauthorized vulnerability provided by an embodiment of the present invention includes the following steps:

[0036] S10: Obtain API request information and corresponding initial response information of normal functional use cases, and configure corresponding login information for users with different permissions.

[0037] When testing unauthorized vulnerabilities, the present invention can first obtain the API request information and corresponding initial response information of normal functional use cases from the interface management platform or other automated testing tools. Generally, there are two ways to obtain the API request information and corresponding initial response information of normal functional use cases. The first way is to obtain a normal functional use case that has been tested from the interface management platform. When the functional use case is executed, the complete API request information and the corresponding initial response information can be saved for the automated testing tool to call. After the functional use case is executed, the system can store the complete API request information and the corresponding initial response information. These stored data can be obtained and used by the automated testing tool to determine whether the system functions normally. The second way is to manually or automatically capture packets during the testing process of the functional use case, capture the complete API request information and the corresponding initial response information, save them, and import them into the automated testing tool.

[0038] It should be noted that API request information is the data sent by the client when requesting the server to perform an operation or obtain certain data. The complete API request information includes the request method, request URL, request header and request body. Among them, the request method includes GET (used to obtain data) and POST (used to submit data to create new resources). For example, when querying user order information, the GET method may be used; the request URL is the address of the server-side API, which specifies the target location of the request; the request header contains some additional information about the request, such as authorization information, etc.; and the request body contains specific data content. For example, when creating a new order, the request body may contain user information, product list, price and other data.

[0039] When the server receives the API request information, it processes it and returns the response information. The initial response information is the content directly returned by the server after processing the request without any additional processing, including the status code, response header and response body. Among them, the status code of the response information is a three-digit code used to indicate the processing result of the request. For example, 200 means the request is successful, 404 means the resource is not found, 500 means an internal server error, etc.; the response header contains some meta information about the response, such as Cache-Control is used to control the client's caching behavior, etc.; and the response body contains the actual data content returned by the server. If the request to query the order information is successful, the response body may contain detailed information about the order, such as the order number, order time, etc.

[0040] After obtaining the API request information of the normal function use case and the corresponding initial response information, users with different permissions are required to configure the corresponding login information. The automated testing method in the present invention can support unauthorized access vulnerability testing, vertical unauthorized vulnerability testing, and horizontal unauthorized vulnerability testing. Among them, the vertical unauthorized vulnerability testing requires pre-filling the login information of high- and low-authorized users, such as user name, password, etc. If there are multiple pairs of login information of high- and low-authorized users, the login information of multiple pairs of high- and low-authorized users needs to be filled in in sequence; while the horizontal unauthorized vulnerability requires pre-filling the login information of two users with the same permissions.

[0041] S20: Automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after the automatic login is successful.

[0042] After obtaining the API request information and the corresponding initial response information of the normal functional use case in step S10, and configuring the corresponding login information for users with different permissions, you can use the pre-configured login information of users with different permission levels to automatically perform the login operation through the program and submit a login request to the system. Once the login is successful, obtain the authentication information for accessing the API from the system feedback, such as tokens, session IDs, etc. These authentication information will be used for subsequent access to the API.

[0043] S30: Replace the original authentication information in the API request information of the normal function use case with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information.

[0044] After obtaining the authentication information of users with different permissions after successful automatic login in step S20, the original authentication information in the API request of the normal function use case previously obtained from the interface management platform can be deleted and replaced with the authentication information of the user with the corresponding permission obtained after successful automatic login, and the API request after the authentication information is replaced is resent to simulate the access of users with different permissions to the API. The present invention can preset replacement rules for authentication information in different scenarios, perform replacement operations on the obtained authentication information, and then resend the API request after the authentication information is modified, which can effectively ensure the integrity and accuracy of the API request information, and can simulate a variety of different authentication scenarios. Specifically, if Figure 3 As stated, Figure 3 yes Figure 2 A specific implementation flow diagram of step S40 in the embodiment of the present invention specifically includes the following steps S31-S33:

[0045] S31: If an unauthenticated access vulnerability is determined, the original authentication information in the API request of the normal functional use case is deleted, and the request information is resent to the API after the authentication information is deleted. In the present invention, if it is necessary to determine an unauthenticated access vulnerability, the authentication information in the original API request can be completely deleted to simulate a user who has not undergone any authentication to initiate a request. This scenario does not require authentication information, and only resends the API request information after deleting the authentication information. In the case of unauthenticated access, after sending the API request information, there will be a specific response to the unauthenticated access user, such as returning a prompt message that authentication is required or providing limited public resource access.

[0046] S32: If a vertical unauthorized access vulnerability is determined, the original authentication information in the API request information of the normal functional use case is replaced with the authentication information of the high-authorized user and the authentication information of the low-authorized user obtained after the automatic login is successful, and the API request information is resent after replacing the authentication information of the high-authorized user and the authentication information of the low-authorized user, respectively. In the present invention, a vertical unauthorized access vulnerability refers to a situation in which a low-authorized user can access the resources of a high-authorized user or a high-authorized user can access resources that a low-authorized user should not access. In this test scenario, the authentication information obtained after the automatic login is successful is replaced with the authentication information of the high-authorized user and the authentication information of the low-authorized user, respectively, and the API request information is resent after the high-authorized and low-authorized user authentication information is replaced to observe whether the API handles different permissions correctly. If there are multiple users with different permission levels in the system, the API request information is resent for each different permission combination to ensure the security of the system in terms of vertical permission management.

[0047] S33: If a horizontal privilege escalation vulnerability is determined, the original authentication information in the API request information of the normal functional use case is replaced with the authentication information of the user with the same authority obtained after the automatic login is successful, and the API request information is resent after replacing the authentication information of the user with the same authority. In the present invention, horizontal privilege escalation means that users of the same authority level can access resources that should not be accessed by each other. In this test scenario, the authentication identifier of the user with the same authority level can be used to replace the authentication information obtained after the automatic login is successful, so as to detect whether the system correctly restricts resource access between users with the same authority level. Resend the API request information after replacing the authentication information of the user with the same authority, and observe whether the API correctly processes the API request information of the user with the same authority to ensure that the horizontal privilege escalation vulnerability can be correctly tested.

[0048] S40: Preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules to determine whether the API of a normal functional use case has an unauthorized vulnerability. Specifically, Figure 4As stated, Figure 4 yes Figure 2 A specific implementation flow diagram of step S40 in the embodiment of the present invention specifically includes the following steps S41-S43:

[0049] S41: judging whether the API of the normal function use case has an unauthorized vulnerability according to whether the initial response information and the response information obtained after resending the API request are empty, and whether the response codes of the initial response information and the response information obtained after resending the API request are 200;

[0050] S42: If the initial response information and the response information obtained after resending the API request are empty, or the response code of the initial response information and the response information obtained after resending the API request is not 200, then the API of the normal function use case does not have an unauthorized vulnerability;

[0051] S43: If the response information obtained according to the initial response information and the response information obtained after resending the API request is not empty and the response code of the initial response information and the response information obtained after resending the API request is 200, then determine whether the API of the normal functional use case has an unauthorized vulnerability based on whether the initial response information and the response information obtained after resending the API request contain keywords.

[0052] In one embodiment of the present invention, it is possible to determine whether there is an unauthorized access vulnerability based on whether the response information is empty. If the initial response information is empty, it may mean that the request was not processed correctly or there is a problem with the API itself. When the response information obtained after resending the API request is empty, it may indicate that the request processing failed in the new authentication scenario. If the initial response information and the response information obtained after resending the API request are not empty, it is necessary to further analyze whether there is an unauthorized access vulnerability.

[0053] In addition, it is possible to determine whether there is an unauthorized access vulnerability based on whether the response code of the initial response information and the response information obtained after resending the API request is 200. In the API interface call, the status code of the response information is 200, indicating that the API has correctly processed the request and returned the expected result. If the initial response code is not 200 when a low-privileged user normally requests a resource, it means that the request was not successfully processed under normal permissions. However, if the response code becomes 200 after the authentication information is subsequently replaced and the request is resent, this may indicate an unauthorized access vulnerability, and further analysis is required to determine whether there is an unauthorized access vulnerability. If the response information obtained according to the initial response information and the response information obtained after resending the API request is not empty and the response code of the initial response information and the response information obtained after resending the API request is 200, it is possible to determine whether the API of the normal functional use case has an unauthorized access vulnerability based on whether the initial response information and the response information obtained after resending the API request contain keywords. Specifically, if Figure 5 As stated, Figure 5 yes Figure 4 A specific implementation flow diagram of step S43 in the embodiment of the present invention specifically includes the following steps S431-S432:

[0054] S431: If the initial response information and the response information obtained after resending the API request contain keywords, then the API of the normal functional use case does not have an unauthorized vulnerability;

[0055] S432: If the initial response information and the response information obtained after resending the API request do not contain keywords, determine whether the API of the normal functional use case has an unauthorized vulnerability based on whether the data types of the initial response information and the response information obtained after resending the API request are the same, and whether the difference in response body data length between the initial response information and the response information obtained after resending the API request is less than a preset length difference.

[0056] In one embodiment of the present invention, it is possible to determine whether the API of a normal functional use case has an unauthorized vulnerability based on whether the initial response information and the response information obtained after resending the API request contain keywords. In the present invention, the keywords "fail" and "block" can be used to determine whether the API of a normal functional use case has an unauthorized vulnerability, wherein the keyword "fail" is a keyword that should be returned when configuring an unauthorized test, such as: no permission, no permission, user not authorized, not authenticated, you do not have access rights, etc. When judging an API unauthorized vulnerability, if the initial response information and the response information obtained after resending the API request contain the "fail" keyword, it means that there is no unauthorized problem or login failure. The keyword "block" is a keyword that should be returned when the configuration API fails to execute due to environmental problems, such as: service interruption, system busy, unknown exception, system abnormality, please contact the administrator. When judging an API unauthorized vulnerability, if the initial response information and the response information obtained after resending the API request contain the "block" keyword, it means that the API function execution failed and it is necessary to locate the abnormal problem of the environment and re-execute. Therefore, when the initial response information and the response information obtained after resending the API request do not contain keywords, it is necessary to further analyze whether there is an unauthorized access vulnerability. The data types of the initial response information and the response information obtained after resending the API request are the same, and the length difference of the response body data between the initial response information and the response information obtained after resending the API request is less than the preset length difference, to determine whether there is an unauthorized access vulnerability in the API for normal functional use cases. Specifically, Figure 6 As stated, Figure 6 yes Figure 5A specific implementation flow diagram of step S432 in the embodiment of the present invention specifically includes the following steps S4321-S4322:

[0057] S4321: If the data types of the initial response information and the response information obtained after resending the API request are different, or the difference in the length of the response body data between the initial response information and the response information obtained after resending the API request is greater than or equal to the preset length difference, then the API of the normal function use case does not have an unauthorized vulnerability;

[0058] S4322: If the data types of the initial response information and the response information obtained after resending the API request are the same, and the length difference of the response body data in the response information is less than the preset length difference, then the API of the normal functional use case has an unauthorized vulnerability.

[0059] In one embodiment of the present invention, it is possible to determine whether the API of a normal functional use case has an unauthorized vulnerability based on whether the data types of the initial response information and the response information obtained after resending the API request are the same. If the data types of the initial response information and the response information obtained after resending the API request are different, there must be no unauthenticated access vulnerability or unauthorized vulnerability, because when users with different permissions request the same resource, the returned data type is different, and this difference is within the normal permission control logic. For example, when a low-privileged user requests a resource, a string is returned, while when a high-privileged user requests, an object containing detailed data is returned. This difference in data type is a normal result, not a manifestation of unauthorized access.

[0060] In addition, it is also possible to determine whether the API of the normal function use case has an unauthorized vulnerability based on whether the difference in length of the response body data between the initial response information and the response information obtained after resending the API request is less than the preset length difference. The present invention can calculate the difference in length of the response body data between the initial response information and the response information obtained after resending the API request. If this length difference is greater than or equal to the preset length difference, it is determined that the API of the normal function use case does not have an unauthorized vulnerability. Because when users with different permissions request the same resource, the amount of response body data should be quite different. If the data types of the initial response information and the response information obtained after resending the API request are the same, and the length difference of the response body data in the response information is less than the preset length difference, then the API of the normal function use case has an unauthorized vulnerability, and the API unauthorized vulnerability needs to be post-processed.

[0061] In the present invention, rules are preset to determine whether an API of a normal functional use case has an unauthorized vulnerability, and the initial response information and the response information obtained after resending the API request are analyzed according to the preset rules to determine whether the API of the normal functional use case has an unauthorized vulnerability. The judgment can be made specifically according to the actual test scenario. The automated testing method in the present invention can support unauthorized access vulnerability testing, vertical unauthorized vulnerability testing, and horizontal unauthorized vulnerability testing. The specific judgment method can be set according to the actual scenario. The judgment result has four states, namely, not involving relevant scenario testing, API has no vulnerability, API has suspected vulnerability, and API execution is blocked.

[0062] For testing of unauthorized access vulnerabilities, please refer to Figure 7 As stated, Figure 7 yes Figure 2The result judgment flow chart of the unauthorized access vulnerability in step S40 is shown in FIG. Response a is the initial response information after the API sends the request, and response b is the response information obtained after resending the API request. The first step is to determine whether the API of the normal function use case involves the test scenario of unauthenticated access vulnerability. If the API of the normal function use case does not involve the test scenario of unauthenticated access vulnerability, the judgment result is that it does not involve the relevant scenario test and the judgment ends; if the API of the normal function use case does have the test scenario of unauthenticated access vulnerability, the second step is to determine whether the response information obtained after resending the API request is empty. If it is empty, the judgment result is that the API execution is blocked and the judgment ends; if it is not empty, the third step is to determine whether the response information obtained after resending the API request contains the keyword "fail". If it contains the keyword "fail", the judgment result is that the API has no vulnerability and the judgment ends; if it does not contain the keyword "fail", the fourth step is to determine whether the response code of the initial response information is 200. If the response code of the initial response information is not 200, the judgment result is that the API execution is blocked and the judgment ends; if the response code of the initial response information is 200, the fifth step is to determine whether the response information obtained after resending the API request contains the keyword "fail". Whether the response code of the response information is 200. If the response code of the response information obtained after resending the API request is not 200, the judgment result is that the API has no vulnerability and the judgment ends; if the response information obtained after resending the API request is 200, the sixth step of judgment is performed to determine whether the initial response information or the response information obtained after resending the API request contains the keyword "block". If it contains the keyword "block", the judgment result is that the API execution is blocked and the judgment ends; if it does not contain the keyword "block", the seventh step of judgment is performed to determine whether the length difference of the response body data in the initial response information and the response information obtained after resending the API request is less than 20%. If the length difference is greater than or equal to 20%, the judgment result is that the API has no vulnerability and the judgment ends; if the length difference is less than 20%, the eighth step of judgment is performed to determine whether the data types of the initial response information and the response information obtained after resending the API request are the same. If they are not the same, the judgment result is that the API has no vulnerability. If they are the same, the judgment result is that the API has a suspected vulnerability and the judgment ends.

[0063] For testing vertical privilege escalation vulnerabilities, please refer to Figure 8 As stated, Figure 8 yes Figure 2The result judgment flow chart of the vertical privilege escaping vulnerability in step S40. Among them, response a is the response information of the high-privilege user after the API request is resent, and response b is the response information of the low-privilege user after the API request is resent. The first step is to determine whether the API of the normal function use case involves the test scenario of the vertical privilege escaping vulnerability. If the API of the normal function use case does not have a test scenario of the vertical privilege escaping vulnerability, the judgment result is that it does not involve the relevant scenario test, and the judgment ends; if the API of the normal function use case has a test scenario of the unauthenticated access vulnerability, the second step is to determine whether the response information of the high-privilege user and the low-privilege user after the API request is resent is empty. If it is empty, the judgment result is that the API execution is blocked, and the judgment ends; if it is not empty, the third step is to determine whether the response code of the response information of the high-privilege user after the API request is resent is 20. 0. If the response code of the high-privileged user's response information after resending the API request is not 200, then determine whether the high-privileged user has permission based on the marked information. If so, the result is that the API execution is blocked. If not, the result is that the API has no vulnerability and the determination ends. If the response code of the high-privileged user's response information after resending the API request is 200, proceed to the fourth step to determine whether the response information of the high-privileged user after resending the API request contains the keyword "fail". If it contains the keyword "fail", the result is that the API execution is blocked and the determination ends. If it does not contain the keyword "fail", the result is that the API execution is blocked and the determination ends. If the keyword "fail" is found, the fifth step is performed to determine whether the response information of the low-privilege user after resending the API request contains the keyword "fail". If the keyword "fail" is found, the result is that the API has no vulnerability and the determination is terminated. If the keyword "fail" is not found, the sixth step is performed to determine whether the response information of the high-privilege user after resending the API request contains the keyword "block". If the keyword "block" is found, the result is that the API is blocked and the determination is terminated. If the keyword "block" is not found, the seventh step is performed to determine whether the high-privilege user has the permission according to the marking information. If the user has the permission, the result is that the API has no vulnerability and the determination is terminated. If the user has no permission, the eighth step is performed to determine whether the data types of the response information of the high-privilege user after resending the API request are the same. If they are not the same, the result is that the API has no vulnerability. If they are the same, the ninth step is performed to determine whether the length difference of the response body data in the response information of the high-privilege user after resending the API request is less than 20%. If the length difference is greater than or equal to 20%, the result is that the API has no vulnerability and the determination is terminated. If the length difference is less than 20%, the result is that the API has a suspected vulnerability and the determination is terminated.

[0064] For testing of horizontal privilege escalation vulnerabilities, please refer to Fig. 9 As stated, Fig. 9yes Figure 2 Result judgment flow chart of horizontal privilege escaping vulnerability in step S40. Response a is the response information of the user with the same privilege a after resending the API request, and response b is the response information of the user with the same privilege b after resending the API request. The first step is to determine whether the API of the normal function use case involves a test scenario for a horizontal privilege escaping vulnerability. If the API of the normal function use case does not involve a test scenario for a horizontal privilege escaping vulnerability, the judgment result is that it does not involve relevant scenario testing and the judgment ends. If the API of the normal function use case has a test scenario for an unauthenticated access vulnerability, the second step is to determine whether the response information of the user with the same privilege after resending the API request is empty. If it is empty, the judgment result is that the API execution is blocked and the judgment ends. If it is not empty, the third step is to determine whether the response code of the response information of the user with the same privilege after resending the API request is 200. If the response code of the response information of the user with the same privilege after resending the API request is not 200, determine whether the user with the same privilege has permission based on the marking information. If so, the judgment result is that the API execution is blocked. If not, the judgment result is that the API has no vulnerability and the judgment ends. If the response code of the response information of the user with the same privilege after resending the API request is 200, the fourth step is to determine. The first step is to determine whether the response information of the same-authority user after resending the API request contains the keyword "fail". If it contains the keyword "fail", the judgment result is that the API has no vulnerability and the judgment ends. If it does not contain the keyword "fail", the fifth step is to determine whether the response information of the same-authority user after resending the API request contains the keyword "block". If it contains the keyword "block", the judgment result is that the API execution is blocked and the judgment ends. If it does not contain the keyword "block", the sixth step is to determine whether the data type of the response information of the same-authority user after resending the API request is the same. If not, the judgment result is that the API has no vulnerability. If they are the same, the seventh step is to determine whether the length difference of the response body data in the response information of the same-authority user after resending the API request is less than 20%. If the length difference is greater than or equal to 20%, the judgment result is that the API has no vulnerability and the judgment ends. If the length difference is less than 20%, the judgment result is that the API has a suspected vulnerability and the judgment ends.

[0065] S50: Generate a scan report based on the judgment result of whether the API of the normal functional use case has an unauthorized access vulnerability, and perform post-processing of the API unauthorized access vulnerability based on the generated scan report.

[0066] After the above step S40 determines whether the API of the normal function use case has an unauthorized vulnerability, a scan report can be generated based on the judgment result of whether the API of the normal function use case has an unauthorized vulnerability, and the API unauthorized vulnerability can be post-processed according to the generated scan report. Specifically, in the present invention, if it is confirmed that the API of the normal function use case has an unauthorized vulnerability, a problem sheet will be automatically generated for the existing API unauthorized vulnerability; if it is confirmed that the API of the normal function use case does not have an unauthorized vulnerability, the API of the normal function use case will be marked. Specifically, in the present invention, if it is determined that the API of the normal function use case has an unauthorized vulnerability, the system will automatically create a problem sheet, which is a record document of the API vulnerability situation, and usually contains detailed information, such as the name, URL, request method and other basic information of the API involving the vulnerability, so as to accurately identify which API has a problem. If it is determined that the API of the normal function use case does not have an unauthorized vulnerability after judgment, then this API will be marked to assist the subsequent process: for example, in the security detection process of the entire system, this mark can be used as an intermediate result to facilitate the subsequent processing decision of the API or related modules.

[0067] In one embodiment of the present invention, before the automatic login according to the configured user's login dependency information is performed in step S30, it also includes: marking the API access permission level of the obtained normal functional use case according to the preset scanning strategy, and filtering the API that does not involve API vulnerability testing according to the marking result. Specifically, some APIs are public and can be accessed without authorization. Such APIs do not involve unauthorized testing; some APIs are authorized to all users, and these APIs do not involve testing of vertical and horizontal unauthorized vulnerabilities. These APIs that do not involve testing can be manually marked as not involving unauthorized testing or unauthorized testing, and these APIs will be automatically filtered out during automated testing. Through this filtering, it is possible to avoid wasting time and resources on unnecessary API testing, while ensuring a more in-depth inspection of the security status of important APIs.

[0068] It can be seen that in the above scheme, for the automated testing of unauthorized access vulnerabilities, the original authentication information in the API request information of the normal functional use case is replaced with the authentication information of the user with different permissions obtained after the automatic login is successful, and the API request information is resent after replacing the authentication information. The initial response information and the response information obtained after the API request is resent are analyzed according to the preset rules to determine whether the API of the normal functional use case has an unauthorized access vulnerability, thereby effectively improving the testing efficiency of the unauthorized access vulnerability.

[0069] It should be understood that the order of execution of the steps in the above embodiment does not necessarily mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present invention.

[0070] In one embodiment, an automated testing device for unauthorized vulnerabilities is provided, and the automated testing device for unauthorized vulnerabilities corresponds one-to-one to the automated testing method for unauthorized vulnerabilities in the above-mentioned embodiment. Fig.10 As shown, Fig.10 1 is a schematic diagram of a structure of an automated testing device for unauthorized vulnerabilities in one embodiment of the present invention, the automated testing device for unauthorized vulnerabilities comprises an acquisition module 101, a login module 102, a replacement module 103, an analysis module 104 and a processing module 105. The functional modules are described in detail as follows:

[0071] The acquisition module 101 is used to obtain the API request information of the normal function use case and the corresponding initial response information, and configure the corresponding login information for users with different permissions;

[0072] The login module 102 is used to automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after the automatic login is successful;

[0073] A replacement module 103 is used to replace the original authentication information in the API request information of the normal function use case obtained with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information;

[0074] The analysis module 104 is used to preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules;

[0075] The processing module 105 is used to generate a scan report based on the analysis results of the initial response information and the response information obtained after the API request is resent, and perform post-processing of the API unauthorized vulnerability according to the generated scan report.

[0076] In one embodiment, the replacement module 103 is specifically configured to:

[0077] If an unauthenticated access vulnerability is identified, the original authentication information in the API request of the normal function use case will be deleted, and the request information will be resent to the API after the authentication information is deleted;

[0078] If a vertical privilege escalation vulnerability is identified, the original authentication information in the API request information of the normal function use case is replaced with the authentication information of the high-privilege user and the low-privilege user obtained after successful automatic login, and the API request information is resent after replacing the authentication information of the high-privilege user and the low-privilege user respectively;

[0079] If a horizontal privilege escalation vulnerability is identified, the original authentication information in the API request information of the normal functional use case will be replaced with the authentication information of the user with the same privilege obtained after successful manual login, and the API request information will be resent after replacing the authentication information of the user with the same privilege.

[0080] In one embodiment, the analysis module 104 is specifically configured to:

[0081] Determine whether the API of the normal function use case has an unauthorized vulnerability based on whether the initial response information and the response information obtained after resending the API request are empty, and whether the response code of the initial response information and the response information obtained after resending the API request is 200;

[0082] If the initial response information and the response information obtained after resending the API request are empty, or the response code of the initial response information and the response information obtained after resending the API request is not 200, then the API of the normal functional use case does not have an unauthorized vulnerability;

[0083] If the response information obtained according to the initial response information and the response information obtained after resending the API request is not empty and the response code of the initial response information and the response information obtained after resending the API request is 200, then determine whether the API of the normal functional use case has an unauthorized vulnerability based on whether the initial response information and the response information obtained after resending the API request contain keywords.

[0084] In one embodiment, the analysis module 104 is specifically configured to:

[0085] If the initial response information and the response information obtained after resending the API request contain keywords, then the API of the normal functional use case does not have an unauthorized vulnerability;

[0086] If the initial response information and the response information obtained after resending the API request do not contain keywords, then determine whether the API of the normal functional use case has an unauthorized access vulnerability based on whether the data types of the initial response information and the response information obtained after resending the API request are the same, and whether the difference in response body data length between the initial response information and the response information obtained after resending the API request is less than a preset length difference.

[0087] In one embodiment, the analysis module 104 is specifically configured to:

[0088] If the data types of the initial response information and the response information obtained after resending the API request are different, or the difference in the length of the response body data between the initial response information and the response information obtained after resending the API request is greater than or equal to the preset length difference, then the API of the normal functional use case does not have an unauthorized vulnerability;

[0089] If the data types of the initial response information and the response information obtained after resending the API request are the same, and the length difference of the response body data in the response information is less than the preset length difference, then the API of the normal functional use case has an unauthorized vulnerability.

[0090] In one embodiment, the processing module 105 is specifically configured to:

[0091] The method generates a scan report based on the judgment result of whether the API of the normal function use case has an unauthorized access vulnerability, and performs post-processing of the API unauthorized access vulnerability based on the generated scan report, including:

[0092] If it is confirmed that the API of a normal functional use case has an unauthorized vulnerability, a problem ticket will be automatically generated for the existing API unauthorized vulnerability;

[0093] If it is confirmed that the API of the normal functional use case does not have an unauthorized vulnerability, the API of the normal functional use case will be marked.

[0094] In one embodiment, the automated testing device for unauthorized vulnerabilities is further used to:

[0095] The API access permission levels of the obtained normal functional use cases are marked according to the preset scanning strategy, and the APIs not involved in API vulnerability testing are filtered according to the marking results.

[0096] The present invention provides an automated testing device for unauthorized vulnerabilities. For the automated testing of unauthorized vulnerabilities, the device replaces original authentication information in API request information of a normal functional use case with authentication information of a user with different permissions obtained after successful automatic login, resends the API request information after replacing the authentication information, and analyzes the initial response information and the response information obtained after resending the API request according to preset rules to determine whether the API of the normal functional use case has an unauthorized vulnerability, thereby effectively improving the testing efficiency of the unauthorized vulnerability.

[0097] For the specific definition of the automated testing device for unauthorized vulnerabilities, please refer to the definition of the automated testing method for unauthorized vulnerabilities mentioned above, which will not be repeated here. Each module in the above-mentioned automated testing device for unauthorized vulnerabilities can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0098] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.11 As shown, Fig.11 It is a structural diagram of a computer device in one embodiment of the present invention. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the server side of an automated testing method for unauthorized vulnerabilities.

[0099] In one embodiment, a computer device is provided. The computer device may be a client, and its internal structure diagram may be as follows: Fig.12 As shown, Fig.12 1 is another structural diagram of a computer device in one embodiment of the present invention. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, the functions or steps on the client side of an automated testing method for unauthorized vulnerabilities are implemented.

[0100] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0101] Obtain API request information and corresponding initial response information for normal functional use cases, and configure corresponding login information for users with different permissions;

[0102] Automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after successful automatic login;

[0103] Replace the original authentication information in the API request information of the normal function use case with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information;

[0104] Preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules to determine whether the API of a normal functional use case has an unauthorized vulnerability;

[0105] A scan report is generated based on the judgment result of whether the API of the normal functional use case has an unauthorized access vulnerability, and post-processing of the API unauthorized access vulnerability is performed based on the generated scan report.

[0106] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0107] Obtain API request information and corresponding initial response information for normal functional use cases, and configure corresponding login information for users with different permissions;

[0108] Automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after successful automatic login;

[0109] Replace the original authentication information in the API request information of the normal function use case with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information;

[0110] Preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules to determine whether the API of a normal functional use case has an unauthorized vulnerability;

[0111] A scan report is generated based on the judgment result of whether the API of the normal functional use case has an unauthorized access vulnerability, and post-processing of the API unauthorized access vulnerability is performed based on the generated scan report.

[0112] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0113] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0114] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0115] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. An automated testing method for unauthorized vulnerabilities, characterized in that: include: Obtain API request information and corresponding initial response information for normal functional use cases, and configure corresponding login information for users with different permissions; Automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after successful automatic login; Replace the original authentication information in the API request information of the normal function use case with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information; Preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules to determine whether the API of a normal functional use case has an unauthorized vulnerability; A scan report is generated based on the judgment result of whether the API of the normal functional use case has an unauthorized access vulnerability, and post-processing of the API unauthorized access vulnerability is performed based on the generated scan report.

2. The automated testing method for unauthorized vulnerabilities according to claim 1, characterized in that: The method of replacing the original authentication information in the API request information of the normal function use case with the authentication information of the user with different permissions obtained after the automatic login is successful, and resending the API request information after replacing the authentication information, includes: If an unauthenticated access vulnerability is identified, the original authentication information in the API request of the normal function use case will be deleted, and the request information will be resent to the API after the authentication information is deleted; If a vertical privilege escalation vulnerability is identified, the original authentication information in the API request information of the normal function use case is replaced with the authentication information of the high-privilege user and the low-privilege user obtained after successful automatic login, and the API request information is resent after replacing the authentication information of the high-privilege user and the low-privilege user respectively; If a horizontal privilege escalation vulnerability is identified, the original authentication information in the API request information of the normal functional use case will be replaced with the authentication information of the user with the same privilege obtained after successful manual login, and the API request information will be resent after replacing the authentication information of the user with the same privilege.

3. The automated testing method for unauthorized vulnerabilities according to claim 2, characterized in that: The preset rules for determining whether the API of the normal function use case has an unauthorized vulnerability, and analyzing the initial response information and the response information obtained after resending the API request according to the preset rules to determine whether the API of the normal function use case has an unauthorized vulnerability, include: Determine whether the API of the normal function use case has an unauthorized vulnerability based on whether the initial response information and the response information obtained after resending the API request are empty, and whether the response code of the initial response information and the response information obtained after resending the API request is 200; If the initial response information and the response information obtained after resending the API request are empty, or the response code of the initial response information and the response information obtained after resending the API request is not 200, then the API of the normal functional use case does not have an unauthorized vulnerability; If the response information obtained according to the initial response information and the response information obtained after resending the API request is not empty and the response code of the initial response information and the response information obtained after resending the API request is 200, then determine whether the API of the normal functional use case has an unauthorized vulnerability based on whether the initial response information and the response information obtained after resending the API request contain keywords.

4. The automated testing method for unauthorized vulnerabilities according to claim 3, characterized in that: The step of judging whether the API has an unauthorized vulnerability based on whether the initial response information and the response information obtained after resending the API request contain keywords includes: If the initial response information and the response information obtained after resending the API request contain keywords, then the API of the normal functional use case does not have an unauthorized vulnerability; If the initial response information and the response information obtained after resending the API request do not contain keywords, then determine whether the API of the normal functional use case has an unauthorized access vulnerability based on whether the data types of the initial response information and the response information obtained after resending the API request are the same, and whether the difference in response body data length between the initial response information and the response information obtained after resending the API request is less than a preset length difference.

5. The automated testing method for unauthorized vulnerabilities according to claim 4, characterized in that: The determining whether there is an unauthorized vulnerability in the API of the normal functional use case according to whether the data types of the initial response information and the response information obtained after resending the API request are the same, and whether the difference in the length of the response body data between the initial response information and the response information obtained after resending the API request is less than a preset length difference, includes: If the data types of the initial response information and the response information obtained after resending the API request are different, or the difference in the length of the response body data between the initial response information and the response information obtained after resending the API request is greater than or equal to the preset length difference, then the API of the normal functional use case does not have an unauthorized vulnerability; If the data types of the initial response information and the response information obtained after resending the API request are the same, and the length difference of the response body data in the response information is less than the preset length difference, then the API of the normal functional use case has an unauthorized vulnerability.

6. The automated testing method for unauthorized vulnerabilities according to claim 5, characterized in that: The method generates a scan report based on the judgment result of whether the API of the normal function use case has an unauthorized access vulnerability, and performs post-processing of the API unauthorized access vulnerability based on the generated scan report, including: If it is confirmed that the API of a normal functional use case has an unauthorized vulnerability, a problem ticket will be automatically generated for the existing API unauthorized vulnerability; If it is confirmed that the API of the normal functional use case does not have an unauthorized vulnerability, the API of the normal functional use case will be marked.

7. The automated testing method for unauthorized vulnerabilities according to claim 6, characterized in that: Before the automatic login is performed according to the configured user login dependency information, the method further includes: The API access permission levels of the obtained normal functional use cases are marked according to the preset scanning strategy, and the APIs not involved in API vulnerability testing are filtered according to the marking results.

8. An automated testing device for an unauthorized vulnerability, the device being used to implement the automated testing method for an unauthorized vulnerability as claimed in any one of claims 1 to 7, characterized in that: include: The acquisition module obtains the API request information and the corresponding initial response information of the normal functional use case, and configures the corresponding login information for users with different permissions; The login module is used to automatically log in according to the configured login information of users with different permissions, and obtain the authentication information of users with different permissions after successful automatic login; A replacement module is used to replace the original authentication information in the API request information of the normal function use case obtained with the authentication information of the user with different permissions obtained after the automatic login is successful, and resend the API request information after replacing the authentication information; The analysis module is used to preset rules for determining whether the API of a normal functional use case has an unauthorized vulnerability, and analyze the initial response information and the response information obtained after resending the API request according to the preset rules; The processing module is used to generate a scan report based on the analysis results of the initial response information and the response information obtained after resending the API request, and perform post-processing of the API unauthorized vulnerability based on the generated scan report.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the automated testing method for unauthorized vulnerability as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the automated testing method for unauthorized vulnerability as described in any one of claims 1 to 7 are implemented.

Images