Cross-domain authorization checking method, device and storage medium

Abstract

The application provides a transverse authority checking method, device and storage medium, wherein the method comprises the following steps: obtaining a to-be-checked request containing a plurality of parameter objects, then determining and calling at least one target resolver according to the request to analyze the request and obtain a plurality of key-value pairs composed of the parameter objects and parameter values as an analysis result. Finally, at least one target checker is determined and called according to the request to check the analysis result, so as to obtain the transverse authority checking result of the to-be-checked request. By separating the transverse authority checking function from the business code, the dynamic combination and calling of the resolver and the checker are utilized, the decoupling of the checking logic and the core business is realized. Not only the coupling degree and the redundancy of the code are reduced, but also the reusability of the checking logic and the maintainability of the system are improved, and the transverse authority risk is effectively prevented.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, device, and storage medium for lateral overreach verification. Background Technology

[0002] In web applications built on the Spring framework, data security is a core concern. When processing user data queries, it is essential to ensure that users can only access data within their authorized scope to prevent lateral privilege escalation vulnerabilities. To ensure data isolation, backend services typically need to write extensive validation code in the business logic layer to verify the validity of request parameters.

[0003] Currently, the industry's common practices mainly rely on two technologies: one is to use the Spring data validation framework combined with custom annotations for parameter format validation; the other is to intercept specific annotations through AOP (Aspect-Oriented Programming) and write hard-coded permission checking logic in the aspect. Developers usually need to manually write repetitive validation code or configure cumbersome aspect rules for different business scenarios.

[0004] However, solutions based on the Spring validation framework can only validate the format or static range of parameters, and cannot achieve dynamic data permission ownership validation; while hard-coded solutions based on AOP result in high coupling between validation logic and business code, extremely poor reusability, and each time a new validation rule is added, the aspect code needs to be modified or a new aspect class needs to be added, resulting in serious code redundancy and maintenance difficulties. Summary of the Invention

[0005] The purpose of this application is to provide a horizontal access control verification method, device, and storage medium to address the shortcomings of the prior art, thereby solving the problems of the inability to achieve dynamic data access control verification and poor reusability in the prior art.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows: Firstly, this application provides a horizontal overriding verification method applied to a verifier, the method comprising: Obtain the verification request for the current business, which includes multiple parameter objects; At least one target parser is determined based on the request to be verified, and each target parser is invoked to parse the request to be verified, thereby obtaining the parsing result of the request to be verified. The parsing result includes multiple key-value pairs, where the key of each key-value pair is a parameter object, and the value of each key-value pair is the parameter value of the parameter object. At least one target checker is determined based on the request to be verified, and each target checker is invoked to verify the parsing result, thereby obtaining the over-authority verification result of the request to be verified.

[0007] Optionally, determining at least one target parser for the request to be verified based on the request to be verified includes: Determine the annotation information in the request to be verified. The annotation information is pre-annotated on the request parameter object corresponding to the request to be verified during the development phase. The annotation information includes: column name configuration information, value list configuration information, and prompt information. The target parser corresponding to the request to be verified is determined based on the value list configuration information.

[0008] Optionally, the value list configuration information includes multiple expressions, each expression indicating the data source of each input parameter. Each expression is pre-configured with a corresponding parser, and the parser includes at least: a user context parser, a current object parser, a current value parser, and a constant parser. The step of determining the target parser corresponding to the request to be verified based on the value list configuration information includes: Iterate through each expression in the value list configuration information, and for the current expression, determine the parser of the current expression based on the prefix of the current expression and the pre-built mapping relationship between expressions and parsers; After the traversal is completed, all the determined parsers are used as the target parsers corresponding to the request to be verified.

[0009] Optionally, the step of invoking each of the target parsers, and having each target parser parse the request to be verified to obtain the parsing result of the request to be verified, includes: If the target parser is a user context parser, then the target parser is invoked, and the target parser parses the login context information in the request to be verified to obtain the first parsed value corresponding to the login context information. The login context information is used as the key, and the first parsed value is used as the value to form a key-value pair as an item in the parsing result. If the target parser is the current object parser, then the current object parser is invoked, and the current object parser parses the request parameter object of the request to be verified to obtain the second parsed value. The request parameter object is used as the key, and the second parsed value is used as the value to form a key-value pair as one item in the parsing result. If the target parser is the current value parser, then the current value parser is invoked, and the current value parser parses the current expression in the request to be verified to obtain the third parsing value. The current expression is used as the key, and the third parsing value is used as the value to form a key-value pair as an item in the parsing result. If the target parser is a constant parser, then the constant parser is invoked to parse the current expression, obtain the fourth parsing value, and use the current expression as the key and the fourth parsing value as the value to form a key-value pair as one item in the parsing result.

