Interpreter script full path verification method, device, medium and program product based on executor rewriting

Abstract

The application provides an interpreter-based script full-path verification method and device based on an executor rewrite, a medium and a program product. The method comprises the following steps: obtaining an interpreter-based script and performing analysis to generate an abstract syntax tree; configuring a verification executor as an interpretation execution subject of the abstract syntax tree, and pointing an interpretation execution flow of the abstract syntax tree to the verification executor for traversal-type interpretation execution; in the traversal-type interpretation execution process, an override execution rule is adopted, so that a plurality of execution paths corresponding to a syntax node are executed, and when an exception occurs, the remaining execution paths are continuously verified; meanwhile, in the traversal-type interpretation execution process, a called script access object is synchronously identified and white list verification processing is performed, so that the script accessible object range is safely verified while the full-path execution verification is completed. The application cooperatively verifies the execution logic and access permission of the interpreter-based script, and improves the integrity, safety and reliability of the script verification.

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 full-path verification of interpreted scripts based on executor rewriting. Background Technology

[0002] In rule- or policy-driven business systems, scripting languages ​​are often used to filter, judge, and control target objects to achieve flexible configuration and dynamic adjustment of business logic. Interpreted scripting languages, due to their flexible deployment, no compilation required, and rapid iteration capabilities, are widely used in business scenarios such as user filtering, rule calculation, condition judgment, and policy control, to dynamically execute corresponding business logic based on input parameters and context data.

[0003] Existing interpreted scripting languages ​​typically employ an interpreted execution mechanism. Their script execution engine parses the script line by line and calls the corresponding methods or computational logic, dynamically determining the actual execution path based on input conditions. In practical applications, to accommodate frequent changes in business rules and rapid script deployment, script logic verification often relies on automatic program execution rather than manually constructing test data to test each logical branch individually. In such application scenarios, the limitation of interpreted scripting languages ​​to covering only a single path during execution directly leads to incomplete branch logic coverage in the script verification process. That is, normal execution verification usually only covers the logic of one execution path, while other logical branches lack effective verification.

[0004] Furthermore, interpreted scripting languages ​​typically feature weak typing or dynamic binding. Issues such as the existence of methods, the correct number of method parameters, and the matching of parameter types often go undetected during script parsing or loading. Instead, they are exposed at runtime when the script actually executes the corresponding method call node. When these runtime errors are located in logic branches that are not actually executed, even if the script has passed verification or is deployed, these errors may remain hidden for a long time and only be triggered under specific input conditions or business scenarios, thus adversely affecting system stability and business processing reliability.

[0005] Therefore, existing execution and verification methods for interpreted scripts are difficult to achieve comprehensive coverage verification of all execution paths in scenarios with multiple logical branches. They suffer from shortcomings such as incomplete branch logic verification and difficulty in early detection of runtime errors hidden in unreached branches. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides a method, device, medium, and program product for full-path verification of interpreted scripts based on executor rewriting, which at least solves the problem that existing technologies cannot effectively verify the full path and all branches of scripts containing multiple logical branches.

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

[0008] In a first aspect, some embodiments of this application provide a method for full-path verification of interpreted scripts based on executor rewriting, including:

[0009] Obtain the interpreted script to be verified, and parse the interpreted script to generate an abstract syntax tree;

[0010] Configure the verification executor as the main body for interpreting and executing the abstract syntax tree, direct the interpretation and execution flow of the abstract syntax tree to the verification executor, and have the verification executor perform traversal interpretation and execution of the abstract syntax tree;

[0011] During the traversal interpretation and execution process, a coverage execution rule is adopted for at least one type of syntax node in the abstract syntax tree so that multiple execution paths corresponding to the syntax node are executed. When an exception occurs during script execution, the traversal interpretation and execution is not interrupted by the exception, and the remaining syntax nodes and execution paths are verified and executed, thereby realizing the full path execution verification of the interpreted script.

[0012] During the traversal-style interpreted execution process, the script access objects called by the interpreted script in the verification execution phase are identified synchronously, and the script access objects are whitelisted to achieve security verification of the scope of script-accessible objects while completing full-path execution verification.

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

[0014] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the interpreter-rewritten full-path verification method as described above.

[0015] 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 interpretable script full-path verification method based on executor rewriting as described above.

[0016] 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 interpretable script full path verification method based on executor rewriting as described above.

[0017] Compared with existing technologies, the solution provided in this application parses the interpreted script to be verified and generates an abstract syntax tree (AST). A verification executor is configured as the interpreter of the AST, performing a traversal-style interpretation and execution. This allows the script execution process to no longer rely on the script engine's default execution logic, but instead achieves controllable and monitorable verification execution at the syntax node level. Specifically, by applying overriding execution rules to at least one type of syntax node during the traversal-style interpretation and execution, and maintaining uninterrupted verification execution when exceptions occur during script execution, potential exceptions located outside the current execution path can be fully triggered and captured. This effectively exposes potential execution defects hidden in branch paths, avoiding the problem of some logical branches lacking verification for extended periods due to premature termination caused by exceptions. Building upon this foundation, during the traversal-style interpreted execution process, the script access objects invoked by the interpreted script during the verification execution phase are simultaneously identified and whitelisted. This ensures that access permission verification is no longer independent of the execution verification process. Instead, it dynamically verifies whether variable access and method call behaviors generated under different execution paths comply with preset access permission constraints, thereby avoiding omissions or misjudgments of access behaviors caused by relying solely on static analysis or pre-defined rules. Therefore, through the above technical solution, this application achieves precise security verification of the scope of script-accessible objects while completing the full-path execution verification of the interpreted script, forming a collaborative processing mechanism between execution correctness verification and access permission control. On the one hand, it improves the ability to detect potential execution anomalies and unauthorized access risks in complex business scripts; on the other hand, it reduces the reliance on manually constructed test data and manual security reviews, enhancing the automation, security, and reliability of the script verification process. It is suitable for business script verification scenarios with complex rules and high dynamism. Attached Figure Description

