Script access object white list verification method and device, medium and program product

Abstract

The invention provides a script access object white list verification method and device, a medium and a program product, and the method comprises the steps: obtaining a to-be-verified service script, analyzing the service script, and generating a grammar structure representation reflecting script execution semantics; based on the grammar structure representation, identifying script access objects actually participating in execution in the service script from grammar nodes related to script execution semantics; obtaining an access object white list, wherein the access object white list comprises a script access object set allowed to be used in the service script; and comparing the script access object with the access object white list to obtain an abnormal script access object which is not covered by the access object white list. Accurate and controllable verification of the accessible object range of the service script is achieved, the safety and reliability of the service script configuration process are improved, meanwhile, the operation risk of the service script in the production environment is reduced, and the method and device are suitable for application scenes with flexible service logic configuration and high access control requirements.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, device, medium and program product for verifying a whitelist of script access objects. Background Technology

[0002] As enterprises continuously improve their informatization and digitalization levels, more and more business systems are introducing rule engines, expression engines, or scripting language mechanisms to achieve flexible configuration and rapid adjustment of business logic. For example, in application scenarios such as risk control, billing, marketing, and approval, business logic is usually configured in the form of scripts. When the scripts are executed, they can access predefined business variables in the system or call business methods provided by the system to complete the corresponding business processing flow.

[0003] To improve the flexibility and configuration efficiency of business systems, existing technologies typically allow business personnel or configuration personnel to directly write and maintain the aforementioned business scripts, and perform a certain degree of validation on the scripts before saving or executing them. However, in actual production environments, as the scale of business systems expands, the number of business variables and methods accessible to scripts gradually increases, and their business semantics and applicable scenarios become more complex. Because existing technologies lack effective technical constraints on the scope of use of business variables and methods in scripts, business personnel are prone to misusing business variables or methods that are not open to them or are not applicable to the current business scenario when customizing scripts.

[0004] The aforementioned problems arise because existing script validation mechanisms primarily focus on syntactic correctness, making it difficult to identify the actual business variables and methods used in the script. Due to the lack of validation methods combined with access control, the scope of use of business variables and methods in the script is difficult to effectively determine during the validation phase, thus hindering the security and controllability of the business script configuration process. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a script access object whitelist verification method, device, medium, and program product, which at least solves the problem in existing technologies that it is difficult to identify and restrict the scope of accessible objects in the script during the script verification stage, thereby causing the script to misuse unauthorized business variables or business methods.

[0006] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0007] Firstly, some embodiments of this application provide a script access object whitelist verification method, including:

[0008] Obtain the business script to be verified and parse the business script to generate a syntactic structure representation that reflects the semantics of script execution;

[0009] Based on the syntactic structure representation, the script access objects that actually participate in the execution of the business script are identified from the syntactic nodes related to script execution semantics;

[0010] Obtain the access object whitelist, which includes a set of script access objects allowed to be used in the business script;

[0011] The script access object is compared with the access object whitelist to obtain the abnormal script access object that is not covered by the access object whitelist.

[0012] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0013] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform a script access object whitelist verification method as described above.

[0014] Thirdly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, wherein the computer program and / or instructions, when executed by a processor, implement the script access object whitelist verification method as described above.

[0015] Fourthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the script access object whitelist verification method as described above.

[0016] Compared with existing technologies, the solution provided in this application significantly improves the accuracy of script access object identification by parsing the business script and constructing a syntactic structure representation reflecting the script execution semantics. This is achieved at the syntactic level by accurately identifying the script access objects actually involved in the execution of the business script, rather than relying solely on coarse-grained verification based on text matching or static rules. Furthermore, by comparing the identified script access objects with a predefined access object whitelist, abnormal script access objects that do not meet access control requirements can be promptly detected during the script saving or publishing stage. This prevents operational anomalies or security risks caused by the misuse of unauthorized objects during business script operation. Through this technical solution, precise and controllable verification of the scope of accessible objects for business scripts is achieved, improving the security and reliability of the business script configuration process while reducing the operational risks of business scripts in production environments. This solution is suitable for application scenarios that require flexible configuration of business logic and have high access control requirements. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is one of the flowcharts illustrating a script access object whitelist verification method provided in this application embodiment;

[0019] Figure 2 This is a second flowchart illustrating a script access object whitelist verification method provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0021] 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Some embodiments of this application relate to a script access object whitelist verification method, see reference Figure 1 , Figure 2 As shown, the method may include the following steps:

[0023] Step S1: Obtain the business script to be verified and parse the business script to generate a syntactic structure representation that reflects the semantics of script execution.

[0024] Business scripts are script programs used to describe business rules or business logic in a business system, supporting flexible configuration and dynamic adjustment of business processes. Business scripts can be written in scripting languages ​​and parsed or executed by script parsing or execution components in the business system, thereby enabling dynamic configuration of business logic without modifying the underlying system code.