[0010] Optionally, determining at least one target checker for the request to be verified based on the request to be verified includes: Determine the annotation information in the request to be verified, the annotation information including: checker configuration information; The checker indicated by the checker configuration information is used as the target checker corresponding to the request to be verified.

[0011] Optionally, the step of invoking each of the target checkers, and having each target checker verify the parsing result to obtain the over-authority verification result of the request to be verified, includes: Iterate through each key-value pair in the parsing result. For the current key-value pair, call the target checker to verify the current key-value pair and obtain the verification result of the current key-value pair. After verifying all key-value pairs, the over-authority verification result of the request to be verified is determined based on the verification results of each key-value pair in the parsing results.

[0012] Optionally, the step of invoking the target inspector to verify the current key-value pair and obtain the verification result of the current key-value pair includes: If the target inspector is a database inspector, then a database query statement is constructed based on the current key-value pair; If the database query statement is executed and the data query result is not empty, then the validation result of the current key-value pair is determined to be valid; if the data query result is empty, then the validation result of the current key-value pair is determined to be invalid.

[0013] Optionally, the step of invoking the target inspector to verify the current key-value pair and obtain the verification result of the current key-value pair includes: If the target checker is a custom checker, then the corresponding verification interface of the custom checker is called, the current key-value pair is used as the input parameter of the verification interface, and the verification result of the current key-value pair returned by the verification interface is obtained.

[0014] Secondly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of a lateral access violation verification method as described in any one of the first aspects.

[0015] Thirdly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of a lateral access violation verification method as described in any one of the first aspects.

[0016] The beneficial effects of this application are: by introducing an independent validator, the validation logic, which was originally scattered in various places, is centrally managed. The validator can call the target parser to automatically break down complex business requests into standard key-value pairs, and then call the target checker to perform precise validation on these key-value pairs. This design completely decouples permission validation from core business code, so that developers do not need to repeatedly write validation code in each business method, thereby significantly reducing code coupling and redundancy, and improving the reusability of validation logic and the maintainability of the system.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This paper shows a schematic diagram of the structure of a lateral overreach verification system provided in an embodiment of this application; Figure 2 A flowchart of a horizontal overriding verification method provided in an embodiment of this application is shown; Figure 3 A flowchart illustrating a target parser determination method provided in an embodiment of this application is shown; Figure 4 A flowchart of yet another target determination parser provided in an embodiment of this application is shown; Figure 5 This document illustrates a flowchart of an embodiment of the present application for obtaining the parsing result; Figure 6 A flowchart of a target determination inspector provided in an embodiment of this application is shown; Figure 7 This document illustrates a flowchart of a method for determining an unauthorized access check result, provided in an embodiment of this application. Figure 8 A flowchart illustrating a method for determining the verification result of a current key-value pair, as provided in an embodiment of this application, is shown. Figure 9 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0022] In current multi-tenant or store management systems, to prevent lateral access violations (such as staff from store A accessing data from store B), a common approach is to manually write validation logic in the business logic code. Developers write code directly before the business methods to hard-code validation of parameters passed from the front end; if a parameter exceeds the current context's scope, an exception is thrown. Alternatively, there is a solution where validation rules are extracted and configured in the database, and the business logic calls a general utility class to read the configuration and perform validation line by line.

[0023] However, manually writing validation logic results in high coupling between the validation code and core business logic, leading to code redundancy and difficulty in reuse, increasing maintenance costs and development cycles. Storing configurations in a database, while achieving some decoupling, increases unnecessary database dependencies and makes configuration maintenance cumbersome. Both approaches reduce system testability and flexibility, hindering rapid iteration and improving product competitiveness.

[0024] Based on this, this application proposes a horizontal privilege escalation verification method to address the technical problems of strong coupling between verification logic and business code, difficulty in code reuse, and high maintenance costs in existing technologies. The method of this application is applied to the verifier in a horizontal privilege escalation verification system, such as... Figure 1 The diagram illustrates a system architecture where validator 102 can be connected to annotator 101, checker 104, and parser 103. Parser 103 includes multiple parser components, and checker 104 includes multiple checker components. By calling annotator 101 to pre-annotate the request parameter object corresponding to the request to be validated with annotations containing column names and value list configuration information, the validation rules are configurable. During validation, validator 102 determines the target parser and target checker based on the annotation information in the request to be validated; the target parser generates key-value pair parsing results based on the expressions in the value list; and the target checker then validates the parsing results. By abstracting the validation logic into independent parser and checker components, this application decouples the unauthorized validation logic from the core business code, maximizing the reuse of validation logic, significantly reducing development and maintenance costs, and improving system scalability.