[0018] 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.

[0019] Figure 1 This is a flowchart illustrating an interpretation script full-path verification method based on executor rewriting provided in an embodiment of this application;

[0020] Figure 2 This is a schematic diagram illustrating the class relationship and execution replacement between the native execution system of the interpreted script engine and the verification execution rewriting system provided in the embodiments of this application;

[0021] Figure 3 This is a schematic diagram illustrating the rewriting of the verification execution logic of key syntax nodes in the abstract syntax tree provided in this application embodiment;

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

[0023] 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.

[0024] Some embodiments of this application relate to a method for full-path verification of interpreted scripts based on executor rewriting, see reference... Figure 1 As shown, the method may include the following steps:

[0025] Step S1: Obtain the interpreted script to be verified and parse the interpreted script to generate an abstract syntax tree.

[0026] Specifically, the interpreted script to be verified is obtained from the script configuration module, the rule management system, or an external input interface. Interpreted scripts are a type of script that uses an interpreted execution mechanism. Their content is parsed and executed line by line by the script engine during runtime, without needing to be pre-compiled into a standalone executable program. They are typically used to describe business rule logic containing conditional judgments, logical operations, and control structures, and are characterized by flexible syntax, low configuration costs, and ease of dynamic adjustment. Interpreted scripts can be configured and generated by business personnel or dynamically generated by the system according to preset rules; their specific source is not a limitation of this embodiment.

[0027] In one feasible implementation, the interpreted script can be implemented using JEXL scripts, with the JEXL engine parsing and executing the script content. JEXL scripts, as a typical implementation of interpreted scripts, support semantic structures such as variable references, logical operations, conditional branches, and method calls, making them suitable for business scenarios such as rule configuration and strategy calculation. It should be understood that the use of JEXL scripts as an example in this embodiment is merely for illustrating the implementation of interpreted scripts and does not constitute a limitation on the scope of protection of this application.

[0028] After obtaining the interpreted script, it undergoes syntax parsing. The parsing process includes lexical analysis and syntax analysis of the script content. Lexical analysis breaks down the script text into syntactic units such as variable identifiers, constants, and operators. Syntactic analysis combines these syntactic units according to their logical relationships based on grammatical rules, thereby constructing an abstract syntax tree to represent the script's semantic structure. The abstract syntax tree is organized in a tree-like data structure. Its root node represents the overall logical structure of the script, while child nodes represent specific semantic components such as conditional branches, logical operations, comparison expressions, variable expressions, or method calls. The parent-child relationships between syntax nodes reflect the hierarchical relationships between different semantic units in the script.

[0029] In one example, an interpreted script can contain compound conditional expressions formed by combining multiple conditional statements using logical operators. For instance, the script might contain the following logical statement: "user.consume > 1000 && user.vip". After parsing the interpreted script, the resulting abstract syntax tree has a root node representing a logical AND operation, indicating a logical relationship where multiple conditions must be satisfied simultaneously. Under this root node are multiple child nodes: one is a comparison expression node, representing the comparison between the variable "user.consume" and the threshold "1000", and the other is a variable expression node, representing the judgment of the Boolean condition variable "user.vip". In this way, the multiple conditional statements connected by logical operators in the original script text are parsed and mapped into multiple syntax nodes with a clear hierarchical relationship. It should be understood that the above logical statements do not constitute a complete interpreted script, but rather logical sub-expressions within the interpreted script, typically existing as part of conditional statement nodes, branch control nodes, or rule clauses.

[0030] In the process of constructing the abstract syntax tree, format information unrelated to script semantics is stripped away, retaining only the syntactic structure and hierarchical relationships related to script execution logic. This allows the script's logical structure to be expressed in the form of structured data. The abstract syntax tree generated in this way serves as the core carrier of interpreted script semantics, providing a unified data structure foundation for subsequent traversal-based interpretation and execution, as well as multi-execution path coverage verification.

[0031] Step S2: Configure the verification executor as the main body for interpreting and executing the abstract syntax tree, direct the interpretation and execution flow of the abstract syntax tree to the verification executor, and let the verification executor perform traversal interpretation and execution of the abstract syntax tree.

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

[0033] Step S201: Generate a script engine instance for verification execution by rewriting the native builder of the interpreted script engine.

[0034] An interpreted script engine is a software component used to parse and execute interpreted scripts. It typically includes functional units such as a script parsing module, an abstract syntax tree (AST) storage module, and an interpretation and execution control module. In actual operation, the interpreted script engine usually creates and initializes its instance through its native builder. The native builder receives engine parameter configurations and generates a default script engine instance, which uses a native interpretation and execution mechanism to execute the AST during script execution. In existing technologies, script engine instances created by the native builder typically only support single-path interpretation and execution based on runtime conditions, which is insufficient to meet the requirements of multi-path coverage verification during script verification. Therefore, this embodiment does not directly intervene in the native engine during script execution; instead, it rewrites the native builder of the interpreted script engine from the source of the script engine instance creation.

[0035] Rewriting the native builder refers to adjusting the build logic used to generate script engine instances while maintaining compatibility with the original builder interface and engine configuration parameters. Instead of generating a script engine instance using the native interpreted execution mechanism during the build phase, it generates a script engine instance for verification execution. This script engine instance still structurally possesses the basic capabilities of script parsing and abstract syntax tree generation, but its internal execution scheduling logic is configured to support verification execution mode. This allows the script execution flow to enter a comprehensive, multi-path verification execution mechanism during subsequent script parsing, object creation, and interpreted execution.

[0036] As an optional embodiment, step S201 specifically includes:

[0037] Step S2011: Provide a validation builder that inherits from the native builder of the interpreted script engine;

[0038] Step S2012: In the validation builder, override the build method used to create the script engine instance;

[0039] Step S2013: The construction method generates a script engine instance for verification execution while keeping the original engine configuration parameters valid. The script engine instance is configured to use a different verification execution mechanism than the interpreted script engine when parsing and interpreting the script.

[0040] In this embodiment, the interpreted script engine is implemented using a layered architecture. Its base layer consists of native classes of the script engine, which perform the basic functions of script parsing and interpretation execution. For example, in the JEXL engine architecture, such as... Figure 2 As shown, the native classes include the builder class JexlBuilder, the core script engine class JexlEngine, the script interface or abstract definition class JexlScript, the script implementation class Script, and the interpreter class Interpreter. These native classes together constitute the default implementation system of the interpreted script engine, used to generate an abstract syntax tree from the script text and interpret and execute the abstract syntax tree according to the established execution rules of interpreted languages.

[0041] Building upon the aforementioned native implementation framework, this embodiment further introduces core classes for business logic rewriting. These classes enable full-path script execution verification in the verification execution mode without altering the overall architecture of the native engine. Specifically, the core classes for business logic rewriting include KooBossJexlBuilder, KooBossJexlEngine, KooBossJexlScript, and KooBossJexlInterpreter. These classes inherit from their respective native classes and rewrite the key construction and interpretation execution logic.

[0042] The KooBossJexlBuilder class inherits from the JexlBuilder class and is used to replace the native script engine instance with a custom verification execution script engine instance during the script engine instance creation phase. The KooBossJexlEngine class inherits from the JexlEngine class and is used to introduce object generation logic related to verification execution during the creation of script objects and verification executors. The KooBossJexlScript class inherits from the JexlScript class and is used to guide the script execution request to the verification executor when the script is triggered for execution. The KooBossJexlInterpreter class inherits from the Interpreter class and is used to rewrite the default interpretation and execution semantics of various syntax nodes in the abstract syntax tree to support traversal and multi-path verification execution.

[0043] As an example implementation, to introduce a verification execution mechanism without intruding on the internal execution flow of the native script engine, a custom `KooBossJexlBuilder` class inherits from the `JexlBuilder` class, and the underlying `create` method used to create script engine instances in the native builder is overridden. This overriding ensures that when creating an execution engine instance, the builder no longer generates a native `JexlEngine` script engine instance, but instead generates a custom `KooBossJexlEngine` class to create the script engine instance. This ensures that the creation result of the script engine instance consistently points to the custom verification execution script engine, completing the switching of the interpretation and execution entry point during the engine construction phase. This allows the script object generation and interpretation / execution process to be uniformly scheduled by the custom script engine instance.

[0044] Through the processing in steps S2011 to S2013, a verification builder that inherits from the native builder is provided. The construction method for creating script engine instances is overridden in the builder. While keeping the original engine configuration parameters (including syntax rules, custom functions, and execution context) valid, a script engine instance for verification execution is generated. This eliminates the need to introduce intrusive execution control logic during the script execution phase, achieving a smooth switch from business execution to verification execution in the interpreted script execution mode. It has good scalability and compatibility.

[0045] Step S202: During the script parsing and execution object creation phases, the script engine instance generates a script object for storing the abstract syntax tree and a verification executor for verifying execution, respectively, to replace the native script object and native interpreter in the interpreted script engine.

[0046] After generating the script engine instance for verification execution in step S201, the script engine instance enters the script object and verification executor creation phase. In this phase, the script engine instance typically needs to generate a script object based on the parsing results, which carries the abstract syntax tree corresponding to the script and related execution information. At the same time, it generates a verification executor, which is used to interpret and execute the abstract syntax tree when the script is triggered for execution.

[0047] In this embodiment, the script engine instance does not use the native object creation mechanism of the interpreted script engine. Instead, it introduces object generation logic related to verification and execution during the object creation phase. This allows the generated script object and verification executor to no longer use the native execution semantics, but are instead configured to support verification and execution mode. The script object generated in this way is used to store and manage the abstract syntax tree and establishes an association with the verification executor during the script execution phase. The verification executor is used to undertake the task of interpreting and executing the abstract syntax tree in subsequent execution processes, replacing the native interpreter to complete the script interpretation and execution.

[0048] As an optional embodiment, step S202 specifically includes:

[0049] Step S2021: Rewrite the creation logic of the native script object through the script engine instance, so that the generated script object can retain the original script semantic representation capability while having the execution scheduling capability to transfer the script execution request to the verification executor;

[0050] Step S2022: Rewrite the creation logic of the native interpreter through the script engine instance to generate a verification executor associated with the script object. The verification executor is used to replace the native interpreter during the script execution phase and perform traversal interpretation and execution of the abstract syntax tree.

[0051] Specifically, by redirecting the execution entry point of the script object, the script execution request is handed over to the verification executor associated with the script object for processing, so that the verification executor can perform traversal interpretation and execution of the abstract syntax tree.

[0052] Specifically, in the JEXL engine system, the JexlEngine class, as the core engine class of the native script engine, is used to complete the parsing, compilation, and execution environment management of expressions. It is the core hub connecting the builder configuration and the script execution process.

[0053] It's important to note that the JexlScript class, as a compiled script expression object within the JEXL engine, stores the abstract syntax tree (AST) generated after the interpreted script is parsed, along with core logic information related to script execution. It also supports repeated execution of the script within the same execution environment. In the native implementation, when a JexlScript object is triggered for execution, its execution flow is typically handled by the native Interpreter class, which interprets and executes the AST. The Interpreter class is the interpreter class in the JEXL engine, used to traverse the AST, interpret and execute the script logic node by node, and handle variable resolution, method calls, and output of computation results during execution. Under runtime constraints, the Interpreter class typically selects a single execution path based on conditional judgments to complete a single script execution.

