Interface security authentication test method

Abstract

The application relates to an interface security authentication test method and belongs to the technical field of interface security test. In the method, test dimensions include user identity authentication verification and object level authorization verification. First, whether the interface authenticates the user identity is judged according to whether a token is valid to request a service end; second, on the basis that the token is valid, whether the power of a request account exists overstepping is judged, and authorization verification is mainly divided into system power verification and user power verification; and finally, a visual test report is generated. The method tests the interface from the perspective of security authentication test, supports two interface security authentication test scenes of user identity authentication and object level authorization, tests the interface from the perspective of security authentication test, increases the interface test dimensions, and improves the test coverage.

Description

Technical Field

[0001] This invention belongs to the field of interface security testing technology, and specifically relates to an interface security authentication testing method. Background Technology

[0002] Most current application systems adopt a front-end / back-end separation design pattern. Whether it's web application interfaces or app application interfaces, they largely use a RESTful architecture. A key design principle of RESTful is that client requests to the server are stateless, and each request uses a token for authentication. To emphasize the importance of API security, OWASP first proposed the "API Security Top 10" in 2019, which includes invalid object-level authorization and invalid user authentication as dimensions of API security authentication. Invalid user authentication mainly refers to the lack of authentication of the requesting party or the failure to verify the validity of the token during API requests. Invalid object-level authorization refers to lax permission restrictions on the requesting account, leading to unauthorized data access. However, current API testing mainly focuses on input parameter testing, including some general validations and validation of the business attributes of the API, lacking testing methods for API security authentication verification and neglecting the importance of API security authentication testing. Summary of the Invention

[0003] (a) Technical problems to be solved

[0004] The technical problem to be solved by this invention is: how to design a testing method for interface security authentication, to test the interface from the perspective of security authentication testing, to increase the dimensions of interface testing, and to improve test coverage.

[0005] (II) Technical Solution

[0006] To address the aforementioned technical problems, this invention provides an interface security authentication testing method, comprising the following steps:

[0007] Step 1: Test Data Reading

[0008] The interface request consists of two parts: input parameters and request headers. The test data is pre-maintained in a YAML file, and when the test cases of the corresponding interface are executed, the test data in the YAML file is directly read as the input parameters.

[0009] Step Two: User Identity Verification

[0010] Consider three scenarios: an empty token, an expired token, and a valid token. When requesting with a valid token, including the token will successfully retrieve the API response. When using an expired or empty token, the expected result is "no access permission". For empty or expired tokens, simply pass an empty or expired token when calling the API. The API response will determine whether to authenticate the user's identity. If a valid token is passed, check if the status code is 200 (successful request). If an expired or empty token is passed, check if the status code is 401 (no access permission). For valid token verification, define a public method to retrieve the token based on the account information. Then, pass the token return value to the request header of the test case. Use the test data from step one and a request header containing the valid token value to request the API and determine if the request was successful.

[0011] Step 3: Object-level authorization verification

[0012] Authorization verification is divided into two categories: system permission authorization verification and user permission authorization verification. On the one hand, application systems have multiple system roles, each with different operation permissions, which may result in permission overlap or permission isolation. Authorization verification in scenarios where different system roles have isolated permissions is categorized as system permission authorization verification. On the other hand, for the same interface, different users may have operation permissions for the corresponding interface, but different users may only have operation permissions for data within their own department. Therefore, this interface also has permissions with data isolation attributes. Authorization verification in scenarios where different users have data isolation is categorized as user permission authorization verification.

[0013] For system permission authorization verification, before interface security testing, the system permissions of the interface should be clearly defined. The system roles with permissions should be passed as input parameters to the test case. If it is a normal test case, the database query interface should be called according to the system role parameter passed to the interface to obtain the account information of the corresponding system role. Then, the public method for obtaining the token should be called according to the account information. The returned token should be passed to the request header of the test case. The test data from step one and the request header containing a valid token value should be used to request the interface to determine whether the interface request is successful. If it is an abnormal test case, the logic should be used to determine the system role that does not currently have this permission. After obtaining the account information of the account that does not have permission, a token should be generated and passed to the request header. At this time, the interface should prompt that there is currently no access permission.

[0014] For user permission authorization verification, considering data isolation factors, users A and B both have permissions for the same interface, but different users can only access data within their own department and do not support cross-department access. When designing test cases, first clarify the department permissions of the data to be operated on, then use logic to determine the department without such operation permissions, obtain the account information of the department without permissions by calling the database query interface, call the public method to obtain the token based on the account information, pass the returned token to the request header of the test case, use the test data obtained in step one and the interface containing the token value, and determine whether user permissions are currently isolated based on the returned information.

[0015] Step 4: Generate a test report

[0016] Using Jenkins continuous integration, separate projects are created on the Jenkins platform for API security test types. User authentication verification and object-level authorization verification API security test cases are tagged separately, and execution scripts are configured according to tag rules. After the two types of API security test cases are executed, a visual test report is generated using the Allure plugin.

[0017] Preferably, in step one, for the preset key input parameters in the test data, data that meets the conditions is obtained from the database to replace some of the pre-maintained parameters.