[0025] Figure 2 This is a flowchart of a horizontal privilege escalation verification method provided in an embodiment of this application, such as... Figure 2 As shown, the method includes: S201. Obtain the verification request for the current business. The verification request includes multiple parameter objects.

[0026] Optionally, the request to be verified refers to a business operation instruction initiated by a user that requires authorization verification before execution. The parameter object refers to the specific data entity or Java Bean carried in the request to be verified, such as an object containing fields such as order ID and user ID.

[0027] The validator can intercept user-initiated verification requests and call the parser and checker to parse and check the verification requests in order to determine whether there are any horizontal privilege escalation issues in the verification requests.

[0028] S202. Determine at least one target parser based on the request to be verified, and call each target parser. Each target parser parses the request to be verified to obtain the parsing result of the request to be verified. The parsing result includes multiple key-value pairs, where the key of each key-value pair is the parameter object, and the value of each key-value pair is the parameter value of the parameter object.

[0029] Optionally, the target parser refers to the component responsible for extracting specific data from the request. The parsing result refers to the structured data obtained after decomposing the request to be verified, i.e., a data set in key-value pair form.

[0030] The parser includes various parser components, the functionality of which can be determined based on the needs of the actual business scenario. For example, parser components may include a user context parser, a current object parser, a current value parser, and a constant parser. When new business scenarios need to be added, components can be written for the new business scenarios to extend the parser's functionality.

[0031] During the data extraction phase, the validator can dynamically select a suitable parser as the target parser based on the characteristics of the request to be verified. Once the target parser is invoked, it can analyze the request and break it down into multiple key-value pairs. For example, the target parser might retrieve User ID=1001 and Order ID=2001 from the request to be verified, forming key-value pairs that can be used for verification as the parsing result.

[0032] S203. Determine at least one target checker based on the request to be verified, and call each target checker to verify the parsing results to obtain the over-authority verification result of the request to be verified.

[0033] Optionally, the target checker refers to the component responsible for executing the specific verification logic. The unauthorized access verification result refers to the Boolean value or status code that ultimately determines whether the request to be verified is valid.

[0034] The validator comprises various validator components, which can be built according to the actual business scenario requirements. For example, validator components may include database validator components or other user-defined validator components. When it is necessary to add validation methods for new business scenarios, the functionality of the validator can be extended by writing components.

[0035] After the validator determines the parsing result, it can select the corresponding checker based on the configuration of the request to be verified. The checker receives the parsed key-value pair data, verifies it according to preset rules, and finally outputs a clear verification result, determining whether the business request can be allowed.

[0036] This application's embodiments centralize the previously scattered verification logic by introducing an independent validator. The validator can call the target parser to automatically break down complex business requests into standard key-value pairs, and then call the target checker to perform precise verification on these key-value pairs. This design completely decouples permission verification from core business code, eliminating the need for developers to repeatedly write verification code in each business method. This significantly reduces code coupling and redundancy, and improves the reusability of verification logic and the maintainability of the system.

[0037] Figure 3 This is a flowchart illustrating a target parser determination method provided in an embodiment of this application. The following is in conjunction with... Figure 3 Further explanation of the above description of at least one target parser for determining the request to be verified based on the request to be verified includes: S301. Determine the annotation information in the request to be verified. The annotation information is pre-marked on the request parameter object corresponding to the request to be verified during the development phase. The annotation information includes: column name configuration information, value list configuration information, and prompt information.

[0038] Optionally, annotation information is metadata tags used in the programming code. Annotation information does not directly participate in business logic operations, but is attached to the code as configuration descriptions. Column name configuration information refers to the names of the fields in the business data table that need to be validated, and value list configuration information is used to describe the rules or set of expressions for obtaining the data required for validation, and to indicate which parsers should be selected as target parsers; prompt information is the prompt text fed back to the front end when validation fails.