[0054] In this embodiment, in order to introduce a full-path verification execution mechanism during the script execution phase, a custom KooBossJexlEngine class is used to inherit the JexlEngine class, and its key methods related to script execution are overridden, so that the script engine instance no longer uses the native execution system during the object creation phase.

[0055] In one example implementation, the KooBossJexlEngine class overrides the script creation method to generate a custom KooBossJexlScript object instead of a native JexlScript object. This custom object carries the abstract syntax tree and semantic information related to script execution. The KooBossJexlScript class inherits from the JexlScript class to gain the ability to store the abstract syntax tree and script semantic information. Furthermore, it overrides the script execution entry method, so that when the script object is triggered, it no longer calls the native Interpreter class for interpretation and execution, but instead delegates the script execution request to its associated verification executor.

[0056] Meanwhile, the KooBossJexlEngine class also rewrites the creation logic of the native interpreter, generating a custom KooBossJexlInterpreter class instance during the script object creation phase to replace the native Interpreter class. The KooBossJexlInterpreter class instance acts as a verification executor, used in verification execution mode to perform traversal interpretation and execution of the abstract syntax tree, and rewrites the default interpretation and execution semantics of various syntax nodes in the abstract syntax tree, thereby supporting verification execution functions such as multi-branch path coverage, execution without interruption due to exceptions, and execution trajectory recording.

[0057] Through steps S2021-S2022, this embodiment structurally restructures the execution scheduling relationship of the interpreted script during the script object and verification executor generation stage. This creates a stable and associated execution mapping relationship between the script object and the verification executor, allowing the verification executor to directly take over the interpretation and execution process of the abstract syntax tree when the interpreted script is triggered, without going through the execution path selection mechanism of the native interpreter. This avoids interference from the native execution semantics on the verification execution process. This restructured design embeds the verification execution capability cohesively into the execution flow of the script object itself, which helps improve the determinism of execution path control and the stability of the verification execution process.

[0058] Step S203: When the script object is triggered to execute, the interpretation and execution request of the abstract syntax tree is redirected to the verification executor, so that the verification executor can perform traversal interpretation and execution of the abstract syntax tree.

[0059] Specifically, the execution entry method of the script object is overridden so that when the script object receives an execution trigger instruction, it no longer sends the abstract syntax tree (API) interpretation and execution request to the native interpreter. Instead, it forwards the interpretation and execution request to the verification executor associated with the script object. The verification executor, as the main body for interpreting and executing the API, takes over the script's interpretation and execution process.

[0060] After the verification executor takes over the interpretation and execution process, it performs a traversal interpretation and execution of the abstract syntax tree. Unlike the native interpretation executor, which selects a single execution path based on runtime conditions, the verification executor traverses each syntax node in the abstract syntax tree according to preset verification and execution rules, and performs overriding execution on the corresponding execution path based on the syntax node type, thereby realizing the verification and execution of multiple potential execution paths in the script.

[0061] Through the aforementioned execution entry redirection mechanism, the script object can switch the script execution from the native interpreted execution mode to the verification execution mode without changing the original semantic structure of the script. This ensures that when the script is triggered for execution, the verification executor can complete the traversal and multi-path interpretation and execution of the abstract syntax tree, providing the execution foundation for subsequent full-path execution verification.

[0062] Through steps S201-S203, this embodiment, without disrupting the original overall architecture and configuration system of the interpreted script engine, collaboratively reconstructs the construction logic of the script engine instance, the creation logic of script objects and verification executors, and the script execution entry point. This ensures that the interpretation and execution flow of the abstract syntax tree is stably directed to the verification execution system during the engine instance creation stage. By rewriting the engine instance creation method at the builder layer, execution ambiguity caused by the coexistence of native execution paths and verification execution paths is avoided from the source. Furthermore, a stable execution association is established between the script object and the verification executor during the object creation stage. When the script is triggered for execution, the verification executor uniformly takes over the interpretation and execution process through execution entry point redirection. This embeds the verification execution mechanism cohesively into the object lifecycle and execution flow of the script engine, providing a deterministic and controllable execution foundation for multi-path abstract syntax tree traversal execution, which is beneficial for improving the stability and reliability of the full-path verification of interpreted scripts.

[0063] Step S3: During the traversal interpretation and execution process, for at least one type of syntax node in the abstract syntax tree, a coverage execution rule is adopted to ensure that multiple execution paths corresponding to the syntax node are executed. When an exception occurs during script execution, the traversal interpretation and execution will not be interrupted due to the exception, and the remaining syntax nodes and execution paths will continue to be verified and executed, thereby realizing the full path execution verification of the interpreted script.

[0064] To ensure that traversal interpretation and execution can cover multiple execution paths formed by branch judgments, logical short-circuiting, loop iterations, and exception propagation, this embodiment, before step S3, first rewrites the default interpretation and execution semantics of at least one type of key syntax nodes in the abstract syntax tree by the verification executor. This execution semantic rewriting mechanism is not a local adjustment to a single syntax node, but rather a unified adjustment of the interpretation and execution rules for key syntax nodes in the abstract syntax tree. This allows the verification executor, during traversal interpretation and execution, to no longer be limited by the runtime behavior rules inherent in the native interpretation and execution semantics, such as "conditional path selection, early return due to logical short-circuiting, and interruption of propagation upon exception triggering." Instead, it implements differentiated execution control for different types of syntax nodes according to a preset coverage verification strategy, thereby completing traversal interpretation and execution with the goal of execution path coverage and execution trajectory recording. Based on the above execution semantic rewriting mechanism, Figure 3 The diagram illustrates the rewriting of the verification execution logic of key syntax nodes in the abstract syntax tree, used to explain the overriding execution control method adopted by different types of syntax nodes in the verification execution mode.