[0018] Preferably, user authentication, or token authentication, is a process where the server verifies the user's identity and determines whether the user has access permissions.

[0019] Preferably, step two is to verify the validity of the token, and determine whether to authenticate the user's identity from the perspective of token validity.

[0020] Preferably, step three involves verifying, based on the validity of the token, whether the requesting account has exceeded its authority.

[0021] Preferably, the system roles of the application system include super administrator, administrator, security auditor, and operator.

[0022] Preferably, step four is followed by the step of: viewing the test case execution results.

[0023] The present invention also provides a system for implementing the method.

[0024] The present invention also provides an application system designed based on the method described above.

[0025] The present invention provides a method for operating the system described herein.

[0026] (III) Beneficial Effects

[0027] This invention proposes a testing method for interface security authentication, with testing dimensions including user identity authentication verification and object-level authorization verification. First, it requests the server based on the validity of the token to determine if the interface authenticates the user. Second, assuming the token is valid, it checks whether the requesting account has exceeded its permissions; authorization verification is mainly divided into system permission verification and user permission verification. Finally, a visual test report is generated. This method tests the interface from a security authentication testing perspective, supporting both user identity authentication and object-level authorization testing scenarios. By testing the interface from a security authentication perspective, it increases the testing dimensions and improves test coverage. Attached Figure Description

[0028] Figure 1 This is a flowchart of the interface security authentication test for the present invention;

[0029] Figure 2 This is a schematic diagram of the interface security authentication test principle of the present invention. Detailed Implementation

[0030] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0031] This invention proposes a method for interface security testing to address two interface security authentication scenarios: invalid user identity authentication verification and invalid object-level authorization. The interface security authentication testing process is as follows: Figure 1 As shown, user authentication primarily verifies the validity of the token; object-level authorization verification mainly verifies account permissions, requiring the generation of a valid token based on the account with the corresponding permissions before requesting the interface. Therefore, both are implemented based on changes in the request header. Figure 1 As shown, the method includes the following steps:

[0032] Step 1: Test Data Reading. The interface security testing method proposed in this invention focuses on authentication testing of user identity and user account permissions; the interface input parameters only need to consider normal request parameters. For example... Figure 1 As shown, an interface request mainly consists of two parts: interface input parameters and request headers. For interface security testing, test data is not the main content of the test; it is only necessary to ensure that the parameters are passed correctly. This method pre-maintains the test data in a YAML file. When executing the test cases for the corresponding interface, the test data in the YAML file can be directly read as the input parameters. At the same time, to avoid test data duplication and redundancy, for some key input parameters in the test data (interface request parameters), the data reading module can retrieve data that meets the conditions from the database to replace some of the pre-maintained parameters, ensuring the timeliness of the test data and reducing redundancy.

[0033] Step Two: User Authentication Verification (Verifying if there are any bugs in the user authentication process). Normally, to ensure the security of API requests, a token is included in the request so the server can verify the requester's identity. User authentication (token authentication) is the server's way of verifying a user's identity and determining whether the user has the necessary permissions. This test scenario primarily verifies the validity of the token (determining whether user authentication is required from the perspective of token validity), such as... Figure 2 As shown, this method considers three scenarios: an empty request header token, an expired token, and a valid token. When making a request with a valid token, including the token will successfully retrieve the interface's return information. When using an expired token or an empty token, the expected result is an "access denied" message. Specifically, for empty or expired tokens, simply passing an empty or expired token when calling the interface is sufficient. The interface's return result determines whether user authentication is required. Passing a valid token verifies the status code to 200, indicating a successful request; passing an expired or empty token verifies the status code to 401, indicating no access permission. For valid token verification, this invention defines a dedicated method for obtaining the token in the public method module. This method retrieves the corresponding token based on the account information and passes the token return value to the request header of the test case. Using the test data from step one and a request header containing the valid token value, the interface is then requested to determine if the request was successful.

[0034] Step 3: Object-Level Authorization Verification. This authorization verification, based on a valid token (after user authentication), verifies whether the requesting account has exceeded its authority. This method divides authorization verification into two categories: system permission authorization verification and user permission authorization verification. For this test scenario, the first requirement is to ensure token validity. On one hand, application systems typically have many roles, including super administrators, administrators, security auditors, operators, etc. Each role has different operating permissions, which may involve permission overlap (e.g., a super administrator has all permissions of other roles) or permission isolation (e.g., security auditors and operators have different permissions). Authorization verification in scenarios where different roles in the application system have isolated permissions can be classified as system permission verification. On the other hand, for the same interface, different users may have operating permissions for that interface, but different users only have operating permissions for data within their own department. Therefore, this interface also has data isolation attributes. Authorization verification in scenarios where different users have data isolation can be classified as user permission verification.

[0035] For system permission authorization verification, before interface security testing, the system permissions of the interface should be clearly defined. The system roles with permissions should be passed as input parameters to the test case. If it is a normal test case, the database query interface should be called according to the role parameter passed to the interface to obtain the account information of the corresponding role. Then, the public method for obtaining the token should be called according to the account information. The returned token should be passed to the request header of the test case. The test data from step one and the request header containing a valid token value should be used to request the interface to determine whether the interface request is successful. If it is an abnormal test case, the system role that does not currently have this permission should be obtained through logical judgment. After obtaining the account information of the person who does not have permission, a token should be generated and passed to the request header. At this time, the interface should prompt that there is currently no access permission.