[0039] During the development phase, developers can pre-add annotations to the request parameter objects. When the validator receives the request to be validated, it first reads these annotations. For example, the annotation could be "Exist," and its content might specify that the column to be validated is the order ID, the rules for retrieving this value are in the value list, and if validation fails, an error message indicating that the user is not authorized to operate on this order will be displayed. By parsing these configurations, the validator can understand the context of the validation.

[0040] S302. Determine the target parser corresponding to the request to be verified based on the value list configuration information.

[0041] Optionally, the value list configuration information can indicate the parser to be used.

[0042] After reading the value list configuration information, the validator can analyze the rules within it to deduce which specific parser needs to be invoked. For example, if the value list configuration specifies retrieving the ID from the currently logged-in user's information, the system can determine that a user context parser is needed; if it specifies retrieving the order number from the request body object, then a current object parser is required. Through this mechanism, the validator can dynamically and flexibly assemble the combination of parsers needed to process the current request.

[0043] In this embodiment, dynamic routing and automatic assembly of the target parser are achieved by introducing annotation information, particularly utilizing the value list configuration information within it. Developers only need to configure simple annotations during the development phase, allowing the validator to automatically identify and determine the required parser at runtime, eliminating the need to hardcode complex judgment logic in the code. This approach not only improves the flexibility and scalability of the validation framework but also decouples business code from the underlying validation logic, reducing development and maintenance costs.

[0044] Optionally, the value list configuration information includes multiple expressions, each of which indicates the data source of each input parameter. Each expression is pre-configured with a corresponding parser, which includes at least: a user context parser, a current object parser, a current value parser, and a constant parser.

[0045] An expression refers to a string written according to specific syntax rules, used to dynamically describe the source or value logic of data.

[0046] The user context resolver is used to extract session information of the currently logged-in user; the current object resolver is used to extract specific field values ​​from the parameter object of the current request; the current value resolver is used to extract the value of a specific expression that is currently being traversed or processed; and the constant resolver is used to process fixed numerical values ​​or strings.

[0047] Figure 4 This is another flowchart for determining a target parser provided in an embodiment of this application. The process of determining the target parser corresponding to the request to be verified based on the value list configuration information includes: S401. Traverse each expression in the value list configuration information. For the current expression being traversed, determine the parser for the current expression based on the prefix of the current expression and the pre-built mapping relationship between expressions and parsers.

[0048] Optionally, a prefix refers to a specific character or symbol at the beginning of an expression string, serving as a label to identify the data source type; the mapping relationship is a pre-defined lookup table or dictionary used to associate a specific prefix with its corresponding parser.

[0049] In one possible implementation, all expressions in the value list can be scanned one by one. For each current expression, a prefix is ​​extracted, and this prefix is ​​then used to look up a pre-prepared mapping table. Once a match is found, it becomes clear which parser should handle the expression. For example, upon reading #userId, the prefix # is identified, and a lookup table reveals that the user context parser needs to be invoked.

[0050] S402. After the traversal is completed, all the determined parsers are used as the target parsers corresponding to the requests to be verified.

[0051] Once all expressions in the value list have been scanned and matched, all the parsers identified during this process can be aggregated to form a complete set of target parsers. For example, if a validation rule requires both user ID and order ID, the user context parser and the current object parser will be determined as target parsers and invoked together in subsequent steps.

[0052] In this embodiment, by introducing an expression and its prefix mapping mechanism, refined automatic identification and dynamic assembly of the target parser are achieved. There is no need to hardcode complex judgment logic; simply by parsing the prefix of the expression, the corresponding parser can be accurately located using a preset mapping relationship. This approach improves the flexibility and scalability of the validation framework. When a new data source is needed, only a new expression prefix and corresponding parser need to be added, without modifying the core validation process code, thus reducing system coupling and maintenance costs.

[0053] Figure 5 This is a flowchart illustrating how to obtain the parsing result, provided in an embodiment of this application. (Refer to...) Figure 5 The process described above, invoking each target parser and having each target parser parse the request to be verified to obtain the parsing result of the request to be verified, includes: S501. If the target parser is a user context parser, then the target parser is invoked. The target parser parses the login context information in the request to be verified, obtains the first parsed value corresponding to the login context information, and uses the login context information as the key and the first parsed value as the value to form a key-value pair as one item in the parsing result.

[0054] Optionally, the user context resolver is a component used to extract the session information of the currently logged-in user; the login context information refers to the user identity information saved by the system in the current session, such as the User object stored in Thread Local or Session, which includes userId, username, etc.; the first parsed value refers to the specific data actually extracted by the resolver.

