Method and system for non-intrusively solving unauthorized security vulnerabilities

Abstract

The invention relates to the technical field of security vulnerability solving, and provides a non-intrusive unauthorized security vulnerability solving method, which comprises the following steps: S1, designing a self-defined unauthorized security vulnerability detection tool, defining a set of service provider interface SPI in the unauthorized security vulnerability detection tool, and integrating with a service system through the service provider interface SPI to obtain an unauthorized security vulnerability detection result; realizing permission judgment of the service system; s2, marking a bean object of the front-end interface which needs to be subjected to permission judgment in the service system by using a (at) Controller or (at) RestController annotation, and meanwhile, adding user permission checking logic to a method in which tool annotation is used in the bean object by adopting a Spring AOP technology by the unauthorized security vulnerability detection tool, when permission judgment needs to be carried out, calling is carried out through the SPI of the service provider interface. According to the technical scheme, a user-defined tool is adopted, a group of authority annotations are defined, and the tool automatically scans all classes and methods with the annotations in the business codes and executes authority checking.

Description

Technical Field

[0001] The present invention relates to the technical field of security vulnerability solutions, and in particular to a method and system for non-invasively solving unauthorized security vulnerabilities. Background Art

[0002] In enterprise applications, the management of user permissions is crucial. Enterprise applications usually involve complex user groups, some of which come from different departments within the enterprise, with different positions and responsibilities, and some come from outside the enterprise, such as various partners, facing different businesses. Therefore, strict management of user permissions is the basis for ensuring enterprise data security and normal business operation. The permission system of enterprise applications is often highly complex, covering multiple levels of permission control, including functional module permissions, data permissions, field permissions, etc.

[0003] However, a serious problem currently faced is that permission check codes are often scattered in various corners of the application. Therefore, permission check logic is difficult to centrally manage and maintain. Since the permission system is closely related to the business of the enterprise, as the business of the enterprise continues to develop and change, the corresponding permission content and structure will also be adjusted accordingly, and the permission check codes scattered everywhere will bring great challenges to maintenance work. When developers are upgrading the system, expanding functions or fixing vulnerabilities, they need to find and modify the permission check logic in numerous code fragments, which is not only time-consuming and labor-intensive, but also prone to omissions and errors. Once an omission occurs, a serious unauthorized security vulnerability will occur.

[0004] Unauthorized security vulnerabilities may cause unauthorized users to access sensitive information, perform critical operations, or obtain data beyond their authority. This is a huge security risk for enterprises and may lead to data leakage, business interruption, and even legal disputes. For example, an ordinary employee may access confidential files of senior management through unauthorized vulnerabilities, or malicious users may use vulnerabilities to tamper with important business data. Therefore, solving the problem of decentralized permission check codes and establishing a centralized and efficient permission management system are crucial for the safe and stable operation of enterprise-level applications. Summary of the invention

[0005] In view of the above problems, the purpose of the present invention is to provide a method and system for solving the unauthorized security vulnerability in a non-invasive manner. A custom tool is used to define a set of permission annotations. The tool automatically scans all classes and methods with annotations in the business code and performs permission checks. The permission check codes originally scattered throughout the business system are concentrated in the tool. This reduces duplicate code, hides complexity, and achieves non-invasiveness.

[0006] The above-mentioned object of the present invention is achieved through the following technical solutions: A non-invasive method for resolving an unauthorized security vulnerability comprises the following steps: S1: design a customized unauthorized security vulnerability detection tool, define a set of service provider interfaces SPI in the unauthorized security vulnerability detection tool, integrate with the business system through the service provider interface SPI, and implement authority judgment of the business system; S2: The bean object of the front-end interface that needs to perform permission judgment in the business system is marked with @Controller or @RestController annotations. At the same time, the unauthorized security vulnerability detection tool uses Spring AOP technology to add user permission checking logic to the method using tool annotations in the bean object. When permission judgment is required, the service provider interface SPI is used for calling.

[0007] Furthermore, in step S1, a customized unauthorized security vulnerability detection tool is designed, a set of service provider interfaces SPI is defined in the unauthorized security vulnerability detection tool, and the service provider interface SPI is integrated with the business system to implement the authority judgment of the business system, specifically: In the unauthorized security vulnerability detection tool, several interface methods included in the service provider interface SPI are defined, and interface specification documents of the interface methods are written, in which information including parameter meaning, return value type, expected function, and throwable exceptions of each interface method is clearly defined; In the business system and the unified authentication system integrated with the business system, the interface method defined in the interface specification document is implemented according to the own situation; In the unauthorized security vulnerability detection tool, a loading mechanism of the service provider interface SPI is implemented. Through the loading mechanism, the unauthorized security vulnerability detection tool dynamically discovers and loads the classes of the service provider interface SPI implemented by different business systems and the unified authentication system, without hard coding the specific calling logic for each business system and the unified authentication system in the unauthorized security vulnerability detection tool; When authority judgment is required, the unauthorized security vulnerability detection tool calls the corresponding interface method according to the specific detection scenario.