[0025] In some embodiments, the business script can be implemented as an expression script based on an expression language. This allows for the dynamic calculation of business rules by parsing and executing expressions containing logical judgments, arithmetic operations, variable references, or method calls. For example, the expression script can be written based on expression languages ​​such as JEXL, MVEL, or SpEL.

[0026] In practical applications, business scripts can be incorporated into rule engines, which then invoke or execute them based on predefined rule trigger conditions. A rule engine is a middleware component that separates business rules from program code. It automates the processing of business rules by parsing and executing predefined "condition-action" decision logic. With the help of a rule engine, business rules can be maintained through scripts or rule configurations, enabling dynamic adjustments to business rules without modifying the program code.

[0027] In a rule engine, the expression parsing component can serve as one of the execution units, used to parse and execute expressions contained in rule conditions or rule actions. As an optional implementation, the expression parsing component can be based on the JEXL expression engine. The JEXL expression engine supports parsing expressions with Java-like syntax and allows business systems to define variables and methods accessible to scripts as needed, thus providing flexible expressive capabilities for business scripts.

[0028] As an optional embodiment, step S1 specifically includes:

[0029] Step S101: Perform lexical and syntactic analysis on the business script to construct an initial syntactic structure representation containing multi-level syntactic nodes.

[0030] After obtaining the business script to be verified, the script text is first used as an input string stream to perform lexical analysis. The character sequence is divided into a set of lexical unit tokens arranged in the order of appearance. Each token carries at least the token type, literal, start and end position index (line number, column number, or offset), and the boundary information of the statement it belongs to. Token types include, but are not limited to, identifiers, keywords, constants, operators, delimiters, and parentheses.

[0031] After obtaining the token sequence, further syntax analysis is performed. The syntax analysis process reduces the token sequence to multi-level syntax nodes according to preset syntax rules, and establishes parent-child hierarchical relationships and sibling order relationships between nodes to construct an initial syntax structure representation. This initial syntax structure representation can be implemented using a tree or graph data structure. Its syntax nodes must at least include node type, the token range covered by the node, node attribute fields, and pointers to child nodes, transforming the script text from a linear sequence of characters or tokens into a hierarchical set of syntax nodes and their relationships.

[0032] Parsing business scripts to generate a syntactic structure representation reflecting the script's execution semantics can be achieved using an Abstract Syntax Tree (AST) mechanism. An AST transforms the source code or expressions corresponding to a business script into a structured tree-like data structure. It performs lexical analysis on the script, breaking the script text down into semantically meaningful syntactic units. Further, through syntactic analysis, these units are organized into relational syntactic nodes according to predefined syntactic rules. This preserves the core syntactic logic and hierarchical relationships of the script while removing redundant information unrelated to execution semantics, such as spaces and separators, allowing the implicit execution semantics of the business script to be expressed in an explicit syntactic structure.

[0033] As an optional embodiment, step S101 specifically includes:

[0034] Step S1011: Use the script parsing engine to perform lexical and syntactic analysis on the business script, and access the syntactic data object generated during the parsing process through reflection without changing the existing parsing process and execution logic of the script parsing engine.

[0035] Step S1012: Obtain the syntax nodes and relationships between nodes in the syntax data object to construct an initial syntax structure representation containing multi-level syntax nodes.

[0036] In this embodiment, after obtaining the business script to be verified, a script parsing engine is invoked to perform lexical and syntactic analysis on the business script. The script parsing engine is used to parse the business script according to preset script syntax rules. Internally, during the parsing process, it generates a syntax data object to describe the script's syntactic structure. This syntax data object carries the intermediate structure information formed during the parsing process, including syntax node instances, node attribute information, and the relationships between nodes.

[0037] To avoid impacting the existing parsing process and execution logic of the script parsing engine, this embodiment does not obtain grammatical structure information by modifying the parsing engine source code or inserting intrusive parsing logic. Instead, after parsing is complete, it accesses the grammatical data objects generated during the parsing process through reflection. Specifically, after the parsing engine completes lexical and syntactic analysis, it obtains the object instance used by the parsing engine to store grammatical data based on runtime object access capabilities, and reads the data fields or access interfaces related to the grammatical structure. This method allows for the acquisition of grammatical structure data formed during the parsing phase without altering the parsing engine's behavior or affecting the script parsing results, thus achieving non-intrusive collection of script grammatical information.

[0038] After obtaining the grammar data object through reflection, the grammar data object undergoes structured parsing. A set of grammar nodes is extracted from the grammar data object, and the node type information, node attribute information, and relationship information between nodes are obtained. Specifically, the node type information characterizes the functional role of the grammar node in the grammatical structure, the node attribute information describes the corresponding identifier content, expression features, or operation information of the grammar node, and the relationship between nodes characterizes the parent-child, sibling, or sequential relationships between grammar nodes.