[0055] In one possible implementation, when a user context resolver is identified as needed, it can retrieve predefined user information from the current login context and encapsulate it into key-value pairs. For example, the key is the logged-in user ID, and the value is 10086.

[0056] S502. If the target parser is the current object parser, then the current object parser is called. The current object parser parses the request parameter object of the request to be verified, obtains the second parsed value, and uses the request parameter object as the key and the second parsed value as the value to form a key-value pair as one item in the parsing result.

[0057] Optionally, the current object resolver is the component responsible for extracting specific field values ​​from the parameter entity of the business request; the request parameter object refers to the entity object containing business data that is passed from the front end to the back end; the second resolved value refers to the specific field value (such as order number, resource ID, etc.) extracted from the object through reflection or getter methods.

[0058] In one possible implementation, when validation relies on business data in the request body, the current object resolver can be invoked to extract the key fields used for validation. For example, if the frontend passes in an object containing order details, the current object resolver can extract the order ID: 2023001 and encapsulate it as a key-value pair.

[0059] S503. If the target parser is the current value parser, then the current value parser is called. The current value parser parses the current expression in the request to be verified, obtains the third parsed value, and uses the current expression as the key and the third parsed value as the value to form a key-value pair as one item in the parsing result.

[0060] Optionally, the current value parser is used to process dynamic expressions or temporary values ​​in a specific context; the current expression refers to the string rule defined in the configuration that needs to be dynamically evaluated; the third parsed value refers to the actual result of the expression after it is calculated or parsed at runtime.

[0061] In one possible implementation, when the configuration contains dynamic logic, the current value resolver can be invoked. The current value resolver can calculate the value of the current expression in real time and convert it into a specific third-party resolved value, storing it as a key-value pair.

[0062] S504. If the target parser is a constant parser, then the constant parser is called to parse the current expression, obtain the fourth parsing value, and use the current expression as the key and the fourth parsing value as the value to form a key-value pair as one item in the parsing result.

[0063] Optionally, the constant parser is used to process static data that remains unchanged; a constant refers to a value or string that remains unchanged in the configuration; the fourth parsed value is the value of the constant itself.

[0064] In one possible implementation, when a fixed reference value needs to be introduced into the validation rule (e.g., to check if the order status is equal to a fixed paid status code), a constant parser can be invoked. The constant parser can extract the constants in the configuration and encapsulate them as a fourth parsed value into a key-value pair.

[0065] In this embodiment, by pre-setting multiple dedicated parsers for different scenarios and uniformly encapsulating the extracted data into a standard key-value pair format, the diversification of data sources and the standardization of data structure are achieved. This enables the validation framework to flexibly handle various complex validation requirements. Whether extracting dynamic user identity information, business object fields, or processing fixed constants, it can output standardized data through a unified interface. This not only improves the versatility and reusability of the validation logic but also reduces the complexity of system integration.

[0066] Figure 6 This is a flowchart illustrating the process of determining a target inspector according to an embodiment of this application. The process of determining at least one target inspector for a request to be verified based on the request to be verified includes: S601. Determine the annotation information in the request to be verified. The annotation information includes: checker configuration information.

[0067] S602. Use the checker indicated by the checker configuration information as the target checker corresponding to the request to be verified.

[0068] Among them, the checker configuration information is a specific configuration item in the annotation information used to specify who should perform the verification.

[0069] Optionally, the validator can first scan the parameter object corresponding to the request to be validated and extract the annotation information pre-written by the developer. Then, according to the instructions in the validator configuration information, it can find the corresponding validator component from the existing validators and designate it as the target validator for the current request. Based on this, developers can flexibly switch the validation logic of the request by simply modifying the configuration in the annotations without changing any business code or underlying framework code.

[0070] In this embodiment, an annotation mechanism containing checker configuration information is introduced to achieve dynamic specification and flexible switching of target checkers. Developers only need to configure simple annotations during the development phase, and the system can automatically identify and call the corresponding checker at runtime, without having to hardcode complex conditional judgment logic in the code. This not only improves the flexibility and scalability of the validation framework, but also decouples business code from the underlying validation logic, reducing development and maintenance costs.

[0071] Figure 7 This is a flowchart illustrating how to determine the result of an unauthorized access check, provided in an embodiment of this application. (Refer to...) Figure 7 The process described above, invoking each target checker and having each target checker verify the parsing results to obtain the over-authority verification result of the request to be verified, includes: S701. Traverse each key-value pair in the parsing result. For the current key-value pair, call the target checker. The target checker verifies the current key-value pair and obtains the verification result of the current key-value pair.