[0008] Further, in step S2, the bean object of the front-end interface that needs to perform permission judgment in the business system is marked with @Controller or @RestController annotations, and the unauthorized security vulnerability detection tool uses the Spring AOP technology to add user permission checking logic to the method using the tool annotation in the bean object, and when permission judgment is required, the service provider interface SPI is used for calling, specifically: The Spring MVC framework receives the original request of the front-end interface and inputs the original input parameters into the AOP aspect of the Spring AOP technology; The AOP aspect corrects the original input parameters, and based on the corrected input parameters, performs functional permission checks, data permission checks, and visible field unauthorized checks on the bean object using tool annotations according to the user permission check logic to obtain the return value of the front-end interface.

[0009] Furthermore, the function permission check is specifically as follows: The functional permission check is the permission for a specific operation in the business system. If the check fails, a 403 response code will be directly returned; The unauthorized security vulnerability detection tool defines the @ApiPermitted(code = "<authorization code / authorization expression>") annotation, in which the attribute code specifies a permission code or a permission expression; The permission code is a basic permission with clear business meaning defined by the business system, and the permission expression is a logical expression representing a combination of multiple permissions; The business system adds the @ApiPermitted annotation to the front-end interface class to indicate that all methods contained in the entire front-end interface class require corresponding permissions, or adds the @ApiPermitted annotation to any method of the front-end interface class to indicate that the current method requires corresponding permissions.

[0010] Furthermore, the data authority check is specifically as follows: The data permission check is used to verify the original input parameters of the front-end interface and control the subset of a set of data that a user can access; The unauthorized security vulnerability detection tool defines the @DataPermitted(dataType = "<data type of permission>") annotation, and the business system adds the @DataPermitted annotation to the parameter of the method of the front-end interface class, indicating that this parameter is subject to data permission control.

[0011] Furthermore, the visible field unauthorized check is specifically as follows: The visible field unauthorized check is used to control the user's viewing rights to specific fields in the data table. The unauthorized security vulnerability detection tool defines the @FieldPermitted(code = "<authorization code / authorization expression>", stub=…) annotation, and the attribute code in the annotation specifies a permission code or a permission expression; The permission code is a basic permission with clear business meaning defined by the business system, and the permission expression is a logical expression representing a combination of multiple permissions; The annotated attribute stub indicates the strategy for replacing the original field value when the user does not have permission to view this field. There are three strategies to choose from: This field does not exist in the data returned by the interface; The field value is null; The field takes an alternative value, specified by @FieldPermitted(pseudoValue = "..."); The business system adds the @FieldPermitted annotation to the field or the get method of the field, indicating that the corresponding permission is required to view the data of this field.

[0012] Furthermore, in the visible field unauthorized check, it also includes: Add a filter Rumba Authority Filter to correct the data returned to the front end and filter out the field data that the user is not authorized to view. The correction rules come from the AOP aspect.

[0013] A method for performing the above-mentioned non-invasive solution to unauthorized security vulnerabilities includes: A tool customization module is used to design a customized unauthorized security vulnerability detection tool, define a set of service provider interfaces SPI in the unauthorized security vulnerability detection tool, integrate with the business system through the service provider interface SPI, and implement the authority judgment of the business system; The permission judgment module is used to mark the bean object of the front-end interface that needs to be subject to permission judgment in the business system with the @Controller or @RestController annotation. At the same time, the unauthorized security vulnerability detection tool uses Spring AOP technology to add user permission checking logic to the method using the tool annotation in the bean object, and uses the service provider interface SPI for calling when permission judgment is required.

[0014] A computer device comprises a memory and one or more processors, wherein the memory stores computer codes, and when the computer codes are executed by the one or more processors, the one or more processors execute the above method.

[0015] A computer-readable storage medium stores computer codes. When the computer codes are executed, the above method is executed.

[0016] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) A non-invasive method for solving unauthorized security vulnerabilities is provided, including: S1: designing a customized unauthorized security vulnerability detection tool, defining a set of service provider interfaces SPI in the unauthorized security vulnerability detection tool, integrating the service provider interface SPI with the business system, and realizing the permission judgment of the business system; S2: using @Controller or @RestController annotations to mark the bean object of the front-end interface that needs to be judged for permission in the business system, and at the same time, the unauthorized security vulnerability detection tool uses Spring AOP technology to add user permission check logic to the method using the tool annotation in the bean object, and uses the service provider interface SPI to call when permission judgment is required. The above technical solution defines a set of permission annotations for use by the business system. The tool automatically scans all annotated classes and methods in the business code and performs permission checks. In this way, the permission check code originally scattered throughout the business system is concentrated in the tool. Reduce duplicate code, hide complexity, and achieve non-invasiveness.