[0039] In one implementation, the root node of the grammar data object is used as the starting node. The lower-level grammar nodes are recursively traversed according to the relationships between nodes, and the grammar nodes and their relationships obtained during the traversal are organized into a unified data structure representation. This data structure representation can be implemented using a tree structure, graph structure, or other data structure forms that support multi-level hierarchical relationships, to fully represent the grammar hierarchy and compositional relationships of the business script. Through the above processing, an initial grammar structure representation containing multi-level grammar nodes is constructed, transforming the grammar information of the business script from the implementation details inside the parsing engine into structured grammar data that can be uniformly accessed and processed by subsequent steps, providing basic data support for semantic analysis, access object identification, and whitelist verification.

[0040] Step S102: Based on the control structure, expression structure and scope relationship in the business script, perform semantic classification on the syntax nodes in the initial syntax structure representation to distinguish candidate semantic nodes used to trigger the parsing of the script access object.

[0041] In this embodiment, after obtaining the initial grammatical structure representation containing multi-level grammatical nodes, the grammatical nodes in the grammatical structure representation are further subjected to semantic analysis and classification to distinguish candidate semantic nodes used to trigger the parsing of script access objects.

[0042] First, control structure nodes describing the script execution flow are identified from the syntactic structure representation. Based on the conditional statements, branching relationships, or looping relationships corresponding to these control structure nodes, the logical position of each syntactic node in the script's control flow is determined. This process identifies syntactic nodes located in conditional branches, loop bodies, or sequential execution paths, providing a control flow context for semantic determination.

[0043] Furthermore, by considering the semantic role of syntax nodes within the expression structure, we analyze whether syntax nodes carry access semantics such as variable references, method calls, or object access. Structural nodes that are only used to organize the syntax structure or describe the control flow are excluded from the candidate pool; while syntax nodes within the expression structure that possess access or computation semantics are marked as nodes with potential script access object resolution value.

[0044] Furthermore, it considers the scope relationship of the syntax node to determine its visibility and validity in the current script context. Specifically, based on the scope hierarchy to which the syntax node belongs, it analyzes whether the corresponding variable or method has a definition or reference condition within that scope, thereby avoiding misjudging nodes that are only effective in other scopes or exist only as syntax placeholders as candidate nodes.

[0045] By performing joint semantic analysis on control structures, expression structures, and scope relationships, semantic nodes related to script access object identification are filtered out from a large number of grammatical nodes that are only used for grammatical organization or control flow description, thereby reducing the computational complexity of subsequent analysis and improving parsing accuracy.

[0046] Step S103: Based on the conditional constraints, calling context and data dependencies of candidate semantic nodes in the script control flow, determine the effective semantic nodes related to script execution semantics.

[0047] After obtaining the set of candidate semantic nodes used to trigger the resolution of the script access object, the execution semantics of the candidate semantic nodes are further determined based on the conditional constraints, calling context and data dependencies of the candidate semantic nodes in the script control flow, so as to identify the effective semantic nodes related to the script execution semantics.

[0048] First, the conditional constraints of candidate semantic nodes are analyzed based on their positional relationship within the script control flow. These constraints describe whether a candidate semantic node is triggered based on a specific condition judgment, branch selection, or loop condition. Based on the conditional expression corresponding to the control structure node, it is analyzed whether the candidate semantic node is in at least one potentially valid execution path. Candidate semantic nodes that appear only in branches where the condition is consistently false or logically unreachable are determined to lack execution reachability.

[0049] After completing the condition constraint analysis, the execution semantics of the candidate semantic nodes are further determined by combining the invocation context information. The invocation context describes the execution environment in which the candidate semantic node exists, including but not limited to the function call hierarchy, expression nesting relationship, or rule triggering scenario. By analyzing whether the candidate semantic node is located in an execution context that can be actually invoked or triggered, candidate semantic nodes that only exist in uninvoked function definitions, untriggered rule branches, or static placeholder structures are excluded.

[0050] Building upon this, the execution validity of candidate semantic nodes is further determined by considering the data dependencies between candidate semantic nodes and between candidate semantic nodes and other syntax nodes. Data dependencies describe whether the data a candidate semantic node depends on is correctly initialized, assigned, or passed along its execution path. Candidate semantic nodes whose dependent data sources do not exist on the execution path or whose dependencies cannot be logically satisfied are deemed to lack execution semantics during actual execution.

[0051] By comprehensively analyzing the conditional constraints, calling context, and data dependencies of candidate semantic nodes in the script control flow, nodes that do not have execution reachability during actual script execution are excluded from the candidate nodes with access semantic potential, thereby accurately characterizing the access behavior that the script may perform at runtime.

[0052] Step S104: Based on valid semantic nodes, construct a syntactic structure representation to characterize the location and access path of the script access object during script execution.

[0053] Specifically, based on the node position information of valid semantic nodes in the initial syntactic structure representation, the occurrence position of each valid semantic node in the script is determined. The node position information includes the hierarchical position of the syntactic node in the syntactic structure, its belonging control structure, and its relative position in the script text, thereby accurately representing the occurrence point of the script access object during script execution.