[0072] S702. After completing the verification of all key-value pairs, determine the over-authority verification result of the request to be verified based on the verification results of each key-value pair in the parsing results.

[0073] After obtaining all the parsed key-value pairs, a loop processing mechanism can be started. Each key-value pair is retrieved one by one, and the previously determined target checker is invoked to validate it. For example, the checker can verify the order ID 2023001 against the database or rule engine to determine if the current user truly has the authority to operate on this ID. After processing each key-value pair, a validation result for that key-value pair will be obtained.

[0074] After all key-value pairs in the parsed results have been verified one by one, the result aggregation stage begins. The verification results of all key-value pairs can be collected and comprehensively judged according to preset logic to ultimately determine the overall request's privilege escalation result, thereby deciding whether the business request can continue to execute.

[0075] The preset logic can be a veto system, where if any key-value pair fails to be verified, the entire pair is judged as exceeding the authority; or a pass system, where all key-value pairs fail before being judged as exceeding the authority; or a system where if the number of failed verifications reaches a preset proportion, the pair is judged as exceeding the authority. The specific method is not limited here.

[0076] In this embodiment of the application, the overall verification task is decomposed into independent traversal verification of each key-value pair, and the results are summarized after all verifications are completed, thereby realizing the modularization and standardization of the verification logic.

[0077] Figure 8This is a flowchart illustrating how to determine the verification result of a current key-value pair, as provided in an embodiment of this application. (Refer to...) Figure 8 The process described above, invoking the target checker to validate the current key-value pair and obtaining the validation result, includes: S801. If the target inspector is a database inspector, then construct a database query statement based on the current key-value pairs.

[0078] Among them, the database inspector is a component used to verify data ownership or legitimacy by interacting with the database; the database query statement refers to the standardized instructions used to retrieve data from the database.

[0079] S802. Execute the database query statement. If the data query result is not empty, the current key-value pair is determined to be validated successfully. If the data query result is empty, the current key-value pair is determined to be validated unsuccessfully.

[0080] If the database returns a non-empty query result, meaning that a record matching the criteria was found, it indicates that the current user does indeed have a legitimate ownership relationship with the resource. Therefore, the key-value pair can be determined to have passed the validation.

[0081] If the database returns an empty query result, meaning no record was found, it indicates that the resource the current user is trying to access does not belong to him or that the resource does not exist at all. Therefore, the key-value pair can be determined to have failed to be validated, thus triggering an unauthorized access interception.

[0082] In another possible implementation, the process of calling the target checker to validate the current key-value pair and obtaining the validation result of the current key-value pair further includes: If the target checker is a custom checker, then the corresponding validation interface of the custom checker is called, the current key-value pair is used as the input parameter of the validation interface, and the validation result of the current key-value pair is returned by the validation interface.

[0083] Optionally, a custom checker refers to a verification component that is written and implemented by developers according to specific and complex business scenarios, such as complex scenarios that require calling third-party risk control systems, performing complex mathematical operations, or querying across multiple heterogeneous systems, which cannot be accomplished by simple database queries; the verification interface refers to the standard method or function entry point exposed by the custom checker to receive data and return verification conclusions.

[0084] In one possible implementation, the custom checker does not construct SQL statements. Instead, it directly finds the pre-written validation interface through reflection or API calls. It then packages the current key-value pair and passes it directly to this interface as input parameters. After executing its unique and complex business logic internally, the custom checker returns the final validation result (pass or fail) to the validation framework.

[0085] In this embodiment, by introducing a custom checker and verification interface mechanism, the limitation of traditional verification frameworks, which can only handle fixed logic, is overcome. Developers can encapsulate complex, non-standardized business verification logic in custom checkers and interface with the main verification framework through standard interfaces, thereby improving the scalability of the checker.

[0086] Based on the same inventive concept, this application also provides a horizontal overreach verification system corresponding to the horizontal overreach verification method. Since the principle of the system in this application is similar to the horizontal overreach verification method described above in this application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0087] Figure 1 This diagram illustrates the structure of a lateral overreach verification system provided in an embodiment of this application. The system includes an annotator 101, a verifier 102, a parser 103, and a checker 104.