[0017] (2) For a specific business system, only the classes or methods that need to check permissions need to be annotated. This is simple to use for business systems. When permissions change, only the annotations need to be adjusted.

[0018] (3) The tool can be integrated with multiple business systems. Each business system only needs to be integrated once to be conveniently used. Applicable scenarios include a single business system, multiple business system instances coexisting, and a combination of multiple business systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is an overall flow chart of the method for non-invasively resolving unauthorized security vulnerabilities of the present invention; Figure 2 A specific logic diagram for the permission check of the present invention; Figure 3 This is the overall structure diagram of the system for non-invasively solving unauthorized security vulnerabilities of the present invention. DETAILED DESCRIPTION

[0020] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0021] Those skilled in the art will appreciate that, unless otherwise stated, the singular forms "a", "an", "said" and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0022] The present invention defines a set of permission annotation tools for use in business systems. The tool automatically scans all annotated classes and methods in the business code and performs permission checks. In this way, the permission check codes originally scattered throughout the business system are concentrated in the tool. Reduce duplicate code, hide complexity, and achieve non-intrusiveness. The specific business system only needs to add Annotation annotations to the classes or methods that need to check permissions. For the business system, it is simple to use. When permissions change, only the annotations need to be adjusted. The tool can be integrated with a variety of business systems, and each business system only needs to be integrated once to be conveniently used. Applicable scenarios include a single business system, multiple instances of a business system, and a combination of multiple business systems.

[0023] The following is described by specific examples: First embodiment like Figure 1 As shown, this embodiment provides a non-invasive method for resolving unauthorized security vulnerabilities, including the following steps: S1: Design a customized unauthorized security vulnerability detection tool, define a set of service provider interfaces SPI in the unauthorized security vulnerability detection tool, integrate with the business system through the service provider interface SPI, and implement permission judgment of the business system.

[0024] In this embodiment, step S1 is specifically as follows: In the unauthorized security vulnerability detection tool, several interface methods included in the service provider interface SPI are defined, and interface specification documents of the interface methods are written, in which information including parameter meaning, return value type, expected function, and throwable exceptions of each interface method is clearly defined; In the business system and the unified authentication system integrated with the business system, the interface method defined in the interface specification document is implemented according to the own situation; In the unauthorized security vulnerability detection tool, a loading mechanism of the service provider interface SPI is implemented. Through the loading mechanism, the unauthorized security vulnerability detection tool dynamically discovers and loads the classes of the service provider interface SPI implemented by different business systems and the unified authentication system, without hard coding the specific calling logic for each business system and the unified authentication system in the unauthorized security vulnerability detection tool; When authority judgment is required, the unauthorized security vulnerability detection tool calls the corresponding interface method according to the specific detection scenario.

[0025] For example, suppose a service provider interface SPI includes three interface methods: filterOperationPermission(): Filter out the permissions that the user has from a set of operation permissions. filterDataPermission(): Filter out the permissions that the user has from a set of data permissions. queryOwnedDataPermission(): Query the data permissions that the user has. The following is the specific definition of the technical solution process of step S1 based on this example: 1. Define the service provider interface SPI and interface specification document 1. Define SPI interface method filterOperationPermission(): This method is used to accurately filter out the operation permissions that a specified user has from a set of operation permissions. It plays a key role in the permission judgment process, and through the careful screening of user operation permissions, it helps determine which operations a user can legally perform in the business system.

[0026] filterDataPermission(): The main function is to accurately filter out the data permissions that a given user has from a set of data permissions. In business scenarios involving data access and operations, this method ensures that users can only access and process the data resources they are authorized to, maintaining data security and compliance.

[0027] queryOwnedDataPermission(): Responsible for comprehensive query of all data permission information owned by a specified user. It provides a way to obtain a complete picture of the user's data permissions across the entire business system, facilitating more in-depth permission analysis and vulnerability detection.

[0028] 2. Write interface specification documents filterOperationPermission() interface specification: Parameter meaning: String userId: represents the unique identifier of the user for whom the operation permissions are to be screened. In an actual business system, it may be the user's account number, employee number, etc., which is used to identify the specific user to whom the permissions belong.

[0029] String[] operationList: A string array containing a set of operation permission names that need to be screened. For example, in an e-commerce system, it may contain operation permission names such as "create order", "modify order", and "delete order".

[0030] Return value type: Return a List Expected functionality: According to the passed user identifier and operation permission name array, by querying the permission management module in the business system or unified authentication system (which may involve database query, cache reading and other operations), the user's operation permissions are judged one by one, and finally the operation permissions that the user actually has are screened out and returned in the form of a list.