[0054] Based on the determined node location information, and considering the control flow relationships and data dependencies between valid semantic nodes, access path information for script access objects is constructed. By performing correlation analysis on valid semantic nodes along the script control flow direction, multiple valid semantic nodes that may be triggered consecutively on the same execution path are identified and organized into ordered access paths. The access path characterizes the actual access order and logical relationships of script access objects in a feasible execution scenario.

[0055] In one implementation, the access path can be represented as structured data such as a path sequence, path graph, or path tree, where path nodes correspond to valid semantic nodes, and path edges describe control transfer relationships or dependencies between nodes. This approach enables comprehensive modeling of script access object behavior that may occur during script execution without executing the script itself.

[0056] Through the above processing, discrete effective semantic nodes are transformed into a structured execution semantic model that can reflect the script execution behavior, so as to obtain a syntactic structure representation of the location and access path of the script access object during the script execution process. This makes the parsing of the script access object no longer limited to the level of a single syntactic node, but based on the complete execution path semantics for unified analysis, thereby providing structured semantic support for script access object identification, whitelist verification and anomaly localization.

[0057] Through steps S101-S104, the script is analyzed and modeled based on its syntactic structure and execution semantic constraints without relying on the actual execution results of the business script. This avoids misjudgments caused by judging solely based on static text, and effectively identifies the access behaviors that actually participate in the execution of the script. By constructing a syntactic structure representation containing multi-level syntactic nodes, and combining control structures, expression structures, and scope relationships to semantically classify syntactic nodes, it effectively avoids misidentifying nodes used only for syntactic organization or flow control as access nodes. Furthermore, based on conditional constraints, calling context, and data dependencies, the execution reachability of candidate semantic nodes is determined, retaining only valid semantic nodes that may be actually triggered under at least one feasible execution path. Based on this, a syntactic structure representation is constructed to characterize the location and access path of script access objects, making the identification results of script access objects closer to the actual execution semantics. This provides an accurate and traceable semantic foundation for access object whitelist verification, abnormal access location, and risk warning, effectively improving the accuracy, security, and controllability of the script verification process.

[0058] Step S2: Based on the syntactic structure representation, identify the script access objects that actually participate in the execution of the business script from the syntactic nodes related to the script execution semantics.

[0059] The syntactic structure constructed in step S1 is mainly used to characterize the hierarchical relationship of the business script's syntax and the execution reachability of each syntax node in the script's control flow. The valid semantic nodes identified in this stage only indicate the location where access behavior may occur during script execution, but do not directly correspond to specific business access object types or object identifiers. Therefore, in step S2, under the determined execution reachability constraints, the valid semantic nodes are further parsed. By combining the node type, node attribute information, and its contextual relationship in the syntactic structure, the access semantics carried by the syntax nodes are refined and parsed, thereby distinguishing different types of access behaviors such as variable access, method calls, or object attribute access.

[0060] As an optional embodiment, step S2 specifically includes:

[0061] Step S201: Based on the grammatical structure representation, traverse the set of grammatical nodes containing multi-level grammatical nodes, and filter out the grammatical nodes related to the semantics of script accessing objects. The grammatical nodes include: grammatical nodes used to represent variable reference semantics, grammatical nodes used to represent method call semantics, and grammatical nodes used to represent object property access or member access semantics.

[0062] Specifically, based on the grammatical structure representation, a systematic traversal process is performed on the set of grammatical nodes containing multi-level grammatical nodes. The traversal starts with the root node in the grammatical structure representation and visits each lower-level grammatical node sequentially according to the hierarchical relationships between nodes. The traversal method can employ depth-first search or breadth-first search to ensure complete coverage of all levels of grammatical nodes in the grammatical structure. When traversing each grammatical node, its node type information is first read to determine its basic semantic role in the grammatical structure. Simultaneously, combined with the node's positional relationship in the grammatical structure representation and the type information of its parent and child nodes, its functional role in the script's grammatical structure is determined. When the semantic role of a grammatical node indicates that it may carry variable reference semantics or method call semantics, the grammatical node is selected as a grammatical node related to the semantics of the script's accessed objects.

[0063] The syntax nodes related to script access object semantics include, but are not limited to, the following categories: One category is syntax nodes representing variable reference semantics, which describe the access behavior of reading, participating in calculations, or participating in expression evaluation of variable identifiers in the script; another category is syntax nodes representing method call semantics, which describe the calling behavior of business methods or functions in the script, and their node attributes typically include the method name, parameter list, or call expression structure; and a third category is syntax nodes representing object attribute or member access semantics, which describe the access behavior of object attributes, object fields, or object members in the script. Syntax nodes used only to describe flow control, logical combination, or expression organization structure are not considered for this step.