[0036] For user permission authorization verification, this method primarily considers data isolation. Users A and B both have permissions for the same interface, but different users can only access data within their own department and cross-departmental access is not supported. When designing test cases, first, the department permissions for the data to be operated on are clearly defined. Then, logical judgment is used to identify departments without the necessary permissions. Account information for these departments is obtained by calling a database query interface. Based on this account information, a public method for obtaining a token is called. The returned token is passed to the request header of the test case. Using the test data obtained in step one and the interface containing this token value, the returned information is used to determine whether user permission isolation is currently in place.

[0037] Step 4: Generate Test Reports. This invention utilizes Jenkins continuous integration, creating separate projects for API security test types on the Jenkins platform. Test cases for user authentication and object-level authorization are individually tagged, and execution scripts are configured according to tag rules. After the execution of these two types of API security test cases, a visual test report is generated using the Allure plugin, allowing users to view the test case execution results.

[0038] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An interface security authentication testing method, characterized in that, Includes the following steps: Step 1: Test Data Reading The interface request consists of two parts: input parameters and request headers. The test data is pre-maintained in a YAML file, and when the test cases of the corresponding interface are executed, the test data in the YAML file is directly read as the input parameters. Step Two: User Identity Verification Consider three scenarios: an empty token, an expired token, and a valid token. When requesting with a valid token, including the token will successfully retrieve the API response. When using an expired or empty token, the expected result is "no access permission". For empty or expired tokens, simply pass an empty or expired token when calling the API. The API response will determine whether to authenticate the user's identity. If a valid token is passed, check if the status code is 200 (successful request). If an expired or empty token is passed, check if the status code is 401 (no access permission). For valid token verification, define a public method to retrieve the token based on the account information. Then, pass the token return value to the request header of the test case. Use the test data from step one and a request header containing the valid token value to request the API and determine if the request was successful. Step 3: Object-level authorization verification Authorization verification is divided into two categories: system permission authorization verification and user permission authorization verification. On the one hand, application systems have multiple system roles, each with different operation permissions, which may result in permission overlap or permission isolation. Authorization verification in scenarios where different system roles have isolated permissions is categorized as system permission authorization verification. On the other hand, for the same interface, different users may have operation permissions for the corresponding interface, but different users may only have operation permissions for data within their own department. Therefore, this interface also has permissions with data isolation attributes. Authorization verification in scenarios where different users have data isolation is categorized as user permission authorization verification. For system permission authorization verification, before interface security testing, the system permissions of the interface should be clearly defined. The system roles with permissions should be passed as input parameters to the test case. If it is a normal test case, the database query interface should be called according to the system role parameter passed to the interface to obtain the account information of the corresponding system role. Then, the public method for obtaining the token should be called according to the account information. The returned token should be passed to the request header of the test case. The test data from step one and the request header containing a valid token value should be used to request the interface to determine whether the interface request is successful. If it is an abnormal test case, the logic should be used to determine the system role that does not currently have this permission. After obtaining the account information of the account that does not have permission, a token should be generated and passed to the request header. At this time, the interface should prompt that there is currently no access permission. For user permission authorization verification, considering data isolation factors, users A and B both have permissions for the same interface, but different users can only access data within their own department and do not support cross-department access. When designing test cases, first clarify the department permissions of the data to be operated on, then use logic to determine the department without such operation permissions, obtain the account information of the department without permissions by calling the database query interface, call the public method to obtain the token based on the account information, pass the returned token to the request header of the test case, use the test data obtained in step one and the interface containing the token value, and determine whether user permissions are currently isolated based on the returned information. Step 4: Generate a test report Using Jenkins continuous integration, separate projects are created on the Jenkins platform for API security test types. User authentication verification and object-level authorization verification API security test cases are tagged separately, and execution scripts are configured according to tag rules. After the two types of API security test cases are executed, a visual test report is generated using the Allure plugin.

2. The method as described in claim 1, characterized in that, In step one, for the preset key input parameters in the test data, data that meets the conditions is retrieved from the database to replace some of the pre-maintained parameters.

3. The method as described in claim 1, characterized in that, User authentication, also known as token authentication, is a process where the server verifies a user's identity and determines whether the user has access permissions.

4. The method as described in claim 1, characterized in that, Step two is to verify the validity of the token, and determine whether to authenticate the user's identity from the perspective of token validity.

5. The method as described in claim 1, characterized in that, Step three, based on the validity of the token, verifies whether the requesting account has exceeded its authority.

6. The method as described in claim 1, characterized in that, The system roles in the application system include super administrator, administrator, security auditor, and operator.

7. The method as described in claim 1, characterized in that, Step four is followed by the step of viewing the test case execution results.

8. A system for implementing the method as described in any one of claims 1 to 7.

9. An application system designed based on the method described in any one of claims 1 to 7.

10. A method of operating the system as described in claim 9.

Images