[0031] Exceptions that can be thrown: InvalidUserIdException: This exception is thrown when the passed in user identifier is invalid or unrecognizable. For example, this exception is triggered if the passed in user ID format is incorrect or the corresponding user record does not exist in the system.

[0032] PermissionDataSourceException: This exception is thrown if a problem related to the data source is encountered during the query of operation permission data, such as database connection failure, permission data storage corruption, etc.

[0033] filterDataPermission() interface specification: Parameter meaning: String userId: It is also the unique identifier of the user for whom data permissions are to be filtered.

[0034] String[] dataResourceList: A string array containing a set of data resource identifiers that need to be screened. These identifiers can be database table names, file paths, data object names, etc., depending on the data storage and management methods of the business system. For example, in an enterprise resource management system, it may contain data resource identifiers such as "employee information table" and "project document folder".

[0035] String accessType: indicates the access type, such as "read", "write", "delete", etc. It is used to clarify the type of access operation that the user expects for a specific data resource, so as to make targeted permission judgments.

[0036] Return value type: Return a List Expected functionality: Based on the passed-in user identifier, data resource identifier array, and access type, by interacting with the data permission management mechanism in the business system or unified authentication system (which may involve operations such as querying multiple database tables, parsing permission configuration files, etc.), a detailed judgment is made on the user's combination of each data resource and access type, thereby filtering out the data permissions that the user actually has and returning them in the form of a list.

[0037] Exceptions that can be thrown: InvalidUserIdException: Similar to the filterOperationPermission() method, this exception is thrown when the passed in user identifier is invalid or unrecognizable.

[0038] InvalidDataResourceException: This exception is thrown if any of the passed-in data resource identifiers is invalid or unrecognizable (for example, the database table name does not exist, the file path is incorrect, etc.).

[0039] PermissionDataSourceException: This exception is thrown when a problem related to the data source is encountered during the query of data permission data, such as the database connection failure mentioned above, the permission data storage is damaged, etc.

[0040] queryOwnedDataPermission() interface specification: Parameter meaning: String userId: The unique identifier of the user who is to perform data permission query.

[0041] Return value type: Returns a custom data structure, such as an instance of the UserDataPermissionInfo class. This class can contain multiple properties, such as List Expected functionality: By calling the comprehensive query interface of authority management in the business system or unified authentication system (which may involve joint query of multiple database tables, cache areas and other operations), based on the user identifier, all data authority information that the user has in the entire business system is fully obtained, including operation authority, data authority and other related details, and it is organized and encapsulated into the returned custom data structure.

[0042] Exceptions that can be thrown: InvalidUserIdException: This exception is thrown when the passed in user identifier is invalid or unrecognizable.

[0043] PermissionDataSourceException: This exception is thrown when a problem related to the data source is encountered during the query of all data permission data, such as database connection failure, damaged permission data settings, etc.

[0044] 2. Business system and unified authentication system interface implementation method 1. Understand business requirements and permission models Business system developers need to deeply analyze the specific operation process, functional requirements and existing permission model architecture of their own business. For example, in a financial transaction system, it is necessary to clearly understand the different permission settings of users in account operations (such as transfer, balance inquiry, purchase of financial products, etc.), customer information management (such as modifying customer information, viewing customer transaction records, etc.), and the complex relationship between these permissions and user roles (such as ordinary customers, financial managers, system administrators, etc.) and data resources (such as transaction record database tables, customer information tables, etc.).

[0045] For the unified authentication system integrated with the business system, it is also necessary to fully grasp the permission management requirements and the general permission model framework under the entire integrated system. It needs to consider how to provide unified and efficient permission authentication and management services while meeting the individual needs of different business systems. For example, in a scenario where a unified authentication system is used to integrate multiple business systems (such as office systems, financial systems, human resources systems, etc.) within an enterprise, the unified authentication system must clarify the common permission requirements of each business system (such as user login verification, basic information access rights, etc.) and individual permission requirements (such as accounting processing permissions unique to the financial system, employee file management permissions unique to the human resources system, etc.), and build a suitable permission model accordingly.

[0046] 2. Implement interface method according to SPI filterOperationPermission() implementation example (taking relational database storage permissions as an example): First, based on the user identifier userId passed in, the role information of the user is queried in the user table of the business system. This can be achieved through an SQL query statement, such as SELECT role_id FROM users WHERE user_id = '${userId}'.

[0047] Next, after obtaining the role information, based on the role-permission association table (assuming it is role_permissions) and the passed-in operation permission name array operationList, a series of SQL query statements (such as SELECT permission_name FROM role_permissions WHERE role_id = '${role_id}' AND permission_name IN ('${operationList[0]}', '${operationList[1]}',...)) are used to determine whether each operation permission belongs to the role to which the user belongs, thereby filtering out the operation permissions that the user actually has, and organizing the results into a string list for return.