[0064] In one implementation based on the JEXL expression engine, the aforementioned syntax nodes can correspond to the Identifier node, IdentifierAccess node, and Var node in the abstract syntax tree, respectively. The Identifier node represents the referencing semantics of variable identifiers, the IdentifierAccess node represents the method call semantics in the script, and the Var node represents the declaration or referencing semantics of local variables. During traversal, by reading the node attribute information (including identifier name, access path, call structure, etc.) carried by each syntax node and combining it with its contextual relationship in the syntax structure, the nodes are uniformly filtered to obtain a subset of syntax nodes that are directly related to script access behavior at the syntax structure level.

[0065] Step S202: Based on the positional relationship, conditional constraint relationship, and scope association relationship of the syntax nodes in the script control structure, determine whether the syntax nodes have execution reachability during script execution, and thereby determine the valid syntax nodes related to the script execution semantics.

[0066] In this embodiment, based on the subset of access semantically related syntax nodes obtained in step S201, it is further determined whether each syntax node has execution reachability during the actual script execution process, thereby identifying the valid syntax nodes related to script execution semantics. Execution reachability is used to characterize whether the syntax node can be actually executed or triggered under at least one legal script execution path.

[0067] Specifically, the execution path constraints of syntax nodes are first analyzed from the perspective of control structure. The type of control structure in which the syntax node resides is identified, including conditional branching structures, loop structures, or multi-branch selection structures, and the specific branch position of the syntax node within the corresponding control structure is resolved. If the syntax node is in a conditional branching structure, the conditional expression corresponding to that branch is recorded; if the syntax node is in a loop structure, the loop entry condition and the constraints of the loop control variables are recorded to determine whether the syntax node has a path to be scheduled for execution.

[0068] Secondly, the reachability conditions of syntax nodes are analyzed from the perspective of conditional constraints. Based on the conditional expressions that the syntax nodes depend on, semantic abstraction is performed on the conditional expressions to determine whether there is a possibility that the conditional expressions are true at the logical level. For branch paths that are always false, mutually exclusive, or unsatisfiable, the syntax nodes in the corresponding branches are determined to be execution-unreachable nodes; for branch paths that may be true under at least one combination of conditions, the corresponding syntax nodes are determined to be execution-reachable nodes.

[0069] Then, the validity of the syntax node is analyzed from the perspective of scope association. Combining the scope hierarchy information of the syntax node, it is determined whether the variables or methods involved in the syntax node are resolvable within the current scope. If the variables or methods referenced by the syntax node are not visible or are obscured within their respective scopes, the syntax node is determined to be semantically unreachable; otherwise, the syntax node is retained as a candidate execution node.

[0070] After the above multi-dimensional analysis, a syntax node is determined to be a valid syntax node related to script execution semantics only if it simultaneously satisfies control structure constraints, condition constraints, and scope constraints under at least one legal execution path; otherwise, it is excluded from the set of valid syntax nodes. This effectively eliminates access semantic nodes that exist only in the syntax structure but are unlikely to be triggered during actual execution, thus ensuring that the analysis only targets script access behaviors that may actually occur.

[0071] Step S203: Based on the node type and node attribute information corresponding to the valid syntax node, determine the script access object that actually participates in the execution of the business script.

[0072] As an optional embodiment, step S203 specifically includes:

[0073] Step S2031: Based on the node type and node attribute information of the valid syntax nodes, perform semantic mapping processing on the valid syntax nodes and parse them into variable access objects and method call objects.

[0074] Specifically, for valid syntax nodes whose node type represents variable reference semantics or object attribute access / member access semantics, they are mapped to variable access objects; for valid syntax nodes whose node type represents method call semantics, they are mapped to method call objects. During the mapping process, the system combines the node attribute information carried by the syntax node for judgment. The node attribute information includes at least identifier text, access expression structure, or call structure identifier, which is used to determine the access object category corresponding to the syntax node.

[0075] In one implementation, when the valid syntax node is an Identifier node or a Var node, it is parsed into a variable access object, and the variable identification information corresponding to the variable access object is recorded. When the valid syntax node is an IdentifierAccess node, it is parsed into a method call object, and the method identification information corresponding to the method call object is recorded. Through the above semantic mapping process, the node information at the syntax structure level is uniformly converted into an object representation at the script access object level.

[0076] Step S2032: Based on the variable access object and the method call object, extract the corresponding identifier name, access path and call parameter information respectively, and perform aggregation processing on the variable access object and the method call object according to the preset data structure to generate the variable call list and the method call list.

[0077] Specifically, for variable access objects, the variable identifier name and its access path information in the script are extracted from the corresponding valid syntax node; for method call objects, the method name, call path, and parameter structure information related to the call are extracted from the corresponding valid syntax node. Parameter structure information may include the number of parameters, parameter positional relationships, or parameter type descriptions, used to characterize the call features of the method call in the script.

[0078] After extraction, the extracted attribute information is structured and encapsulated, unit by unit for variable access objects and method call objects. Multiple variable access objects are aggregated according to variable identifiers to form a variable call list; multiple method call objects are aggregated according to method identifiers to form a method call list. The variable call list and method call list are used to uniformly represent the variable access behavior and method call behavior involved in the execution semantic constraints of the business script.