[0088] Verifier 102 is used to obtain the verification request of the current business, which includes multiple parameter objects; The verifier 102 is used to determine at least one target parser 103 based on the request to be verified, and to call each target parser 103. Each target parser 103 parses the request to be verified and obtains the parsing result of the request to be verified. The parsing result includes multiple key-value pairs, where the key of each key-value pair is a parameter object and the value of each key-value pair is the parameter value of the parameter object. Verifier 102 is used to determine at least one target checker 104 based on the request to be verified, and to call each target checker 104 to verify the parsing result and obtain the over-authority verification result of the request to be verified.

[0089] Optionally, the verifier 102 is specifically used for: Determine the annotation information in the request to be verified. The annotation information is pre-annotated on the request parameter object corresponding to the request to be verified by the annotator 101 during the development phase. The annotation information includes: column name configuration information, value list configuration information, and prompt information. The target parser 103 corresponding to the request to be verified is determined based on the value list configuration information.

[0090] Optionally, the value list configuration information includes multiple expressions, each of which is used to indicate the data source of each input parameter. Each expression is pre-configured with a corresponding parser. The parser 103 includes at least: a user context parser, a current object parser, a current value parser, and a constant parser. Optionally, the verifier 102 is specifically used for: Iterate through each expression in the value list configuration information, and for the current expression, determine the parser for the current expression based on the prefix of the current expression and the pre-built mapping relationship between expressions and parsers; After the traversal is completed, all the determined parsers are used as the target parser 103 corresponding to the request to be verified.

[0091] Optionally, the verifier 102 is specifically used for: If the target parser 103 is a user context parser, then the target parser is called, and the target parser parses the login context information in the request to be verified, obtains the first parsed value corresponding to the login context information, and uses the login context information as the key and the first parsed value as the value to form a key-value pair as an item in the parsing result; If the target parser 103 is the current object parser, then the current object parser is called, and the current object parser parses the request parameter object of the request to be verified, obtains the second parsed value, and uses the request parameter object as the key and the second parsed value as the value to form a key-value pair as an item in the parsing result; If the target parser 103 is the current value parser, then the current value parser is called. The current value parser parses the current expression in the request to be verified, obtains the third parsed value, and uses the current expression as the key and the third parsed value as the value to form a key-value pair as an item in the parsing result. If the target parser 103 is a constant parser, then the constant parser is called to parse the current expression, obtain the fourth parsing value, and use the current expression as the key and the fourth parsing value as the value to form a key-value pair as one item in the parsing result.

[0092] Optionally, the verifier 102 is specifically used for: Determine the annotation information in the request to be verified. The annotation information includes: the configuration information of inspector 104. The checker 104 indicated by the checker 104 configuration information is used as the target checker 104 corresponding to the request to be verified.

[0093] Optionally, the verifier 102 is specifically used for: Iterate through each key-value pair in the parsing result. For the current key-value pair, call the target checker 104. The target checker 104 verifies the current key-value pair and obtains the verification result of the current key-value pair. After verifying all key-value pairs, the over-authority verification result of the request to be verified is determined based on the verification results of each key-value pair in the parsing results.

[0094] Optionally, the verifier 102 is specifically used for: If the target inspector 104 is a database inspector, then construct a database query statement based on the current key-value pairs; If the database query result is not empty, the validation result of the current key-value pair is determined to be valid; otherwise, the validation result of the current key-value pair is determined to be invalid.

[0095] Optionally, the verifier 102 is specifically used for: If the target inspector 104 is a custom inspector, then the corresponding verification interface of the custom inspector is called, the current key-value pair is used as the input parameter of the verification interface, and the verification result of the current key-value pair returned by the verification interface is obtained.

[0096] This application's embodiments centralize the previously scattered verification logic by introducing an independent validator. The validator can call the target parser to automatically break down complex business requests into standard key-value pairs, and then call the target checker to perform precise verification on these key-value pairs. This design completely decouples permission verification from core business code, eliminating the need for developers to repeatedly write verification code in each business method. This significantly reduces code coupling and redundancy, and improves the reusability of verification logic and the maintainability of the system.

[0097] Figure 9 This illustration shows a schematic diagram of an electronic device provided in an embodiment of this application, including: a processor 901, a storage medium 902, and a bus 903. The storage medium 902 stores machine-readable instructions executable by the processor 901. When the electronic device runs a lateral access violation verification method as described in the embodiment, the processor 901 communicates with the storage medium 902 via the bus 903. The processor 901 executes the machine-readable instructions, and the preamble of the method item of the processor 901 performs the steps in the above-described lateral access violation verification method.

[0098] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor, wherein the processor performs the steps in the above-described lateral access violation verification method.