[0048] During the entire process, if the user identifier is invalid (for example, the corresponding user record cannot be found), an InvalidUserIdException is thrown; if the database connection fails or there is a problem with the permission data storage, a PermissionDataSourceException is thrown.

[0049] filterDataPermission() implementation example (taking the file system storing some data resources and the relational database storage permissions as an example): For the input user identifier userId, the role information is also first queried in the user table.

[0050] Then, for each data resource identifier dataResourceList and access type accessType passed in, a judgment is made according to the situation. If the data resource identifier corresponds to a file or folder in the file system (such as project_documents_folder), the user role and the file system access permission configuration file (assuming such a configuration file exists) are used to determine whether the user has the corresponding access type permission for the data resource. If the data resource identifier corresponds to a database table (such as employee_information_table), the data permission association table in the database (such as user_data_permissions) is queried, combined with the user role information, to determine whether the user has the corresponding access type permission for the database table. For example, the judgment of the database table can be achieved through the SQL query statement SELECT permission FROMuser_data_permissions WHERE user_id = '${userId}' AND data_resource = '${dataResourceList[i]}' AND access_type = '${accessType}'.

[0051] All the data permission identifiers that the user has are sorted into a string list and returned. In the process, if the user identifier is invalid, the data resource identifier is invalid (such as file path error, database table name does not exist, etc.), or there is a problem with the data source, the corresponding InvalidUserIdException, InvalidDataResourceException, and PermissionDataSourceException are thrown respectively.

[0052] queryOwnedDataPermission() implementation example (taking the combination of relational database and cache storage permissions as an example): First, based on the passed in user identifier userId, query the role information in the user table of the business system.

[0053] Then, by querying multiple related tables in the database (such as user table, role table, permission table, data permission association table, etc.) and possible cache areas (such as cache for storing common permission information), all information about the user's operation permissions, data permissions, etc. can be fully obtained. For example, through the joint query statement SELECT operation_permissions, data_permissions FROM users JOIN role_permissions ON users.role_id = role_permissions.role_id JOIN user_data_permissions ON users.user_id =user_data_permissions.user_id WHERE users.user_id = '${userId}' to obtain relevant permission information.

[0054] All the obtained permission information is sorted and encapsulated into an instance of the UserDataPermissionInfo class, where the operationPermissions attribute stores the operation permission list, the dataPermissions attribute stores the data permission list, and other related attributes are set according to the actual situation. If the user identifier is invalid or there is a problem with the data source, the corresponding InvalidUserIdException and PermissionDataSourceException are thrown.

[0055] 3. Unauthorized security vulnerability detection tool implements SPI loading mechanism 1. Implementation of SPI loading mechanism (taking Java as an example) In the Java code of the unauthorized security vulnerability detection tool, the java.util.ServiceLoader class can be used to implement the SPI loading mechanism. First, define a variable of interface type to represent the SPI interface, such as ServiceProviderInterface spi, where it is assumed that ServiceProviderInterface is the interface class name that defines the SPI interface.

[0056] Then, all classes that implement ServiceProviderInterface are loaded through the ServiceLoader.load(ServiceProviderInterface.class) statement. This returns a ServiceLoader object that contains all eligible implementation classes.

[0057] Next, by traversing this ServiceLoader object, you can dynamically discover and load the ServiceProviderInterface classes implemented by different business systems and the unified authentication system. For example: ServiceLoader / / Here you can perform related operations on each loaded SPI instance, such as calling interface methods to determine permissions, etc.} 2. Avoid hard-coding specific call logic Through the above-mentioned SPI loading mechanism, the unauthorized security vulnerability detection tool does not need to hard-code the specific call logic for each business system and unified authentication system in the code. In other words, there is no need to write a specific call code snippet for each business system or unified authentication system to obtain permission information. Instead, through the unified specification of the SPI interface, as long as the business system and the unified authentication system implement the SPI interface according to the specification, the detection tool can automatically discover and load their implementation classes through the loading mechanism, and then directly call the corresponding interface method to perform operations such as permission judgment. This greatly improves the flexibility and scalability of the detection tool, enabling it to easily cope with the access and permission judgment requirements of different business systems and unified authentication systems.

[0058] 4. Permission Judgment Calling Interface Method 1. Permission determination process When permission judgment is required, the unauthorized security vulnerability detection tool calls the corresponding interface method according to the specific detection scenario. For example, when detecting whether a user can perform an operation beyond the permission, the filterOperationPermission() method is called.

[0059] First, obtain the user identifier and the array of related operation permission names (if any) in the current detection scenario. Assume that in a scenario where user operation behavior is monitored, by analyzing the user's operation records, the array of operation permission names that the user attempted to perform is extracted, and the user's account is obtained as the user identifier.

[0060] Then, the user identifier and the array of operation permission names are passed as parameters to the filterOperationPermission() method, and the interface method implemented by the loaded business system or unified authentication system is called to perform permission judgment.