[0065] Specifically, for branch control syntax nodes ( Figure 3 The "if node behavior rewriting" shown demonstrates how the executor overrides its interpretation and execution rules: when traversing a branch control node, instead of selecting a single branch based on the runtime condition judgment result, it triggers the execution of multiple branch logics of that branch control node one by one. Specifically, the executor can extract the branch set into a sequence of branches to be executed, executing "condition-true branches, condition-false branches, and optional else-if chain branches" in a preset order, and writing the execution start identifier, branch identifier, execution result, and exception status of each branch in the global execution context. When an exception occurs in the condition evaluation itself (e.g., missing variables, type mismatch causing the condition expression to fail to evaluate), the executor does not use this exception as the termination condition for the branch node, but records the condition evaluation exception and continues to execute the remaining branch logic to ensure the continuity of branch path coverage. This method achieves the effects of "forcing the execution of all branches instead of only executing branches that meet the conditions," "recording the execution process and result of each branch," and "continuing to execute the code block even if the condition judgment is incorrect."

[0066] For logical operation syntax nodes ( Figure 3The "Logical Operator Processing (AND / OR)" shown demonstrates how the executor cancels short-circuit evaluation rules and performs complete evaluation and recording of each operand. Taking a logical AND node (e.g., ASTAndNode) as an example, in its native semantics, a short-circuit return occurs when any operand is false. In this embodiment, when the executor traverses to a logical AND node, it evaluates both left and right operands (or multiple operand sequences) in operand order and writes the evaluation results of each operand, along with variable references, method calls, and exception information involved in the evaluation process, into the execution trajectory. For logical OR nodes (e.g., ASTOrNode), the short-circuit behavior of "returning early when any operand is true" is also canceled. Instead, all operands are evaluated and recorded to avoid certain branches or method call paths not being triggered for a long time due to short-circuiting. When the logical operation node itself has uncertain evaluation results or abnormal return values, the executor records this abnormal state in the global execution context and returns a preset verification result to maintain the traversal's continuation, thereby achieving the trajectory recording purpose of "detailed recording of the values ​​and expressions of the left and right operands."

[0067] For loop control syntax nodes ( Figure 3 The "Loop Statement Processing" shown verifies that the executor records loop start and end information and iteration status during the loop execution phase, and continues subsequent iterations even when an exception occurs during partial iteration execution. Taking a for-each loop as an example, when the executor enters a loop node, it writes a loop start event in the global execution context and records a summary of the loop set (e.g., whether the set is empty, the set length, and the set element type identifier). During iteration, it writes the iteration number, iteration variable binding status, and iteration body execution result for each iteration. When an exception occurs during the execution of an iteration body, the executor catches the exception and records the exception type and trigger location. Instead of throwing the exception upwards to interrupt the loop node, it continues to execute subsequent iterations and writes a loop end event at the end of the loop, thus achieving the continuity requirement that "partial iteration exceptions do not affect subsequent iteration coverage verification".

[0068] For method call class syntax nodes ( Figure 3The "Method Invocation Processing" shown demonstrates that the executor parses and records the method invocation object and method information during the interpretation execution phase, and performs capture and degradation processing on preset business exceptions to avoid interrupting the traversal interpretation execution. Specifically, when traversing to a method invocation node, the executor parses the invocation target (object identifier or class identifier), method identifier, and parameter list information, and writes this information as a method execution event into the global execution context. Subsequently, it performs wrapper-style exception handling for method invocation execution: if a general runtime exception occurs, the exception is recorded and marked as "caught," allowing the traversal to continue; if a preset business exception is triggered (such as EvalRaiseException, an exception type used for business interruption), it is treated as a "business interruption signal" and processed specifically, that is, only the exception information, trigger location, and corresponding business interruption semantic identifier are recorded, without using it as a termination condition for interpretation execution, to ensure that the verification execution process continues and covers subsequent syntax nodes and paths.

[0069] For syntax nodes that are sensitive to decision class or return value ( Figure 3 The example shown, "Rewriting the behavior of the empty() function," verifies that the executor returns a preset verification result and records the exception information when an exception or uncertain execution result occurs, in order to avoid the undeterminable state of such nodes blocking subsequent path coverage. Taking the empty() function as an example, the verification executor can rewrite the default behavior of this function node: when its input value parsing fails, context variables are missing, or evaluation is abnormal, the exception is not thrown upwards, but the exception is recorded and a preset verification return value is returned (e.g., returning TRUE or returning a neutral value for continued coverage). At the same time, the execution trajectory is marked that the return belongs to "verification degradation return". Furthermore, the variable names or access paths related to empty() can be extracted and written into the execution log context to locate potential variable null value risks or type risks in the script, thereby achieving the trajectory enhancement purpose of "extracting variables and recording them into the execution log context".

[0070] After completing the default interpretation and execution semantic rewriting, the process proceeds to step S3: the verification executor performs traversal interpretation and execution on the abstract syntax tree, and applies covering execution rules to at least one type of syntax node during the traversal to ensure that multiple execution paths corresponding to the syntax node are executed. During the traversal, the verification executor triggers interpretation and execution node by node according to the node access order of the abstract syntax tree. When encountering branch control nodes, logical operation nodes, loop control nodes, method call nodes, and decision nodes, the corresponding covering execution rules are invoked to achieve multi-path coverage. Simultaneously, exceptions generated during script execution are captured and recorded. Exception information is written to the global execution context in the form of node-level events without triggering an interruption of the traversal interpretation and execution process, thus continuing to verify and execute the remaining syntax nodes and execution paths. Through the above mechanism, this embodiment can continuously trigger and record hidden paths caused by condition judgments, logical short circuits, loop iterations, and business interruption exceptions within a single verification execution cycle, enabling the script to complete path verification with higher coverage before being put into business operation.

[0071] As an optional embodiment, the process of performing full-path verification on the interpreted script also includes:

[0072] Construct a global execution state container for aggregating execution state data generated during the traversal interpretation execution process;

[0073] Execution events generated by different syntax nodes during the traversal interpretation execution process will be written into the global execution state container in a unified data structure. The execution events include at least one of the following: syntax node identifier, branch selection identifier, execution order identifier, or exception state identifier.

[0074] By performing correlation analysis on the execution events aggregated in the global execution state container, execution trajectory data is generated to characterize the coverage of each execution path during the verification execution of the interpreted script.

[0075] Specifically, before the verification executor performs traversal interpretation and execution of the abstract syntax tree, a global execution state container is first constructed. The global execution state container is used to continuously and effectively aggregate various execution state data generated during the traversal interpretation and execution process within a single verification execution cycle. It can be implemented in the form of an in-memory data structure, a context object, or a state set, and is used to uniformly carry the execution event information generated by different syntax nodes during the execution process.

[0076] During the traversal-style interpretation and execution process, the verification executor generates corresponding execution events for the execution behavior of each syntax node in the abstract syntax tree when interpreting and executing them. These events are then written into the global execution state container using a unified data structure. Execution events describe the execution status of syntax nodes during the verification and execution process, and include at least one or more of the following information: syntax node identifier, used to uniquely identify the currently executed syntax node and its position in the abstract syntax tree; branch selection identifier, used to indicate the branch path corresponding to the branch control type syntax node during the overlay execution process; execution order identifier, used to reflect the execution sequence of syntax nodes during the traversal-style interpretation and execution process; and exception status identifier, used to indicate whether an exception occurred during the execution of the syntax node and the exception type information. Through this method, execution events generated by different types of syntax nodes during the traversal-style interpretation and execution process are continuously written into the global execution state container, thus forming an execution state set reflecting the entire script execution process.

[0077] After the traversal-style interpreted execution is completed, correlation analysis is performed on the execution events aggregated in the global execution state container. Correlation analysis can perform path-level association and combination of execution events based on syntax node identifiers, branch selection identifiers, and execution order identifiers, thereby generating execution trajectory data that characterizes the coverage of each execution path during the verification execution of the interpreted script. Execution trajectory data reflects whether each logical branch, loop iteration, and exception path in the script has been covered and can be used for subsequent verification result output, exception localization, or coverage integrity assessment.

[0078] By introducing the aforementioned global execution state container and execution trajectory generation mechanism, this embodiment can structurally record and analyze the multi-execution path coverage of interpreted scripts without relying on specific input conditions or manual test cases, providing reliable data support for the full-path execution verification of interpreted scripts.

[0079] It should be noted that the global execution state container can be maintained as a set of states or a state mapping structure in the global execution context, and its specific implementation does not constitute a limitation on the scope of protection of this application.

[0080] Step S4: During the traversal interpretation execution process, synchronously identify the script access objects called by the interpreted script in the verification execution phase, and perform whitelist verification on the script access objects to achieve security verification of the scope of script accessible objects while completing the full path execution verification.

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

[0082] Step S401: Based on the reflection mechanism, parse and identify the script access objects called by the script during the verification execution process from the syntax nodes related to script execution semantics in the abstract syntax tree. The script access objects include variable access objects and method call objects.

[0083] Step S402: Based on the script access object, extract the corresponding identifier name, access path and call parameter information respectively, and encapsulate the variable access object and method call object in a structured manner according to the preset data structure to form a variable call list and a method call list;

[0084] Step S403: Obtain a preset access object whitelist, which includes a set of script access objects that are allowed to be accessed in the current script execution scenario;

[0085] Step S404: Compare and verify the script access objects in the variable call list and method call list with the access object whitelist to identify abnormal script access objects that are not covered by the access object whitelist.

[0086] In this embodiment, during the process of traversing and interpreting the abstract syntax tree, the script access objects involved in the verification and execution phase of the interpreted script can also be identified and whitelisted simultaneously, so as to achieve security verification of the scope of script access objects while completing the full path execution verification.

[0087] When the executor performs traversal interpretation and execution of the abstract syntax tree, the variable access and method call relationships involved in the script are difficult to fully determine statically during the script parsing phase due to the characteristics of interpreted scripts, such as weak typing, dynamic binding, and runtime resolution. This is especially true under overriding execution rules, where different execution paths may trigger different access behaviors. Therefore, this embodiment introduces a reflection mechanism during the traversal interpretation and execution process as a means of parsing execution semantics to identify script access objects. The reflection mechanism is used during the interpretation and execution phase to dynamically parse and identify script access objects triggered during the verification and execution process from syntax nodes related to the script's execution semantics, in conjunction with the execution context of the current syntax node.

[0088] Script access objects characterize the access behaviors that a script may exhibit at the execution semantic level, and include at least two types: variable access objects and method call objects. Variable access objects characterize the script's access to variable identifiers or object properties during execution; method call objects characterize the script's invocation of external methods or functions during execution. When the executor traverses syntax nodes, it combines the node type, node attribute information, and the node's context within the execution path, using reflection to obtain runtime-resolvable object instances, attribute information, or method signature information, thereby resolving the syntax nodes carrying access semantics into corresponding script access objects.

[0089] After identifying the script access objects, the identifier name, access path, and call parameter information corresponding to each script access object are extracted, and the script access objects are then structurally encapsulated according to a preset data structure. 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 actual variable access and method call behaviors that occur in the interpreted script under the semantic constraints of verification execution.

[0090] After structuring the script access objects, a pre-defined whitelist of access objects is obtained. The whitelist describes the set of script access objects allowed to be accessed in the current script execution scenario, and can be generated based on script type, business scenario, or execution context. In one implementation, business variables and methods open to business personnel are pre-maintained in a structured configuration to form whitelist configuration information. The whitelist configuration information includes multiple access control rules, each defining the range of script access objects allowed for a business script under at least one business script type, business scenario, or execution context. 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 identifier, business module identifier, business scenario identifier, execution environment identifier, or other contextual features that characterize the script 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 allowed for the business script. The script access object collection can include variable access objects, method call objects, or a combination of both.

[0091] 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.

[0092] Based on the script characteristic information of the interpreted script to be verified, access control rules that meet the applicable conditions are dynamically selected from multiple access control rules in the whitelist configuration information. A whitelist of access objects adapted to the business script is then generated based on these access control rules. Specifically, the script characteristic information of the interpreted script to be verified is first obtained. This script characteristic information characterizes the usage background and applicable environment of the business script, and may include, but is not limited to: script type identifier, business module identifier, business scenario identifier, execution environment identifier, and context parameter information related to script execution. This script characteristic information can be provided by the business system during the script submission, configuration, or invocation phase, or automatically determined by the script management module based on the script's configuration location, invocation entry point, or runtime parameters.

[0093] After obtaining the script characteristic information of the business script, rule matching is performed against the whitelist configuration information. 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 matching the applicable scenario of the current business script is selected from multiple access control rules. 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. That is, the variable access object definition information and method call object definition information are extracted from each access control rule, and access objects with duplicate definitions are merged to generate an access object whitelist adapted to the current business script. The access object whitelist is used to clearly define the scope of script access objects allowed to be used in the current business script execution scenario. The access object whitelist includes at least the set of allowed variable access objects and the set of method call objects.

[0094] Subsequently, each script access object in the variable call list and method call list is compared and verified against the access object whitelist to determine if there are any abnormal script access objects not covered by the access object whitelist. Script access objects that exist in the script access object set but cannot be matched with a corresponding allowed item in the access object whitelist are identified as abnormal script access objects.

[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] Through the above embodiments, the script access object whitelist verification mechanism and the full-path execution verification process of interpreted scripts form a unified verification and execution system. The script's logical integrity and access security can be verified simultaneously during the script verification stage without relying on the actual running results of the script in a real business environment, thereby improving the security, reliability and controllability of the script configuration and verification process.

[0097] Through steps S401-S404, dynamic identification and whitelist verification of interpreted script access behavior are achieved during the traversal interpreted execution process, forming a tightly coupled collaborative mechanism between script access security verification and the full-path execution verification process. Specifically, a reflection mechanism is introduced in the verification execution phase, combined with the traversal interpreted execution method, enabling the verification executor to dynamically identify and collect variable access and method call behaviors that may be triggered by the interpreted script under different execution paths based on the script's execution semantics. This approach overcomes the limitation of static analysis capabilities under the conditions of weak typing and dynamic binding of interpreted scripts, and avoids the omission risks caused by coarse-grained verification based solely on the script's static syntax structure or single-path execution results in existing technologies. It can detect potential illegal access behaviors or security vulnerabilities hidden in specific branch paths in advance during the script verification phase, thereby effectively reducing business risks caused by the lack of access control after the script goes live.

[0098] In summary, the full-path verification method for interpreted scripts based on executor rewriting provided in this application parses the interpreted script to be verified and generates an abstract syntax tree (AST). A verification executor is configured as the interpreter of the AST, performing a traversal-based interpretation execution. This allows the script execution process to no longer rely on the script engine's default execution logic, but instead achieves controllable and monitorable verification execution at the syntax node level. Specifically, by applying overriding execution rules to at least one type of syntax node during the traversal-based interpretation execution, and by maintaining uninterrupted verification execution when exceptions occur during script execution, potential exceptions located outside the current execution path can be fully triggered and captured. This effectively exposes potential execution defects hidden in branch paths and avoids the problem of some logical branches lacking verification for extended periods due to premature termination caused by exceptions. Building upon this foundation, during the traversal-style interpreted execution process, the script access objects invoked by the interpreted script during the verification execution phase are simultaneously identified and whitelisted. This ensures that access permission verification is no longer independent of the execution verification process. Instead, it dynamically verifies whether variable access and method call behaviors generated under different execution paths comply with preset access permission constraints, thereby avoiding omissions or misjudgments of access behaviors caused by relying solely on static analysis or pre-defined rules. Therefore, through the above technical solution, this application achieves precise security verification of the scope of script-accessible objects while completing the full-path execution verification of the interpreted script, forming a collaborative processing mechanism between execution correctness verification and access permission control. On the one hand, it improves the ability to detect potential execution anomalies and unauthorized access risks in complex business scripts; on the other hand, it reduces the reliance on manually constructed test data and manual security reviews, enhancing the automation, security, and reliability of the script verification process. It is suitable for business script verification scenarios with complex rules and high dynamism.

[0099] 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.

[0100] 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 cellular phones, smartphones, wearable devices, and other similar computing devices.

[0101] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform an interpreted script full-path verification method based on executor rewriting as provided in any one or more of the above embodiments. Figure 4 An 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.

[0102] 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 4 Taking the example of a connection between China and Israel via a bus.

[0103] 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.

[0104] 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).

[0105] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements the interpretable script full-path verification method based on executor rewriting provided in any one or more of the above embodiments. The 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 computer-readable medium carries one or more computer-readable instructions.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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).

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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 the full path of an interpreted script based on executor rewriting, characterized in that, include: Obtain the interpreted script to be verified, and parse the interpreted script to generate an abstract syntax tree; Configure the verification executor as the main interpreter of the abstract syntax tree, direct the interpretation and execution flow of the abstract syntax tree to the verification executor, and have the verification executor perform traversal interpretation and execution of the abstract syntax tree, including: The native classes of an interpreted script engine include: the builder class JexlBuilder, the core script engine class JexlEngine, the script interface or abstract definition class JexlScript, the script implementation class Script, and the interpreter class Interpreter; Without changing the overall architecture of the native engine, the core classes that inherit the corresponding native classes and generate business rewrites include: KooBossJexlBuilder class, KooBossJexlEngine class, KooBossJexlScript class, and KooBossJexlInterpreter class; The KooBossJexlBuilder class inherits from the JexlBuilder class and overrides the construction method in the native builder used to create script engine instances, so as to replace the native script engine instance with the script engine instance for verification and execution during the script engine instance creation stage. The KooBossJexlEngine class inherits from the JexlEngine class and is used by the script engine instance to generate a script object for storing the abstract syntax tree and a verification executor for verifying execution during the script parsing and execution object creation phases, respectively, to replace the native script object and native interpreter in the interpreted script engine. The KooBossJexlScript class inherits from the JexlScript class and is used to direct script execution requests to the verification executor when a script object is triggered to execute. The KooBossJexlInterpreter class inherits from the Interpreter class and is used to rewrite the default interpretation and execution semantics of various syntax nodes in the abstract syntax tree. An instance of the KooBossJexlInterpreter class serves as a verification executor and is used to perform traversal interpretation and execution of the abstract syntax tree in verification execution mode. During the traversal interpretation and execution process, a coverage execution rule is adopted for at least one type of syntax node in the abstract syntax tree so that multiple execution paths corresponding to the syntax node are executed. When an exception occurs during script execution, the traversal interpretation and execution is not interrupted by the exception, and the remaining syntax nodes and execution paths are verified and executed, thereby realizing the full path execution verification of the interpreted script. During the traversal-style interpreted execution process, the script access objects called by the interpreted script in the verification execution phase are identified synchronously, and the script access objects are whitelisted to achieve security verification of the scope of script-accessible objects while completing full-path execution verification.

2. The method for verifying the full path of an interpreted script based on executor rewriting according to claim 1, characterized in that, The construction method generates a script engine instance for verification execution while keeping the original engine configuration parameters valid. The script engine instance is configured to use a different verification execution mechanism than the interpreted script engine when parsing and interpreting the script.

3. The method for verifying the full path of an interpreted script based on executor rewriting according to claim 1, characterized in that, The step of generating a script object for storing the abstract syntax tree and a verification executor for verifying execution during the script parsing and execution object creation phases of the script engine instance, respectively, to replace the native script object and native interpreter in the interpreted script engine, includes: The creation logic of the native script object is rewritten by the script engine instance, so that the generated script object can retain the original script semantic representation capability while having the execution scheduling capability to transfer the script execution request to the verification executor. The creation logic of the native interpreter is rewritten by the script engine instance to generate a verification executor associated with the script object. The verification executor is used to replace the native interpreter during the script execution phase and perform traversal interpretation and execution of the abstract syntax tree. Specifically, by redirecting the execution entry point of the script object, the script execution request is handed over to the verification executor associated with the script object for processing, so that the verification executor can perform traversal interpretation and execution of the abstract syntax tree.

4. The method for verifying the full path of an interpreted script based on executor rewriting according to claim 1, characterized in that, Before the step of the verification executor performing traversal interpretation and execution of the abstract syntax tree, the method further includes: The verification executor rewrites the default interpretation and execution semantics of at least one type of syntax node in the abstract syntax tree, specifically including: For branch control syntax nodes, an overriding branch execution rule is adopted to execute multiple branch logics one by one, rather than selecting a single execution path based on runtime conditions; For logical operation syntax nodes, the short-circuit evaluation rule is canceled, each operand is fully evaluated, and the evaluation process is recorded. For loop control syntax nodes, the loop start and end information and iteration status are recorded during loop execution, and subsequent iterations continue to be executed if an exception occurs during part of the iteration execution; For the syntax nodes of the method call class, record the method call object and method information, and capture and degrade preset business exceptions to avoid interrupting the traversal interpretation execution; For judgment-type syntax nodes, when an exception or uncertain execution result occurs, a preset verification result is returned and the exception information is recorded.

5. The method for verifying the full path of an interpreted script based on executor rewriting according to claim 1, characterized in that, The step of synchronously identifying script access objects called by the interpreted script during the verification execution phase and performing whitelist verification on the script access objects during the traversal interpreted execution process includes: Based on the reflection mechanism, the script access objects called by the script during the verification execution process are parsed and identified from the syntax nodes related to script execution semantics in the abstract syntax tree. The script access objects include variable access objects and method call objects. Based on the script access object, the corresponding identifier name, access path and call parameter information are extracted respectively, and the variable access object and method call object are encapsulated in a structured manner according to the preset data structure to form a variable call list and a method call list. Obtain a preset access object whitelist, which includes a set of script access objects that are allowed to be accessed in the current script execution scenario; The script access objects in the variable call list and method call list are compared and verified with the access object whitelist to identify abnormal script access objects that are not covered by the access object whitelist.

6. The method for verifying the full path of an interpreted script based on executor rewriting according to claim 1, characterized in that, The process of performing full-path verification on the interpreted script also includes: Construct a global execution state container for aggregating execution state data generated during the traversal interpretation execution process; The execution events generated by different syntax nodes during the traversal interpretation execution process are written into the global execution state container in a unified data structure, wherein the execution events include at least one of the following: syntax node identifier, branch selection identifier, execution order identifier, or abnormal state identifier. By performing correlation analysis on the execution events aggregated in the global execution state container, execution trajectory data is generated to characterize the coverage of each execution path during the verification execution of the interpreted script.

7. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the interpreter-rewritten full-path verification method as described in any one of claims 1-6.

8. 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 interpretable script full path verification method based on executor rewriting as described in any one of claims 1-6.

9. 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 interpretable script full path verification method based on executor rewriting as described in any one of claims 1-6.

Images