[0099] In this embodiment, the computer program, when run by the processor, can also execute other machine-readable instructions to perform other methods as described in the embodiments. For details on the specific execution steps and principles, please refer to the description of the embodiments, which will not be repeated here.

[0100] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0101] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0102] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0103] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0104] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0105] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for horizontal overriding detection, characterized in that, Applied to a validator, the method includes: Obtain the verification request for the current business, which includes multiple parameter objects; At least one target parser is determined based on the request to be verified, and each target parser is invoked to parse the request to be verified, thereby obtaining the parsing result of the request to be verified. The parsing result includes multiple key-value pairs, where the key of each key-value pair is a parameter object, and the value of each key-value pair is the parameter value of the parameter object. At least one target checker is determined based on the request to be verified, and each target checker is invoked to verify the parsing result, thereby obtaining the over-authority verification result of the request to be verified.

2. The method according to claim 1, characterized in that, The step of determining at least one target parser for the request to be verified based on the request to be verified includes: Determine the annotation information in the request to be verified. The annotation information is pre-annotated on the request parameter object corresponding to the request to be verified during the development phase. The annotation information includes: column name configuration information, value list configuration information, and prompt information. The target parser corresponding to the request to be verified is determined based on the value list configuration information.

3. The method according to claim 2, characterized in that, The value list configuration information includes multiple expressions, each of which indicates the data source of each input parameter. Each expression is pre-configured with a corresponding parser, which includes at least: a user context parser, a current object parser, a current value parser, and a constant parser. The step of determining the target parser corresponding to the request to be verified based on the value list configuration information includes: Iterate through each expression in the value list configuration information, and for the current expression, determine the parser of the current expression based on the prefix of the current expression and the pre-built mapping relationship between expressions and parsers; After the traversal is completed, all the determined parsers are used as the target parsers corresponding to the request to be verified.

4. The method according to claim 1, characterized in that, The step of invoking each of the target parsers, and having each target parser parse the request to be verified to obtain the parsing result of the request to be verified, includes: If the target parser is a user context parser, then the target parser is invoked, and the target parser parses the login context information in the request to be verified to obtain the first parsed value corresponding to the login context information. The login context information is used as the key, and the first parsed value is used as the value to form a key-value pair as an item in the parsing result. If the target parser is the current object parser, then the current object parser is invoked, and the current object parser parses the request parameter object of the request to be verified to obtain the second parsed value. The request parameter object is used as the key, and the second parsed value is used as the value to form a key-value pair as one item in the parsing result. If the target parser is the current value parser, then the current value parser is invoked, and the current value parser parses the current expression in the request to be verified to obtain the third parsing value. The current expression is used as the key, and the third parsing value is used as the value to form a key-value pair as an item in the parsing result. If the target parser is a constant parser, then the constant parser is invoked to parse the current expression, obtain the fourth parsing value, and use the current expression as the key and the fourth parsing value as the value to form a key-value pair as one item in the parsing result.

5. The method according to claim 1, characterized in that, The step of determining at least one target checker for the request to be verified based on the request to be verified includes: Determine the annotation information in the request to be verified, the annotation information including: checker configuration information; The checker indicated by the checker configuration information is used as the target checker corresponding to the request to be verified.

6. The method according to claim 1, characterized in that, The step of invoking each of the target checkers, and having each target checker verify the parsing result to obtain the over-authority verification result of the request to be verified, includes: Iterate through each key-value pair in the parsing result. For the current key-value pair, call the target checker to verify the current key-value pair and obtain the verification result of the current key-value pair. After verifying all key-value pairs, the over-authority verification result of the request to be verified is determined based on the verification results of each key-value pair in the parsing results.

7. The method according to claim 6, characterized in that, The step of invoking the target inspector to validate the current key-value pair and obtain the validation result of the current key-value pair includes: If the target inspector is a database inspector, then a database query statement is constructed based on the current key-value pair; If the database query statement is executed and the data query result is not empty, then the validation result of the current key-value pair is determined to be valid; if the data query result is empty, then the validation result of the current key-value pair is determined to be invalid.

8. The method according to claim 6, characterized in that, The step of invoking the target inspector to validate the current key-value pair and obtain the validation result of the current key-value pair includes: If the target checker is a custom checker, then the corresponding verification interface of the custom checker is called, the current key-value pair is used as the input parameter of the verification interface, and the verification result of the current key-value pair returned by the verification interface is obtained.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of a lateral access violation verification method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of a lateral access violation verification method as described in any one of claims 1 to 8.

Images