[0061] According to the returned result, if the return value is false, but it is actually found that the user has attempted to perform the operation, it may indicate that there is an unauthorized security vulnerability.

[0062] 2. Data permission detection example For data permission detection, such as detecting whether a user has unauthorized access to a data resource, call the filterDataPermission() method.

[0063] Suppose in an enterprise resource management system, you want to check the user's access rights to the "employee information table". First, get the user identifier, then determine the access type to be checked (such as "read") and the data resource identifier (such as "employee information table"), and pass them as parameters to the filterDataPermission() method.

[0064] The authority is determined by calling the interface method implemented by the loaded business system or unified authentication system. If it is detected that the user does not have access rights to a data resource, but there are relevant operation records showing that the user has accessed the data resource, it also indicates that there may be an unauthorized security vulnerability.

[0065] 3. Comprehensive Permission Analysis Example The queryOwnedDataPermission() method can be used to perform a more comprehensive permission analysis. For example, when reviewing a user's permission configuration in the entire business system, call the queryOwnedDataPermission() method and pass in the user identifier.

[0066] By calling the interface method implemented by the loaded business system or unified authentication system, all the user's permission information, including operation permissions, data permissions and other related details, can be obtained. Then the obtained permission information can be matched with the expected business role permissions to check whether there are abnormal permission configurations, so as to discover possible unauthorized security vulnerabilities or unreasonable permission settings.

[0067] S2: The bean object of the front-end interface that needs to perform permission judgment in the business system is marked with @Controller or @RestController annotations. At the same time, the unauthorized security vulnerability detection tool uses Spring AOP technology to add user permission checking logic to the method using tool annotations in the bean object. When permission judgment is required, the service provider interface SPI is used for calling.

[0068] In this embodiment, if Figure 2 As shown, step S2 is specifically as follows: The Spring MVC framework receives the original request of the front-end interface and inputs the original input parameters into the AOP aspect of the Spring AOP technology; the AOP aspect corrects the original input parameters, and based on the corrected input parameters, performs functional permission checks, data permission checks, and visible field unauthorized checks on the bean object using tool annotations according to the user permission check logic to obtain the return value of the front-end interface.

[0069] In this embodiment, the front-end interface is a BFF interface, that is, an HTTP interface. The HTTP interfaces in Spring MVC are all in beans annotated with @Controller or @RestController. The tool uses Spring AOP technology to add user permission checking logic to the methods annotated with the tool in these Controller beans.

[0070] Figure 2 The Rumba Authority Aspect in the example is an AOP aspect. Its responsibilities include function permission checking (vertical permission violation), data permission checking (horizontal permission violation), and visible field permission checking (visible field permission violation), which are described below.

[0071] (1) The functional permission check is specifically: The functional permission check is the permission for a specific operation in the business system. If the check fails, a 403 response code will be directly returned. For example, the permission to create goods, the permission to delete goods, the permission to review purchase orders, etc. If a user obtains functional permissions beyond his or her authority, he or she can perform operations that he or she does not have the authority to perform, which is vertical overreach.

[0072] The unauthorized security vulnerability detection tool defines the @ApiPermitted(code = "<authorization code / authorization expression>") annotation, in which the attribute code specifies a permission code or a permission expression; The permission code is a basic permission with clear business meaning defined by the business system. The administrator of the business system assigns specific permissions to specific users. The functional permissions possessed by a user are a collection of permission codes.

[0073] The permission expression is a logical expression, which represents a combination of multiple permissions; for example, having multiple permissions at the same time, having any one of multiple permissions, etc.

[0074] view-goods && (modify-goods || remove-goods) This means that the user must have the view-goods permission and either the modify-goods or remove-goods permission. The logical operators supported by permission expressions are AND (&&), OR (||), NOT (!), and brackets.

[0075] The business system adds the @ApiPermitted annotation to the front-end interface class to indicate that all methods contained in the entire front-end interface class require corresponding permissions, for example: @ApiPermitted(code = "view-goods") public interface GoodsService {} Indicates that users need to have the view-goods permission to access all methods in the GoodsService interface class. Here, "view-goods" is a permission code, indicating the right to view goods.

[0076] Or add the @ApiPermitted annotation to any method of the front-end interface class to indicate that the current method requires the corresponding permission. For example: public interface GoodsService { @ApiPermitted(code = "create-goods") void create(Goods goods); } Indicates that users need to have the create-goods permission to access the create method of GoodsService.

[0077] (2) The data authority check is specifically: The data permission check is used to verify the original input parameters of the front-end interface and control the subset of data that users can access. For example, if there are 100 records of customer information, an employee can only access 10 records related to his or her work, a department manager can access 40 customer information in the area he or she is responsible for, and the general manager can access all 100 records. If a user accesses data outside of his or her authority, it is horizontal overreach.