[0079] Through steps S201-S203, this embodiment establishes a clear mapping relationship between the syntactic structure level and the execution semantic level, enabling accurate identification of potential access behaviors during actual execution from business scripts. By filtering the access semantics of multi-level syntactic nodes in the syntactic structure representation, only syntactic nodes carrying variable references, object attribute access, or method call semantics are retained, avoiding misidentification of syntactic nodes used only for flow control or expression organization as access nodes. Furthermore, by combining the position of control structures, conditional constraints, and scope relationships to determine the execution reachability of syntactic nodes, access semantic nodes that cannot be triggered under any legal execution path are effectively eliminated. On this basis, all valid syntactic nodes that are execution-reachable are uniformly mapped to variable access objects and method call objects, generating variable call lists and method call lists that reflect the true execution semantics of the business script. Through the above processing, potential access behaviors in the script can be accurately located and expressed in a structured form, reducing the risk of misjudgment caused by static syntactic analysis and improving the accuracy and reliability of script access object identification.

[0080] Step S3: Obtain the access object whitelist, which includes a set of script access objects that are allowed to be used in the business script.

[0081] As an optional embodiment, step S3 specifically includes:

[0082] Step S301: Obtain whitelist configuration information for describing script access control rules. The whitelist configuration information includes multiple access control rules. Each access control rule is used to define the scope of script access objects that are allowed to be accessed under at least one business script type, business scenario, or execution context.

[0083] Specifically, in one implementation, business variables and methods accessible to business personnel are pre-maintained in a structured configuration to form a whitelist configuration. The whitelist configuration includes multiple access control rules, each defining the scope of script access objects that a business script is allowed to access under at least one business script type, business scenario, or execution context.

[0084] In one implementation, each access control rule includes at least: rule application condition information and rule-allowed access object definition information. The rule application condition information describes the prerequisites for the access control rule to take effect, which may include, but is not limited to, script type identifiers, business module identifiers, business scenario identifiers, execution environment identifiers, or other contextual features that can characterize the script's usage scenario. The rule-allowed access object definition information describes that the access control rule takes effect when the script characteristics of the business script meet the corresponding rule application conditions, thereby limiting the set of script access objects that the business script is allowed to access. The set of script access objects may include variable access objects, method call objects, or a combination of both.

[0085] In one alternative implementation, the whitelist configuration information can be maintained in a structured configuration format, such as storing it in the form of a rule table, configuration file, or configuration data object. Each access control rule records its applicable conditions and the corresponding scope of access objects in a structured field, thereby supporting independent configuration, dynamic adjustment, and on-demand loading of access control rules.

[0086] Step S302: Based on the script feature information of the business script, dynamically select access control rules that meet the applicable conditions from multiple access control rules in the whitelist configuration information, and generate an access object whitelist that is compatible with the business script based on the access control rules.

[0087] In this embodiment, the script characteristic information of the business script is first obtained. The script characteristic information is used to characterize the usage background and applicable environment of the business script, and may include, but is not limited to: the script type identifier to which the business script belongs, the business module identifier, the business scenario identifier, the execution environment identifier, and context parameter information related to script execution. The above-mentioned script characteristic information may be provided by the business system during the script submission, configuration, or invocation stage, or may be automatically determined by the script management module based on the script's configuration location, invocation entry point, or runtime parameters.

[0088] After obtaining the script characteristic information of the business script, rule matching processing is performed on the whitelist configuration information obtained in step S301. In one implementation, when the script characteristic information of the business script meets the rule application conditions of a certain access control rule, the access control rule is marked as a valid rule; when the rule application conditions are not met, the corresponding access control rule is ignored. Through the above matching process, a set of access control rules that match the applicable scenario of the current business script is selected from multiple access control rules.

[0089] After determining the applicable set of access control rules, the allowed script access objects are summarized and integrated based on the allowed access object information defined in the access control rule set. This involves extracting the corresponding variable access object definition information and method call object definition information from each access control rule, merging access objects with duplicate definitions, and generating an access object whitelist that fits the current business script. The access object whitelist is used to clearly define the scope of script access objects allowed in the current business script execution scenario.

[0090] Through steps S301-S302, during the script verification phase, access control rules matching the applicable scenario of the current business script are dynamically selected from multiple pre-configured access control rules based on the script characteristic information of the business script, and an access object whitelist adapted to the business script is generated accordingly. Compared with the static, unified whitelist configuration method in the prior art, the embodiments of this application can dynamically generate an access object whitelist adapted to the business script based on the actual characteristics and usage scenarios of the business script, without relying on a static fixed whitelist configuration, thereby improving the flexibility and scenario adaptability of script access control.