[0078] The unauthorized security vulnerability detection tool defines the @DataPermitted(dataType = "<data type of permission>") annotation. The business system adds the @DataPermitted annotation to the parameters of the method of the front-end interface class, indicating that this parameter is subject to data permission control. For example, a method that searches for the corresponding order based on the incoming customer List Indicates that the parameter customerIds is controlled by the data permissions of the user. The tool will be responsible for correcting the parameter value to make it consistent with the user's data permissions.

[0079] (3) The above-mentioned visible field unauthorized check is as follows: The visible field unauthorized check is used to control the user's viewing rights to specific fields in the data table. For example, a table has 10 fields, 3 of which are sensitive information and can only be seen by users in special departments. Then the general users can only see 7 fields of data, and the sensitive fields are invisible to them. Users in special departments can see all 10 fields. If the user sees field data outside the scope of his or her permission, he or she has seen information that he or she has no right to view, which means that the visible field has been unauthorized. The unauthorized security vulnerability detection tool defines the @FieldPermitted(code = "<permission code / permission expression>", stub=…) annotation, and the attribute code in the annotation specifies a permission code or a permission expression; The permission code is a basic permission with clear business meaning defined by the business system, and the permission expression is a logical expression representing a combination of multiple permissions; The annotated attribute stub indicates the strategy for replacing the original field value when the user does not have permission to view this field. There are three strategies to choose from: This field does not exist in the data returned by the interface; The field value is null; The field takes an alternative value, specified by @FieldPermitted(pseudoValue = "..."); The business system adds the @FieldPermitted annotation to the field or the get method of the field, indicating that the corresponding permission is required to view the data of this field.

[0080] For example: public class Goods { @FieldPermitted(code = "view-goods-purchase-price") private BigDecimal purchasePrice; } This means that the user needs to have the view-goods-purchase-price permission to view this field (goods purchase price). The same is true when the annotation is added to the get method: public class Goods { @FieldPermitted(code = "view-goods-purchase-price") public BigDecimal getPurchasePrice() { return purchasePrice; } } In addition, the visible field unauthorized check also includes: Add a filter Rumba Authority Filter to correct the data returned to the front end and filter out the field data that the user is not authorized to view. The correction rules come from the AOP aspect. The AOP aspect will not directly correct the content of the return value of the front-end interface, but will tell the correction rules to Rumba Authority Filter, which will be responsible for correcting it before returning it to the front end. Because no matter whether the front end has the right to view the data, the application always has the right to view the data, and other AOP aspects must also be able to see the complete data.

[0081] Second embodiment like Figure 3 As shown, this embodiment provides a method for executing the non-invasive solution to the unauthorized security vulnerability in the first embodiment, including: The tool customization module 1 is used to design a customized unauthorized security vulnerability detection tool, define a set of service provider interfaces SPI in the unauthorized security vulnerability detection tool, integrate with the business system through the service provider interface SPI, and implement the authority judgment of the business system; The permission judgment module 2 is used to mark the bean object of the front-end interface that needs to perform permission judgment in the business system with @Controller or @RestController annotations. At the same time, the unauthorized security vulnerability detection tool uses Spring AOP technology to add user permission checking logic to the method using the tool annotation in the bean object, and when permission judgment is required, the service provider interface SPI is used for calling.

[0082] A computer-readable storage medium stores computer code. When the computer code is executed, the above method is executed. A person skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program. The program can be stored in a computer-readable storage medium. The storage medium can include: a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0083] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

[0084] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0085] It should be noted that the above embodiments can be freely combined as needed. The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered as the protection scope of the present invention.

Claims

1. A non-invasive method for resolving unauthorized security vulnerabilities, characterized in that: The following steps are involved: S1: design a customized unauthorized security vulnerability detection tool, define a set of service provider interfaces SPI in the unauthorized security vulnerability detection tool, integrate with the business system through the service provider interface SPI, and implement authority judgment of the business system; S2: The bean object of the front-end interface that needs to perform permission judgment in the business system is marked with @Controller or @RestController annotations. At the same time, the unauthorized security vulnerability detection tool uses Spring AOP technology to add user permission checking logic to the method using tool annotations in the bean object. When permission judgment is required, the service provider interface SPI is used for calling.

2. The non-invasive method for resolving unauthorized security vulnerabilities according to claim 1, characterized in that: In step S1, a customized unauthorized security vulnerability detection tool is designed, a set of service provider interfaces SPI is defined in the unauthorized security vulnerability detection tool, and the service provider interface SPI is integrated with the business system to implement the authority judgment of the business system, specifically: In the unauthorized security vulnerability detection tool, several interface methods included in the service provider interface SPI are defined, and interface specification documents of the interface methods are written, in which information including parameter meaning, return value type, expected function, and throwable exceptions of each interface method is clearly defined; In the business system and the unified authentication system integrated with the business system, the interface method defined in the interface specification document is implemented according to the own situation; In the unauthorized security vulnerability detection tool, a loading mechanism of the service provider interface SPI is implemented. Through the loading mechanism, the unauthorized security vulnerability detection tool dynamically discovers and loads the classes of the service provider interface SPI implemented by different business systems and the unified authentication system, without hard coding the specific calling logic for each business system and the unified authentication system in the unauthorized security vulnerability detection tool; When authority judgment is required, the unauthorized security vulnerability detection tool calls the corresponding interface method according to the specific detection scenario.

3. The non-invasive method for resolving unauthorized security vulnerabilities according to claim 1, characterized in that: In step S2, the bean object of the front-end interface that needs to be judged for authority in the business system is marked with @Controller or @RestController annotations. At the same time, the unauthorized security vulnerability detection tool uses the Spring AOP technology to add user authority checking logic to the method using the tool annotation in the bean object. When authority judgment is required, the service provider interface SPI is used for calling, specifically: The Spring MVC framework receives the original request of the front-end interface and inputs the original input parameters into the AOP aspect of the SpringAOP technology; The AOP aspect corrects the original input parameters, and based on the corrected input parameters, performs functional permission checks, data permission checks, and visible field unauthorized checks on the bean object using tool annotations according to the user permission check logic to obtain the return value of the front-end interface.

4. The non-invasive method for resolving unauthorized security vulnerabilities according to claim 3, characterized in that: The function permission check is specifically as follows: The functional permission check is the permission for a specific operation in the business system. If the check fails, a 403 response code will be directly returned; The unauthorized security vulnerability detection tool defines the @ApiPermitted(code = "<authorization code / authorization expression>") annotation, in which the attribute code specifies a permission code or a permission expression; The permission code is a basic permission with clear business meaning defined by the business system, and the permission expression is a logical expression representing a combination of multiple permissions; The business system adds the @ApiPermitted annotation to the front-end interface class to indicate that all methods contained in the entire front-end interface class require corresponding permissions, or adds the @ApiPermitted annotation to any method of the front-end interface class to indicate that the current method requires corresponding permissions.

5. The non-invasive method for resolving unauthorized security vulnerabilities according to claim 3, characterized in that: The data permission check is specifically as follows: The data permission check is used to verify the original input parameters of the front-end interface and control the subset of a set of data that a user can access; The unauthorized security vulnerability detection tool defines the @DataPermitted(dataType = "<data type of permission>") annotation, and the business system adds the @DataPermitted annotation to the parameter of the method of the front-end interface class, indicating that this parameter is subject to data permission control.

6. The non-invasive method for resolving unauthorized security vulnerabilities according to claim 3, characterized in that: The visible field unauthorized check is specifically as follows: The visible field unauthorized check is used to control the user's viewing rights to specific fields in the data table. The unauthorized security vulnerability detection tool defines the @FieldPermitted(code = "<authorization code / authorization expression>", stub=…) annotation, and the attribute code in the annotation specifies a permission code or a permission expression; The permission code is a basic permission with clear business meaning defined by the business system, and the permission expression is a logical expression representing a combination of multiple permissions; The annotated attribute stub indicates the strategy for replacing the original field value when the user does not have permission to view this field. There are three strategies to choose from: This field does not exist in the data returned by the interface; The field value is null; The field takes an alternative value, specified by @FieldPermitted(pseudoValue = "..."); The business system adds the @FieldPermitted annotation to the field or the get method of the field, indicating that the corresponding permission is required to view the data of this field.

7. The non-invasive method for resolving unauthorized security vulnerabilities according to claim 6, characterized in that: The visible field unauthorized inspection also includes: Add a filter Rumba Authority Filter to correct the data returned to the front end and filter out the field data that the user is not authorized to view. The correction rules come from the AOP aspect.

8. A method for executing the non-invasive solution to unauthorized security vulnerabilities as claimed in any one of claims 1 to 7, characterized in that: include: A tool customization module is used to design a customized unauthorized security vulnerability detection tool, define a set of service provider interfaces SPI in the unauthorized security vulnerability detection tool, integrate with the business system through the service provider interface SPI, and implement the authority judgment of the business system; The permission judgment module is used to mark the bean object of the front-end interface that needs to be subject to permission judgment in the business system with the @Controller or @RestController annotation. At the same time, the unauthorized security vulnerability detection tool uses Spring AOP technology to add user permission checking logic to the method using the tool annotation in the bean object, and the service provider interface SPI is used for calling when permission judgment is required.

9. A computer device comprising a memory and one or more processors, wherein the memory stores computer codes, and when the computer codes are executed by the one or more processors, the one or more processors execute the method according to any one of claims 1 to 7. 10 . A computer-readable storage medium storing a computer code. When the computer code is executed, the method according to claim 1 is executed.

Images