[0091] Furthermore, by associating the generation process of the access object whitelist with the type of business script, business scenario, and execution context conditions, different business scripts can correspond to different allowed access object ranges in different usage scenarios. This avoids security risks or configuration restrictions caused by whitelist configurations that are too broad or too narrow, and enhances the granularity and maintainability of script access control policies.

[0092] Step S4: Compare the script access object with the access object whitelist to obtain the abnormal script access object that is not covered by the access object whitelist.

[0093] Specifically, a consistency check is performed between the script access objects actually executed in the business script and the access object whitelist to identify abnormal script access objects that do not conform to access control rules. The set of script access objects identified in step S2 can include variable access objects and method call objects. Each script access object contains at least identification information to uniquely identify the access object, such as identifier name, access path, method name, parameter characteristics, or object type information. The access object whitelist generated in step S3 contains the range of script access objects that the current business script is allowed to access under the corresponding business scenario or execution context. Each whitelist item also includes at least identification information describing the allowed access object and may further include rule attributes such as access level, invocation method, parameter constraints, or usage conditions.

[0094] During the comparison process, each script access object in the script access object set is matched against a whitelist entry in the access object whitelist. Matching can be based at least on the consistency of object identification information, such as comparing variable names, method names, or whether the access path meets the access rules defined in the whitelist. In scenarios with hierarchical access or nested objects, a comprehensive match can be made by combining access path prefixes, object type relationships, or call context information. Script access objects that exist in the script access object set but fail to match a corresponding whitelist entry are identified as abnormal script access objects. Abnormal script access objects indicate that the access behavior is outside the permitted scope of the current business script, potentially corresponding to unauthorized variable access, illegal method calls, or object usage that does not conform to scenario constraints.

[0095] In one implementation, the identified abnormal script access objects can be uniformly summarized and a list of abnormal access objects can be generated. This list of abnormal access objects can be used for subsequent script verification result output, problem prompts, risk interception, or audit records.

[0096] In step S4, obtaining the abnormal script access object also includes:

[0097] Obtain the object description information corresponding to the abnormal script access object. The object description information is used to characterize the business semantics, functional purpose, or usage constraints of the script access object.

[0098] Based on the object description information, a verification prompt message is generated to indicate the cause of the exception and the correction suggestion, and the verification prompt message is associated with the exception script access object and output.

[0099] In one implementation, after identifying an abnormal script access object, the object description information corresponding to the abnormal script access object is retrieved from an object description information database based on the object identifier information of the abnormal script access object. The object description information database is used to centrally store description information related to script access objects, so as to achieve unified management and mapping between script access object identifiers and their business semantics, functional uses, and usage constraints.

[0100] The object description information repository can be pre-maintained by developers or system maintenance personnel during the system configuration phase and stored in a structured data format. To facilitate the categorization and management of different types of script access objects, corresponding object description information tables can be created within the object description information repository based on the type of the script access object. For example, for variable access objects, a variable object description information table is created in the object description information repository to store descriptive information related to business variables accessible by scripts. As shown in Table 1, in the example of the variable object description information table, each record corresponds to a business variable accessible by scripts, and its fields include at least: variable name field, variable type field, variable business meaning field, and variable usage constraint field. Through this variable object description information table, the data type, business meaning, and allowed usage conditions of each business variable can be clearly described.

[0101] Table 1 Example of variable object description

[0102]

[0103] For method call objects, a method object description information table is established in the object description information repository to store descriptive information related to business methods that can be called by scripts. As shown in Table 2, each record in the method object description information table corresponds to a business method, and its fields include at least: method name field, method function description field, method input parameter definition field, method return value description field, and method call constraints or usage example field, so as to realize the semantic interpretation and usage restriction description of method call behavior in scripts.

[0104] Table 2 Example of method object description

[0105]

[0106] During the business script saving or verification phase, when an abnormal script access object is detected in the script, the object description information in the object description information library is further used to generate verification prompt information corresponding to the abnormal script access object. The verification prompt information not only indicates the reason for the abnormality that the script access object is not covered by the access object whitelist, but also, in combination with the business semantic description and usage constraints in the object description information, provides business personnel with an understandable explanation of the abnormality and suggestions for correction.

[0107] By combining the object description information database with the script verification process, even if business personnel cause access anomalies in the script due to negligence or insufficient understanding of the business objects during the script writing process, the system can automatically identify the anomaly during the script saving or verification stage, and output clear and understandable prompts to business personnel based on the object description information, thereby helping business personnel to quickly locate the problem and complete the correction.

[0108] In summary, the script access object whitelist verification method provided in this application significantly improves the accuracy of script access object identification by parsing the business script and constructing a syntactic structure representation reflecting the script execution semantics, thereby accurately identifying the script access objects actually involved in the execution of the business script at the syntactic level, rather than relying solely on coarse-grained verification based on text matching or static rules. Furthermore, by comparing the identified script access objects with a predefined access object whitelist, abnormal script access objects that do not meet access control requirements can be promptly detected during the script saving or publishing stage, preventing operational anomalies or security risks caused by the misuse of unauthorized objects during business script operation. Through the above technical solution, precise and controllable verification of the scope of accessible objects for business scripts is achieved, improving the security and reliability of the business script configuration process, while reducing the operational risks of business scripts in production environments. This method is suitable for application scenarios that require flexible configuration of business logic and have high access control requirements.

[0109] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0110] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0111] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform a script access object whitelist verification method as provided in any one or more of the above embodiments. Figure 3An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0112] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0113] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0114] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0115] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements a script access object whitelist verification method provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0116] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0117] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0118] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0119] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0120] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0121] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0122] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0123] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0125] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for verifying a whitelist of objects accessed by a script, characterized in that, include: Obtain the business script to be verified and parse the business script to generate a syntactic structure representation that reflects the semantics of script execution; Based on the syntactic structure representation, the script access objects that actually participate in the execution of the business script are identified from the syntactic nodes related to script execution semantics; Obtain the access object whitelist, which includes a set of script access objects allowed to be used in the business script; The script access object is compared with the access object whitelist to obtain the abnormal script access object that is not covered by the access object whitelist.

2. The script access object whitelist verification method according to claim 1, characterized in that, The step of obtaining the business script to be verified and parsing the business script to generate a syntactic structure representation reflecting the script execution semantics includes: Lexical and syntactic analysis are performed on the business script to construct an initial syntactic structure representation containing multi-level syntactic nodes; Based on the control structure, expression structure, and scope relationship in the business script, the syntax nodes in the initial syntax structure representation are semantically classified to distinguish candidate semantic nodes used to trigger the parsing of the script access object. Based on the conditional constraints, calling context, and data dependencies of the candidate semantic nodes in the script control flow, valid semantic nodes related to script execution semantics are determined. Based on the effective semantic nodes, a syntactic structure representation is constructed to characterize the location and access path of the script access object during script execution.

3. The script access object whitelist verification method according to claim 2, characterized in that, The steps of performing lexical and syntactic analysis on the business script to construct an initial syntactic structure representation containing multi-level syntactic nodes include: The business script is subjected to lexical and syntactic analysis using a script parsing engine. Without changing the existing parsing process and execution logic of the script parsing engine, the syntactic data object generated during the parsing process is accessed through reflection. Obtain the syntax nodes and relationships between nodes in the syntax data object to construct an initial syntax structure representation containing multi-level syntax nodes.

4. The script access object whitelist verification method according to claim 1, characterized in that, The step of identifying the script access objects that actually participate in the execution of the business script from the syntax nodes related to script execution semantics based on the syntax structure representation includes: Based on the grammatical structure representation, the set of grammatical nodes containing multi-level grammatical nodes is traversed, and grammatical nodes related to script access object semantics are filtered out. The grammatical nodes include: grammatical nodes for representing variable reference semantics, grammatical nodes for representing method call semantics, and grammatical nodes for representing object attribute access or member access semantics. Based on the positional relationship, conditional constraint relationship, and scope association relationship of the syntax node in the script control structure, it is determined whether the syntax node has execution reachability during script execution, and the valid syntax nodes related to script execution semantics are determined accordingly. Based on the node type and node attribute information corresponding to the valid syntax node, the script access object that actually participates in the execution of the business script is determined.

5. The script access object whitelist verification method according to claim 4, characterized in that, The step of determining the script access object actually executed in the business script based on the node type and node attribute information corresponding to the valid syntax node includes: Based on the node type and node attribute information of the valid syntax nodes, semantic mapping processing is performed on the valid syntax nodes, and they are parsed into variable access objects and method call objects; Based on the variable access object and the method call object, the corresponding identifier name, access path and call parameter information are extracted respectively, and the variable access object and the method call object are aggregated according to the preset data structure to generate the variable call list and the method call list.

6. The script access object whitelist verification method according to claim 1, characterized in that, The step of obtaining the access object whitelist, wherein the access object whitelist includes the set of script access objects allowed to be used in the business script, includes: Obtain whitelist configuration information for describing script access control rules. The whitelist configuration information includes multiple access control rules, each of which defines the scope of script access objects allowed to be accessed under at least one business script type, business scenario, or execution context. Based on the script feature information of the business script, access control rules that meet the applicable conditions are dynamically selected from multiple access control rules in the whitelist configuration information, and an access object whitelist adapted to the business script is generated based on the access control rules.

7. The script access object whitelist verification method according to claim 1, characterized in that, Obtaining the abnormal script access object also includes: Obtain object description information corresponding to the abnormal script access object. The object description information is used to characterize the business semantics, functional purpose, or usage constraints of the script access object. Based on the object description information, a verification prompt message is generated to indicate the cause of the exception and the correction suggestion, and the verification prompt message is associated with the exception script access object and output.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform the script access object whitelist verification method as described in any one of claims 1-7.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the script access object whitelist verification method as described in any one of claims 1-7.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the script access object whitelist verification method as described in any one of claims 1-7.

Images