Vulnerability detection method and device, electronic equipment and computer program product

Abstract

The embodiment of the invention is suitable for the field of software security, and provides a vulnerability detection method and device, electronic equipment and a computer program product.The method comprises the steps that for a to-be-detected target function, a first taint parameter conforming to a parameter structure of the target function is generated; inputting the first stain parameter to the target function for operation, and recording operation feature information of a pollution expression corresponding to the first stain parameter; the operation feature information comprises at least one of position information used for describing the pollution expression in the target function and object information used for describing an object pointed by the pollution expression during operation; and performing vulnerability detection on the operation feature information by adopting a static analysis mode to obtain vulnerability information of the vulnerability. By adopting the method, the detection accuracy can be guaranteed while the vulnerability detection efficiency is improved.

Description

Technical Field

[0001] This application belongs to the field of software security technology, and in particular relates to a vulnerability detection method, device, electronic device and computer program product. Background Technology

[0002] In the field of software security, injection vulnerabilities are a core risk threatening system security. Essentially, untrusted input (taints) flows into dangerous operations (convergence points) without proper handling, leading to unexpected behavior. While the detection of traditional injection vulnerabilities (such as command injection and code injection) has developed into a mature system centered on taint analysis, prototype chain pollution vulnerabilities are more difficult to detect due to their unique characteristics.

[0003] For prototype chain pollution vulnerabilities, existing mainstream detection technologies are based on taint analysis methods that use abstract interpretation. These methods can abstract a program into a heterogeneous graph of object relationships that integrates an abstract syntax tree, a control flow graph, and a program dependency graph. Potential risks can then be queried through preset rules or static analysis.

[0004] However, when detecting vulnerabilities based on static analysis, the analysis time often increases dramatically with the size of the code because highly sensitive analyses (such as flow-sensitive and context-sensitive vulnerabilities) require traversing a large number of code paths. Furthermore, when detecting vulnerabilities based on preset rules, omissions are likely because these rules are difficult to cover all vulnerability scenarios and variations. Summary of the Invention

[0005] This application provides a vulnerability detection method, apparatus, electronic device, and computer program product, which can solve the problem that the existing technology cannot improve the efficiency of vulnerability detection while ensuring the accuracy of detection.

[0006] In a first aspect, embodiments of this application provide a vulnerability detection method, the method comprising: For the target function to be detected, generate the first taint parameter that conforms to the parameter structure of the target function; The first tainted parameter is input into the target function for execution, and the execution characteristic information of the tainted expression corresponding to the first tainted parameter is recorded; the execution characteristic information includes at least one of the following: information describing the position of the tainted expression in the target function, and object information describing the object that the tainted expression points to at runtime. Static analysis is used to detect vulnerabilities in runtime characteristic information to obtain vulnerability information.

[0007] In one embodiment, a first taint parameter is input into the target function for execution, and the execution characteristic information of the taint expression corresponding to the first taint parameter is recorded, including: When the first taint parameter is input into the objective function, the values ​​generated by each expression in the objective function at runtime are determined; If the value originates from the first taint parameter, the expression is determined to be a tainted expression, and the first position of the expression is determined to be the position information in the running feature information.

[0008] In one embodiment, a first taint parameter is input into the target function for execution, and the execution characteristic information of the taint expression corresponding to the first taint parameter is recorded, including: Determine the target object that the pollution expression points to when it runs; When the target object is a data object, the second position of the target object and the corresponding prototype chain information are determined as the object information in the running feature information; When the target object is a function, the function is identified as the object information in the runtime characteristic information.

[0009] In one embodiment, a first taint parameter is input into the target function for execution, and the execution characteristic information of the taint expression corresponding to the first taint parameter is recorded, including: Determine the target property that needs to be accessed when the property access expression is executed during the execution of the target function; If the first taint parameter does not include the parameter corresponding to the target attribute, then add a second taint parameter corresponding to the target attribute. Record the runtime characteristic information of the contamination expressions corresponding to the first taint parameter and the second taint parameter.

[0010] In one embodiment, after performing vulnerability detection on runtime characteristic information using static analysis to obtain vulnerability information, the method further includes: Identify the vulnerability convergence point; the vulnerability convergence point is the location in the target function that receives the first taint parameter and triggers the vulnerability. During the execution of the target function, identify the sub-functions in the execution path that include the vulnerability convergence point; The input parameter template combination is generated based on the parameter structure; the input parameter template combination includes multiple input parameter templates, and one or more placeholders in each input parameter template are filled with random values. For any input parameter template, the input parameter template is input into the sub-function for execution, and the valid input parameter templates for the random value propagated to the vulnerability convergence point are determined. Exploit code is generated based on valid input parameter templates.

[0011] In one embodiment, the input parameter template is input into a sub-function for execution, and the valid input parameter template for propagating random values ​​to the vulnerability convergence point is determined, including: If all random values ​​in the input parameter template are propagated to the vulnerability convergence point during the execution of the sub-function, then the input parameter template is determined to be a valid input parameter template. If at least one random value in the input parameter template does not pass through the vulnerability convergence point, the input parameter template is determined to be an invalid input parameter template.

[0012] In one embodiment, generating exploit code based on a valid input parameter template includes: For any valid input parameter template, a random value in the valid input parameter template is replaced with a preset danger value to obtain a test case; The test cases are input into the sub-function for execution to determine the triggering result of the vulnerability; If the trigger result is that the vulnerability is triggered, exploit code containing test cases will be generated.

[0013] Secondly, embodiments of this application provide a vulnerability detection device, which includes: The first generation module is used to generate first taint parameters that conform to the parameter structure of the target function to be detected. The recording module is used to input the first tainted parameter into the target function for execution and record the execution characteristic information of the tainted expression corresponding to the first tainted parameter; the execution characteristic information includes at least one of the following: position information describing the tainted expression in the target function and object information describing the object pointed to by the tainted expression at runtime. The detection module is used to perform vulnerability detection on runtime characteristic information using static analysis to obtain vulnerability information.

[0014] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0016] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the method described in the first aspect.

[0017] The beneficial effects of this application embodiment compared with the prior art are as follows: For the target function to be detected, a first tainted parameter conforming to its parameter structure is generated, which ensures that the first tainted parameter is highly matched with the input format of the target function. This avoids omissions in the propagation path of the first tainted parameter in the target function due to parameter structure incompatibility, improves the propagation path coverage of taints during the execution of the target function, and provides more comprehensive basic data for subsequent vulnerability detection. Then, the first tainted parameter is input into the target function for execution, and the execution characteristic information of the tainted expression is recorded. The execution characteristic information includes at least one of the following: information describing the position of the tainted expression in the target function, and object information describing the object pointed to by the tainted expression at runtime. By dynamically executing and capturing runtime details that are difficult to obtain through static analysis, the specific carrier of taint propagation (e.g., the tainted expression) is clearly identified, and the position information of the carrier in the target function can be located, providing a basis for vulnerability root cause analysis and compensating for the ambiguity caused by the lack of runtime information in traditional static analysis. Finally, static analysis is used to perform vulnerability detection on the above-mentioned execution characteristic information, achieving a deep integration of dynamic runtime data and static code analysis. In other words, static analysis excels at uncovering potential risks by traversing code paths, while dynamically recorded runtime characteristic information can focus on tainted expressions related to the first tainted parameter, filtering out redundant code interference unrelated to the first tainted parameter during the target function's runtime, significantly reducing the amount of code processing required for static analysis. Simultaneously, based on runtime characteristic information from actual runtime, static analysis can more accurately identify vulnerability triggering conditions, improving detection accuracy. Therefore, through the progressive logic of first tainted parameter injection with parameter structure adaptation, runtime characteristic information capture, and static analysis, vulnerability detection efficiency can be improved while ensuring detection accuracy. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the implementation of a vulnerability detection method according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating one implementation method for generating runtime characteristic information in a vulnerability detection method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating one implementation method for generating runtime characteristic information in a vulnerability detection method provided in another embodiment of this application; Figure 4This is a schematic diagram illustrating one implementation method for generating runtime characteristic information in a vulnerability detection method provided in another embodiment of this application; Figure 5 This is a schematic diagram illustrating one implementation method for generating vulnerability exploitation code in a vulnerability detection method provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating one implementation method for generating exploit code in a vulnerability detection method provided in another embodiment of this application; Figure 7 This is a flowchart illustrating the implementation of a vulnerability detection method according to another embodiment of this application; Figure 8 This is a schematic diagram of the structure of a vulnerability detection device provided in one embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should be noted that the information collection process (such as patient information collection process, physiological information collection process, etc.) / feature extraction process corresponding to this application is carried out with the user's knowledge and permission. That is, the information collection process / feature extraction process complies with the requirements of laws and regulations and does not constitute an act that harms the public interest.

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] In the field of software security, injection vulnerabilities are a core risk threatening system security. Essentially, untrusted input (taints) flows into dangerous operations (convergence points) without proper handling, leading to unexpected behavior. While the detection of traditional injection vulnerabilities (such as command injection and code injection) has developed into a mature system centered on taint analysis, prototype chain pollution vulnerabilities are more difficult to detect due to their unique characteristics.

[0025] For prototype chain pollution vulnerabilities, existing mainstream detection technologies are based on taint analysis methods that use abstract interpretation. These methods can abstract a program into an object relation heterogeneous graph (ODGen) that integrates an abstract syntax tree, a control flow graph, and a program dependency graph. Potential risks can then be queried through preset rules or static analysis.

[0026] For example, using ODGen, this method represents a program as a heterogeneous graph containing edges and nodes. Edges represent the operational relationships between objects, and nodes contain Abstract Syntax Tree (AST) nodes and the objects themselves. This graph integrates key information from the Abstract Syntax Tree (AST), Control Flow Graph (CFG), and Program Dependency Graph (PDG), providing convenience for unified query analysis. Specifically, for the detection of prototype chain pollution vulnerabilities, the query rules are roughly as follows: (1) The attribute p of an object o in the graph is assigned a value to another object v that has not undergone harmless processing; (2) The attribute p of object o is assigned a value that has not undergone harmless processing (which may be a dangerous attribute such as proto), and at this time o may point to a built-in object prototype (such as Object.prototype).

[0027] The main drawbacks of the aforementioned methods are: 1) Inherent limitations of static analysis based on abstract interpretation. That is, to improve analysis accuracy, these methods typically need to support flow-sensitive, context-sensitive, and branch-sensitive analysis. However, high sensitivity significantly reduces analysis efficiency, especially branch-sensitive analysis, which requires constraint solving, leading to excessively long analysis times and poor scalability for large-scale programs. 2) Limitations at the implementation level of taint analysis. Because it requires separate modeling and definition of corresponding taint propagation rules for different language features, it is difficult to cover all scenarios and prone to missed detections.

[0028] Based on the above explanation, it can be concluded that when detecting vulnerabilities based on static analysis, the analysis time often increases dramatically with the size of the code because highly sensitive analyses (such as flow-sensitive and context-sensitive analyses) require traversing a large number of code paths. Furthermore, when detecting vulnerabilities based on preset rules, omissions are likely to occur because the preset rules are difficult to cover all vulnerability scenarios and variations.

[0029] Based on this, in order to improve the efficiency and accuracy of vulnerability detection, this application provides a vulnerability detection method that can be applied to electronic devices such as tablet computers, laptops, ultra-mobile personal computers (UMPCs), and netbooks. This application does not impose any restrictions on the specific type of electronic device.

[0030] Please see Figure 1 , Figure 1 The following is a flowchart illustrating the implementation of a vulnerability detection method provided in an embodiment of this application. The method includes the following steps: S101. For the target function to be detected, generate the first taint parameter that conforms to the parameter structure of the target function.

[0031] In one embodiment, the aforementioned target function refers to the specific object of vulnerability detection analysis. It can be complete program code (such as a standalone script file) or a portion of the code implementing a specific function (such as a function, method, or code block). For example, the target function could be the `merge` function in JavaScript, the `process_data` method in Python, etc. Its code language is typically a high-level programming language, such as JavaScript, Python, Java, or other machine languages; there is no limitation on this.

[0032] The parameter structure described above refers to the format specification of the input parameters received by the target function, including the parameter type (such as string, object, array), organization (such as JSON key-value pairs, XML tag nesting, comma-separated lists), and nesting level (such as second-level nesting of {a: {b: "value"}}). For example, if the target function requires input as a JSON object containing name and config fields, where config is an array, then its parameter structure follows this format specification.

[0033] The "taint" in the first tainted parameter refers to untrusted input data, such as potentially malicious content like the dangerous string "proto". The first tainted parameter is a customized input based on the parameter structure of the target function. It conforms to the format requirements of the parameter structure (ensuring it can be correctly received and processed by the target function) and includes markers for tracking propagation (such as specific strings or random values). Its purpose is to simulate malicious input in real-world attack scenarios, trace its propagation path within the target function, and provide a basis for subsequent vulnerability detection.

[0034] As an example, the first taint parameter mentioned above can be generated using the following example: Obtaining the parameter structure: This parameter structure can be predefined by the user, or the electronic device can determine the format specification of the parameters it receives by statically analyzing the definition of the target function (such as function signature, parameter verification logic) or runtime logs.

[0035] Implanting taint markers: Provided the parameter structure described above is met, specific values ​​in the parameters can be replaced with traceable taint markers, typically specific identifiers. For example, taint_7f9d2, ensuring the markers can be recognized by subsequent instrumentation logic.

[0036] Verify format compatibility: Input the generated first tainted parameter into the parameter validation logic of the target function, such as the preprocessing function, to confirm that it has not been filtered or reported as an error and can enter the processing flow of the target function.

[0037] Based on the above explanation, it can be assumed that the first tainted parameter must be able to be received and processed by the objective function, and during the processing, the tainted mark can be traced by the subsequent instrumentation logic to identify which expressions are tainted by the first tainted parameter.

[0038] Instrumentation logic refers to the design logic that inserts specific monitoring code into the target program's code to track, record, or analyze the program's runtime behavior (such as variable passing, function calls, and data flow). Its core purpose is to obtain key runtime information without disrupting the program's original functionality, providing data support for subsequent analysis (such as vulnerability detection, performance monitoring, and debugging). This embodiment does not provide a detailed explanation of instrumentation logic.

[0039] S102. Input the first taint parameter into the target function and run it, and record the running characteristic information of the taint expression corresponding to the first taint parameter.

[0040] The runtime characteristic information includes at least one of the following: information describing the location of the polluting expression in the objective function, and object information describing the object that the polluting expression points to at runtime.

[0041] In one embodiment, the execution of the target function refers to the execution of the target function's code logic (such as function calls, data processing, branch judgments, etc.) after the first tainted parameter is input into the target function, simulating the process of the target function receiving and processing input in a real-world scenario. For example, in JavaScript, calling merge(obj) and passing in the first tainted parameter obj means that the execution of the merge function is the execution of the target function.

[0042] The pollution expression mentioned above refers to an expression (code snippet) that directly or indirectly uses the first tainted parameter during the execution of the target function. Pollution indicates that the result of the expression's operation or the operand is affected by the first tainted parameter.

[0043] For example, if the first tainted parameter is {key:"taint_123"}, then in const value=obj.key, obj.key is an expression that directly uses the tainted parameter, which is a tainted expression; if the subsequent code executes result+=value, then result+= value is also a tainted expression because it indirectly uses the value of the tainted parameter.

[0044] As an example, the types of tainted expressions include, but are not limited to, dynamic property access expressions (expressions that access properties by using the value of the first tainted parameter as the property name), tainted and unpurified property access expressions (if the key name or value used in the property access comes from the first tainted parameter and has not been purified), and expressions pointing to functions (expressions that directly or indirectly reference functions, and the source of the function reference or the call parameter is related to the first tainted parameter), without limitation.

[0045] The aforementioned runtime characteristic information refers to the key attributes exhibited by the polluted expression at runtime, which is the core basis for subsequent vulnerability detection. It typically includes the object information of the object that the polluted expression points to at runtime and the position information of the polluted expression itself in the target function.

[0046] The object information of the object being pointed to refers to the information about the object that the tainted expression actually operates on or is associated with at runtime. For example, if the tainted expression is target[prop]=value, and prop comes from the tainted parameter, then the object information includes the specific object of target (such as {a:1}), the actual value of prop (such as proto), and the source of value (such as the marker in the first tainted parameter); if the expression corresponds to a prototype chain, it also includes the prototype chain information it points to, such as the prototype object (such as Object.prototype).

[0047] The location information mentioned above refers to the specific location of the tainted expression in the code, usually represented by the filename, line number, and column number. For example, utils.js:15:8 is used to precisely locate the code segment affected by the taint, facilitating the association with source code logic during subsequent static analysis.

[0048] It should be noted that by dynamically executing the target function, runtime details that are difficult to access through static analysis can be captured, and the runtime characteristic information of tainted expressions can be accurately obtained. This not only makes up for the ambiguity of static analysis in describing dynamic behavior, but also filters redundant information by focusing on taint-related paths, providing real, focused and directly related fine-grained evidence for subsequent static analysis. This improves the accuracy of vulnerability detection while reducing irrelevant data interference to improve efficiency.

[0049] S103. Use static analysis to perform vulnerability detection on runtime characteristic information to obtain vulnerability information.

[0050] In one embodiment, the aforementioned static analysis method refers to a method that determines the existence of vulnerabilities by analyzing static information such as the syntax structure, variable relationships, and function calls of the source code without actually running the program. In this embodiment, the static analysis method is a non-flow-sensitive, non-context-sensitive, and non-branch-sensitive analysis method. That is, it does not track the code execution order (flow-sensitive), does not distinguish the context of function calls (context-sensitive), and does not analyze the execution probability of conditional branches (branch-sensitive), thereby simplifying the analysis logic and improving efficiency.

[0051] For example, static analysis includes, but is not limited to, data flow analysis, control flow analysis, pointer analysis, type analysis, pattern matching and rule checking, etc., and is not limited thereto.

[0052] The aforementioned vulnerability detection refers to the process of analyzing the correlation between static code and runtime characteristic information through preset rules to determine whether a prototype chain pollution vulnerability exists. Vulnerability information refers to the key vulnerability attributes contained in the detection results, such as the code location of the vulnerability (combined with runtime characteristic location information), triggering conditions (such as specific pollution expressions and pointer relationships), and risk level, etc., without any limitations.

[0053] As an example, if a pollution expression of the form expr[prop]=value exists, and the execution characteristics include expr pointing to the prototype object and value being the polluted value; or in a pollution expression of the form expr[prop], prop is the polluted string, and the prototype of expr is the built-in Object (i.e., expr points to Object.prototype); or other assignment, static property access, or other expressions that conform to general pointer analysis rules, then it can be determined that a prototype chain pollution vulnerability exists, and vulnerability information including location, triggering conditions, etc., will be output.

[0054] It should be noted that the runtime characteristic information has been dynamically and precisely filtered to identify the polluted expressions contaminated by the first pollution parameter. These polluted expressions are key nodes in the taint propagation path and also high-risk areas where vulnerabilities may exist. During static analysis, it is only necessary to focus on these marked expressions, combining their recorded object information (such as the prototype object they point to, function references) and location information (such as code line numbers), and perform matching analysis against preset vulnerability rules. Furthermore, compared to traditional static analysis, which requires traversing all code paths of the entire program and analyzing all expressions (including a large amount of logic unrelated to the input), the vulnerability detection method in this embodiment significantly reduces the processing scope of static analysis, thereby significantly improving analysis efficiency while ensuring the targeting of vulnerability detection.

[0055] In this embodiment, a first tainted parameter conforming to the parameter structure of the target function to be detected is generated. This ensures a high degree of matching between the first tainted parameter and the input format of the target function, avoiding omissions in the propagation path of the first tainted parameter in the target function due to parameter structure incompatibility. This improves the coverage of the propagation path of the taint during the execution of the target function, providing more comprehensive basic data for subsequent vulnerability detection. Next, the first tainted parameter is input into the target function for execution, and the runtime characteristic information of the tainted expression is recorded. The runtime characteristic information includes at least one of the following: information describing the position of the tainted expression in the target function, and object information describing the object pointed to by the tainted expression at runtime. By dynamically executing and capturing runtime details that are difficult to obtain through static analysis, the specific carrier of taint propagation (e.g., the tainted expression) is clearly identified, and the position of the carrier in the target function can be located, providing a basis for vulnerability root cause analysis and overcoming the ambiguity caused by the lack of runtime information in traditional static analysis. Finally, static analysis is used to perform vulnerability detection on the above-mentioned runtime characteristic information, achieving a deep integration of dynamic runtime data and static code analysis. In other words, static analysis excels at uncovering potential risks by traversing code paths, while dynamically recorded runtime characteristic information can focus on tainted expressions related to the first tainted parameter, filtering out redundant code interference unrelated to the first tainted parameter during the target function's runtime, significantly reducing the amount of code processing required for static analysis. Simultaneously, based on runtime characteristic information from actual runtime, static analysis can more accurately identify vulnerability triggering conditions, improving detection accuracy. Therefore, through the progressive logic of first tainted parameter injection with parameter structure adaptation, runtime characteristic information capture, and static analysis, vulnerability detection efficiency can be improved while ensuring detection accuracy.

[0056] In one embodiment, based on the above description of the pollution expression, the electronic device can be configured according to, for example... Figure 2 Steps S201-S202, as shown, record the aforementioned operational characteristic information. Details are as follows: S201. When the first taint parameter is input into the objective function, determine the values ​​generated by each expression in the objective function during runtime.

[0057] In one embodiment, an expression is a code snippet used in a program to calculate and produce a value, which can be composed of variables, constants, operators, function calls, etc. For example: basic operation expressions: a+b (produces the sum of a and b), obj.prop (produces the value of the prop property of object obj); function call expressions: fn(taintParam) (produces the return value of function fn after receiving the tainted parameter); dynamic property access expressions: target[key] (key is a variable, producing the value of the property corresponding to key in target).

[0058] The above expression will be executed and generate a specific result when the program runs. Its value may be directly or indirectly affected by the input parameters (such as the first taint parameter).

[0059] It should be noted that during the process of the objective function receiving the first taint parameter and executing it, the actual values ​​of all expressions in the objective function under the current execution scenario can be captured in real time through dynamic tracing (such as instrumentation logic and runtime monitoring), which can clarify the specific impact of taint propagation.

[0060] Specifically, the first tainted parameter, as a tagged untrusted input, has its value passed to other variables or objects through expression evaluation (e.g., in x=taintParam.id, the value of x is determined by the id field of the first tainted parameter). Recording the runtime values ​​of these expressions allows for a clear tracking of how the taint permeates from the input to various processing stages of the function.

[0061] S202. If the value originates from the first taint parameter, then the expression is determined as a taint expression, and the first position of the expression is determined as the position information in the running feature information.

[0062] Specifically, if the runtime value of an expression directly or indirectly originates from the first tainted parameter, meaning its generation depends on the content of the first tainted parameter (e.g., the value of x in x=taintParam.name directly comes from the tainted parameter, or the value of y in y=x+1 indirectly comes from the tainted parameter), then the expression is marked as a tainted expression. Simultaneously, the specific location of this tainted expression in the code (i.e., the first location) is recorded as part of the runtime characteristic information.

[0063] Furthermore, if the runtime value of an expression is unrelated to the first tainted parameter—that is, the value's generation does not depend on anything of the tainted parameter, or only on constants or untainted variables within the function—then the expression will not be marked as a tainted expression, and its location information does not need to be included in the runtime characteristic information. Therefore, such expressions can be considered unaffected by untrusted input (the first tainted parameter), do not involve taint propagation, and will not become trigger points for vulnerabilities. Based on this, filtering these expressions can reduce the interference of irrelevant data on subsequent analysis, further focusing on high-risk taint paths and improving detection efficiency.

[0064] In this embodiment, by dynamically tracking the source of the runtime values ​​of each expression, the tainted expressions related to the first taint parameter can be marked and their code locations recorded. This not only accurately determines the taint propagation range to avoid invalid analysis, but also provides the core basis for linking static code and dynamic data for runtime feature information.

[0065] In another embodiment, the electronic device can be based on, for example... Figure 3 Steps S301-S303, as shown, record the aforementioned operational characteristic information. Details are as follows: S301. Determine the target object that the pollution expression points to when it runs.

[0066] In one embodiment, the target object refers to the specific entity that the pollution expression directly operates on, references, or associates during program execution. The target object can be considered as the target of the pollution expression's runtime behavior, which can be either a data storage structure or an executable code block.

[0067] For example, target objects can be categorized into types such as data objects or functions. Data objects can be collections of key-value pairs used to store data, serving as the fundamental structure for carrying information in a program. For instance, data objects include, but are not limited to, ordinary objects, built-in data objects, and special objects; there is no specific limitation on these types.

[0068] Data objects are used to store and transmit data, and their attribute values ​​can be primitive types (strings, numbers, etc.), other data objects, or functions.

[0069] Furthermore, functions, as entities of executable code blocks, typically pollute the execution unit pointed to by expressions that directly reference or access it through properties when the function is the target object. Examples include ordinary functions, object methods, and built-in functions. When a function is the target object, the target object can be invoked and executed, thereby affecting the program's logical flow or data processing.

[0070] It should be noted that by determining the specific entity (data object or function) that the tainted expression points to, it is possible to determine whether the taint has propagated to sensitive structures (such as prototype objects) or dangerous operations (such as calling the eval function), which is the core basis for subsequent vulnerability detection (such as prototype chain taints and command injection).

[0071] The electronic device can determine the target object in the following manner, as detailed below: Direct reference resolution method: For expressions that directly reference, such as obj and fn, the memory entity (data object or function) that it points to is directly recorded.

[0072] Property access tracing method: For property access expressions such as expr.prop or expr[prop], after parsing the actual object that expr points to, the entity corresponding to its prop property is obtained (if prop is a dynamic value, the result of prop calculated at runtime needs to be combined).

[0073] Prototype chain lookup method: If the property accessed by the expression does not exist in the current object, its prototype chain needs to be traced (such as obj.__proto) to determine the prototype object (data object) that ultimately retrieves the property value.

[0074] Function call association method: For function call expressions such as expr(), determine the function entity that expr itself points to, and the data object that the this keyword inside the function points to.

[0075] In this embodiment, the method for determining the target object is not limited.

[0076] S302. When the target object is a data object, the second position of the target object and the corresponding prototype chain information are determined as the object information in the running feature information.

[0077] In one embodiment, the second position refers to the definition location of the data object in the code, and its representation is similar to that of the first position, so it will not be described further. It should be noted that, unlike the first position (the code location that pollutes the expression itself), the second position is the source of the data object being operated on, used to trace the object's creation logic.

[0078] The aforementioned prototype chain information refers to the hierarchical relationship and key attributes of a series of prototype objects associated with a data object through the prototype chain. It may include information such as direct prototype objects, indirect prototype objects, the type and identifier of prototype objects, the key attributes and methods of prototype objects, and the hierarchical structure of the prototype chain, without any limitations.

[0079] For example, taking direct prototype objects and indirect prototype objects as examples, the direct prototype object is the prototype that the data object points to directly through the proto property (such as the direct prototype of a regular object is Object.prototype, and the direct prototype of an array is Array.prototype); the indirect prototype object is the upper prototype on the prototype chain (such as the prototype of Array.prototype is Object.prototype, which ultimately points to null).

[0080] In one embodiment, the electronic device can obtain prototype chain information through dynamic runtime tracing combined with a preset prototype chain mechanism for real-time parsing. For example, for a target data object, the `proto` attribute value can be directly obtained to determine the direct prototype object; alternatively, the `proto` attribute of the prototype object can be recursively accessed until null, constructing a complete prototype chain hierarchy; or, the type (built-in / custom) and definition location of each prototype object can be recorded (e.g., built-in prototypes are marked as engine-built-in, and custom prototypes record their code location). In this embodiment, the method for determining the prototype object is not limited.

[0081] It's important to note that the second location of a data object can be used to correlate its initial state at creation (e.g., whether it's a user-controllable object, whether it's defined within a security context), helping to determine the risk level of object contamination. For example, if a data object is defined in a user input processing module, its likelihood of contamination is higher. Furthermore, the prototype chain is the core of JavaScript's inheritance mechanism and a key carrier of prototype chain contamination vulnerabilities. Therefore, recording prototype chain information can directly determine whether a contamination expression operates on a sensitive prototype object (such as Object.prototype). For example, when the contamination expression is obj[prop]=value, and obj's prototype chain includes Object.prototype and prop is __proto__, it matches the prototype chain contamination vulnerability rule.

[0082] Based on this, the second position of the target object and its corresponding prototype chain information are identified as runtime characteristic information. This can not only locate the source of the data object, but also trace its prototype inheritance relationship, providing a complete context of object source and prototype association for static analysis, thereby improving the accuracy of vulnerability detection.

[0083] S303. When the target object is a function, the function is identified as the object information in the runtime characteristic information.

[0084] In one embodiment, once the actual function entity (such as fn, obj.method, or the built-in function eval) pointed to by the contaminated expression is determined through dynamic tracking, the electronic device can incorporate relevant information about the function (such as function name, definition location, whether it is a built-in function, etc.) into the runtime characteristic information.

[0085] It should be noted that when a function is used as a target object, it is the core carrier of the program's execution logic. Recording function information can provide a foundation for subsequent functions such as identifying the risk of dangerous function calls and tracing the path of function contamination propagation.

[0086] Specifically, many vulnerabilities (such as command injection and code execution) are directly related to calling dangerous functions. For example, if a tainted expression points to a built-in function that can execute dynamic code, such as `eval` or `Function`, and the function's call parameters are affected by taints, then there may be a risk of code injection. Recording functions themselves can be directly associated with such high-risk operations.

[0087] Furthermore, when a function is the target object, taints can propagate further through parameter passing, return values, and other means. For example, if a tainted expression points to a function `fn` that uses a tainted parameter in its internal logic or returns it to another expression, then `fn` itself becomes a transit point for taint propagation. Recording `fn` can help subsequent analysis trace the indirect propagation path of taints.

[0088] In this embodiment, by determining the target object pointed to by the tainted expression during runtime, key information can be recorded in a targeted manner. For example, when the target object is a data object, recording its definition location (second location) and prototype chain information can provide a basis for tracing and associating data object-related vulnerabilities (such as prototype chain taints); and when the target object is a function, recording the function itself helps identify dangerous function calls and taint propagation paths. This not only improves the dimensions of runtime characteristic information and strengthens the linkage between dynamic data and subsequent static analysis, but also supports risk analysis of different types of target objects, thereby improving the targeting, depth, and accuracy of vulnerability detection.

[0089] In another embodiment, it should be noted that in dynamic taint analysis for vulnerability detection, the initial first taint parameter is often based on a pre-defined understanding of the target function's input structure (such as known parameter names and common input fields). However, in real-world scenarios, the target function's attribute access logic may contain dynamic attributes that are not covered by the pre-defined parameters. For example, the function may access attributes through obj[dynamicKey], and the values ​​of dynamicKey cannot be fully enumerated in the initial stage.

[0090] In the above scenario, if the first taint parameter does not contain the target attribute actually accessed during the execution of the target function (i.e., the parameter corresponding to the dynamic attribute name), the access process of the target attribute will be outside the taint tracking scope, resulting in some taint paths being missed (such as unmarked attribute values ​​being used for sensitive operations).

[0091] Therefore, in order to overcome the limitations of the first taint parameter setting and improve the completeness of taint tracking, the electronic device can, according to, such as Figure 4 The steps S401-S403 shown illustrate the acquisition of runtime characteristic information. Details are as follows: S401. Determine the target attribute that needs to be accessed when executing the attribute access expression during the execution of the target function.

[0092] In one embodiment, the above attribute access expression is a code snippet used in the program to access object attributes, and it comes in two forms: Static property access: The property name is fixed, such as obj.name (directly accessing the name property of obj); Dynamic property access: The property name is determined by a variable or expression, such as obj[prop] (the value of prop determines the actual property accessed, which may be the result of dynamic calculation).

[0093] The target property mentioned above is the name (in string form) of the property that the property access expression actually accesses at runtime. For example, if the value of prop in obj[prop] is "config" at runtime, then the target property is "config"; the target property of obj.__proto__ is "__proto__".

[0094] It should be noted that when the target function executes an attribute access expression (whether static or dynamic), the runtime context of the expression is parsed: for static attribute access (such as obj.age), the fixed attribute name ("age") is directly extracted as the target attribute; for dynamic attribute access (such as obj[key]), the specific value of key in the current runtime can be calculated (if key is a variable, its current value is taken; if key is an expression, its result is calculated), and this value is used as the target attribute (if the result is not a string, it can be automatically converted to a string form, such as the number 123 being converted to "123").

[0095] Based on the above explanation, by parsing the runtime context of the expression, we can determine all the attributes that the target function actually accesses during the actual execution, which will help us determine whether the first taint parameter covers all accessed attributes and ensure that taint tracking is thorough.

[0096] S402. If the first taint parameter does not include the parameter corresponding to the target attribute, then add a second taint parameter corresponding to the target attribute.

[0097] S403. Record the running characteristic information of the contamination expression corresponding to the first taint parameter and the second taint parameter.

[0098] In one embodiment, the aforementioned second taint parameter is a taint parameter added to supplement the taint tracking scope when the first taint parameter does not cover the target attribute actually accessed during the execution of the target function. Essentially, it is an input parameter corresponding to the target attribute not included in the first taint parameter, used to ensure that the access process of the target attribute and related taint paths can be included in the tracking scope.

[0099] For example, if the target function accesses the target property "ext" at runtime, but the first tainted parameter initially set only contains "name" and "id", then a second tainted parameter corresponding to "ext" (such as {ext: tainted value}) is added so that access to properties related to "ext" (such as obj["ext"]) can be marked as a tainted expression.

[0100] In one embodiment, after determining the target attribute, it can be checked whether the target attribute is already included in the first taint parameter. That is, whether there is a corresponding key name in the first taint parameter. For example, if the first taint parameter is {name:taint}, then it includes "name" but does not include "ext". Then, if it is determined that the first taint parameter does not include the target attribute, a corresponding taint parameter (with a preset taint mark value, such as a random string or special mark, as the key name) can be generated as the second taint parameter (e.g., {ext:taint mark}). Finally, the electronic device can also input the second taint parameter into the target function to ensure that the access process of the target attribute can be captured by taint tracking.

[0101] Understandably, by first determining the target attribute actually accessed during the execution of the objective function, all attribute operations, including dynamic attribute access, can be accurately captured, resolving the issue that the initially set first taint parameter may not provide comprehensive coverage due to preset limitations. When the first taint parameter does not include the target attribute, a corresponding second taint parameter is added to dynamically supplement the taint tracking range, ensuring that attribute access paths not covered by the initial parameter (such as attribute names determined by user input or dynamic calculation) are not missed. Based on this, by recording the runtime characteristic information of the taint expressions corresponding to the first and second taint parameters, both the original taint path data covered by the first taint parameter and the supplementary taint paths added by the second taint parameter (i.e., attribute access-related paths not covered by the first taint parameter) can be included in the analysis scope. Furthermore, this provides comprehensive taint path data for subsequent vulnerability detection, improving the comprehensiveness and accuracy of vulnerability detection.

[0102] In another embodiment, during vulnerability detection, generating effective exploit code after a vulnerability is discovered is a necessary step to verify its exploitability and assess its risk level. However, the current method of manually writing exploit code has significant shortcomings: this process heavily relies on in-depth analysis of the vulnerability triggering logic by humans, but the target function often contains multiple layers of sub-function calls, complex parameter passing chains, and diverse branching logic, making it difficult for humans to accurately locate the vulnerability convergence point that receives tainted parameters and triggers the vulnerability, and even more difficult to clearly trace the propagation pattern of taints in the execution path of sub-functions. Consequently, it easily leads to lengthy exploit code development cycles and low success rates, failing to meet the need for efficient vulnerability verification.

[0103] Therefore, to improve the efficiency of generating exploit code, electronic devices can also... Figure 5 The steps S501-S505 shown below are detailed in the process of generating exploit code: S501, Obtain the vulnerability aggregation point.

[0104] In one embodiment, the aforementioned vulnerability refers to a security risk point in the target function caused by code logic defects or improper design, resulting in the malicious exploitation of untrusted inputs (such as the first tainted parameter). For example: Prototype chain pollution vulnerability: When a tainted parameter modifies the prototype object (such as Object.prototype) through dynamic property assignment (such as obj[prop]=value), it leads to unexpected property inheritance; Injection vulnerabilities: Unpurified tainted parameters are directly passed to sensitive operations such as eval and SQL queries, leading to code execution or database injection. Logical vulnerabilities: Tainted parameters affect critical branch decisions (such as permission checks), leading to unexpected behaviors such as permission bypass. The essence of these vulnerabilities is that the propagation path of tainted parameters ultimately reaches sensitive operation points, causing security issues through these points.

[0105] Furthermore, the aforementioned vulnerability convergence point is the location within the objective function that receives the first taint parameter and triggers the vulnerability. Based on this, the vulnerability convergence point can be considered the endpoint of the taint propagation path and the core node for vulnerability triggering.

[0106] For example, in prototype chain pollution, `obj[__proto__] = pollution value` (this expression directly modifies the prototype object, causing a vulnerability); in SQL injection, `db.query("SELECT ... ... )`... The SQL statement `FROM users WHERE id="+tainted parameter"` is used to perform a SQL injection attack. The tainted parameter is directly appended to the query, triggering an injection vulnerability. Its core characteristic is that the first tainted parameter (or its tainted value) is used in a sensitive operation, and this operation directly leads to the vulnerability.

[0107] In one embodiment, the electronic device can combine static analysis and dynamic tracing to determine vulnerability convergence points. Specifically, the electronic device can first scan the target function code through static analysis to identify sensitive operations that may trigger vulnerabilities (such as dynamic attribute assignment, eval calls, database queries, etc.) and mark them as potential convergence points. Then, tainted parameters (first tainted parameter or second tainted parameter) are input into the target function, and the propagation path of the taint is traced through dynamic instrumentation, recording all expressions through which the taint flows. Finally, the potential convergence point and the endpoint of the taint propagation path are identified. If the input value of a sensitive operation comes directly or indirectly from the tainted parameter, and the operation satisfies the vulnerability triggering rules (such as modifying the prototype object, concatenating unpurified input), then the location of the sensitive operation (such as the line number or specific expression) is the vulnerability convergence point. Finally, by repeatedly executing the target function, it can be confirmed that the location reliably triggers the vulnerability when receiving the tainted parameter, eliminating sporadic or misjudged situations.

[0108] S502. When the target function is running, determine the sub-functions in the execution path that include the vulnerability convergence point.

[0109] In one embodiment, the execution path described above is the actual code logic chain that the target function traverses during its execution, consisting of function calls, branch judgments (such as if / else), and loop execution. For example, when the target function handleInput() runs, it first calls parseData() to parse the input, then enters processValid() through the if (isValid) branch, and finally executes outputResult(). This series of actual function calls and branch paths constitutes the execution path for this run. Its core is the actual execution flow of the program during runtime, rather than all possible paths in the static code.

[0110] Furthermore, the aforementioned sub-functions are functions that are directly or indirectly called during the execution of the target function, and are integral parts of the target function's execution logic. For example, if the target function A() calls B(), and B() in turn calls C(), then B() and C() are both sub-functions of A() (C() is an indirect sub-function). Sub-functions may be auxiliary functions defined within the target function, or they may be externally introduced library functions; their execution logic directly affects the overall behavior of the target function.

[0111] As an example, when the target function runs, the electronic device can record in real time all its called sub-functions and their corresponding execution paths (i.e., the order in which sub-functions are called, the parameters passed in, and the internal execution branches, etc.). Then, the electronic device can check whether these sub-function execution paths contain vulnerability convergence points (i.e., whether the code location of a vulnerability convergence point belongs to the code scope of a certain sub-function); if a sub-function's execution path contains a vulnerability convergence point, it is marked as a sub-function related to the vulnerability.

[0112] It's important to note that vulnerability convergence points may not reside directly within the target function itself, but rather within its called sub-functions. For example, the target function might call the sub-function `dangerFunc()`, and the vulnerability convergence point might be the `eval(taint)` expression within `dangerFunc()`. Identifying the sub-functions containing vulnerability convergence points allows us to focus on the critical execution stages that trigger the vulnerability, providing a precise scope for generating subsequent exploit code and preventing irrelevant functions from interfering with the analysis.

[0113] S503. Generate input parameter template combinations based on the parameter structure.

[0114] The above-mentioned input parameter template combination includes multiple input parameter templates, and one or more placeholders in each input parameter template are filled with random values.

[0115] In one embodiment, the input parameter template described above is a parameter framework created based on the parameter structure features of the target function (or sub-function), which includes one or more placeholders (such as {{key1}}, {{nested.prop}}) to simulate possible input parameter forms. These placeholders can be filled with random values ​​(such as random strings, numbers, nested objects, etc.) to form concrete parameter instances that can be directly input into the sub-function.

[0116] For example, if the parameter structure of the sub-function is an object containing a name attribute, and name may nest an id attribute, then the input parameter template can be designed as {name:{id:{{placeholder}}}}, where {{placeholder}} will be filled with random values ​​(such as "taint_123", 456, etc.) to generate specific parameters such as {name:{id:"taint_123"}}.

[0117] In one embodiment, generating the input parameter template combination needs to be based on the parameter structure of the target function (or sub-function), combined with vulnerability-related characteristics (such as parameter types and attribute names that the vulnerability convergence point depends on). Specifically, the process can be as follows: by statically analyzing the definition of the sub-function or dynamically tracing the parameters it receives at runtime, structural features such as parameter type (e.g., object, array, basic type), nesting level (e.g., three levels of nesting in obj.prop.subprop), and required / optional attributes are extracted. Afterwards, the electronic device can construct a template framework consistent with the original structure based on these parameter structure features.

[0118] As an example, if the parameter is an object and contains attributes 'a' and 'b', the base framework could be `{a:{{p1}}, b:{{p2}}}`; if the parameter is an array and its elements are strings, the base framework could be `[{{p1}}, {{p2}}]`. Then, by adjusting the position, number, or nesting depth of the placeholders, multiple variant templates are generated to cover possible parameter structure variations. For example, for object parameters, templates with additional attributes can be generated (`{a: {{p1}}, b: {{p2}}, c: {{p3}}}`); for nested structures, templates with different depths can be generated (`{a: {{p1}}}` and `{a: {b: {{p1}}}}`). Finally, random values ​​(such as random strings, values ​​with special characters, etc.) are assigned to the placeholders in each variant template to ensure that each template is a concrete parameter instance that can be directly input into the sub-function for execution, resulting in the input parameter template. The combination of multiple input parameter templates is the input parameter template combination described above.

[0119] It should be noted that the purpose of generating multiple input parameter templates is to cover different parameter structure possibilities and avoid omissions caused by a single template failing to meet the vulnerability triggering conditions; while filling in random values ​​is to determine whether the parameter structure can transmit data to the vulnerability convergence point by observing the value propagation trajectory.

[0120] S504. For any input parameter template, input the input parameter template into the sub-function and run it to determine the valid input parameter template for which random values ​​are propagated to the vulnerability convergence point.

[0121] In one embodiment, a valid input parameter template refers to a template whose random values, after being input into a sub-function, can be successfully propagated to the vulnerability convergence point. For example, the electronic device can add special markers (such as a specific prefix "taint_" or a memory address identifier) ​​to the random values ​​filled in the input parameter template, making them traceable simulated taints. Then, the input parameter template is run in the sub-function, and the flow of the random value is monitored in real time through instrumentation logic, recording which variables it is assigned to, which internal functions it is passed as a parameter to, and whether it participates in expression operations (such as attribute assignment or string concatenation). Finally, the runtime data of the vulnerability convergence point (such as the input values ​​and operands of the vulnerability convergence point expression) is checked to see if it contains the marked random value (or its derived values, such as concatenated strings or calculated results). If it does, it indicates that the parameter structure of the template supports the propagation of random values ​​to the vulnerability convergence point, and it is determined to be a valid input parameter template; otherwise, it is an invalid input parameter template.

[0122] It should be noted that, since an input parameter template may include multiple random values, in another embodiment, during the execution of the sub-function, if all random values ​​in the input parameter template are propagated to the vulnerability convergence point, the electronic device can determine that the input parameter template is a valid input parameter template. Otherwise, if at least one random value in the input parameter template does not pass through the vulnerability convergence point, the electronic device can determine that the input parameter template is an invalid input parameter template.

[0123] During the execution of the sub-function, dynamic tracing technology is used to monitor the propagation path of each random value in the input parameter template in real time, and the validity of the template is determined by whether all values ​​reach the vulnerability convergence point. Specifically, if all random values ​​in the input parameter template (whether directly or indirectly) are propagated to the vulnerability convergence point (i.e., the runtime data of the vulnerability convergence point contains the original or derived forms of all random values), then the template is marked as a valid input parameter template. For example, in the input parameter template {a:{{r1}}, b:{{r2}}}, r1 is passed to the convergence point via obj.a, and r2 is passed via obj.b → temp variable → convergence point. Since both arrive, the input parameter template can be considered a valid input parameter template.

[0124] Furthermore, if at least one random value in the input parameter template fails to reach the vulnerability's convergence point (i.e., its propagation path is interrupted before reaching the convergence point, or it never enters the logic related to the convergence point), then the input parameter template can be considered invalid. For example, in the input parameter template {a:{{r1}}, c:{{r2}}}, r1 reaches the convergence point, but the r2 factor function does not process the c attribute and is ignored, thus failing to reach the convergence point; therefore, the input parameter template is invalid.

[0125] In this embodiment, valid input parameter templates are filtered by determining whether all random values ​​in the input parameter template propagate to the vulnerability convergence point. This not only provides a reliable structural foundation for the subsequent generation of vulnerability exploitation code (ensuring that all propagation paths required for vulnerability triggering are covered), avoiding the generation of unusable code based on invalid structures, but also reduces redundant attempts and trial-and-error costs by excluding invalid templates, thereby improving the success rate and reliability of generating vulnerability exploitation code.

[0126] S505. Generate exploit code based on valid input parameter templates.

[0127] In one embodiment, the exploit code is a program or script that actively triggers the target vulnerability and demonstrates its harm. Its core function is to use carefully crafted input to exploit the vulnerability's triggering logic (such as parameter propagation paths and sensitive operation calls) to induce unexpected security consequences, thereby verifying the vulnerability's exploitability and assessing its risk level. Since valid input parameter templates can trigger vulnerabilities when run in sub-functions, electronic devices can directly generate exploit code from valid input parameter templates.

[0128] In this embodiment, by identifying the vulnerability convergence point that receives the first taint parameter and triggers the vulnerability, the core location of the vulnerability triggering can be determined, avoiding invalid analysis of irrelevant code regions. Simultaneously, focusing on sub-functions containing this convergence point in the execution path further narrows the analysis scope, allowing subsequent operations to concentrate on the critical logic related to the vulnerability and reducing redundant computation. Next, an input parameter template combination containing random value placeholders is generated based on the parameter structure. This not only covers possible parameter structures but also provides traceable markers for subsequent propagation verification through random values. Then, by dynamically running sub-functions to filter valid input parameter templates where all random values ​​can propagate to the vulnerability convergence point, the matching of the template structure with the vulnerability propagation path can be ensured, eliminating invalid attempts caused by incorrect parameter structures. Finally, exploit code is generated based on valid input parameter templates, preserving the verified parameter structure that reaches the vulnerability convergence point, ensuring that the generated exploit code can reliably trigger the vulnerability.

[0129] In another embodiment, the electronic device may also be based on, for example... Figure 6 The steps S601-S603 shown generate the exploit code. Details are as follows: S601. For any valid input parameter template, replace the random value in the valid input parameter template with a preset danger value to obtain a test case.

[0130] In one embodiment, the aforementioned preset danger value is a malicious value or characteristic content that is predefined according to the vulnerability type (such as prototype chain pollution, code injection, SQL injection, etc.) and can trigger the vulnerability.

[0131] For example, for prototype chain pollution vulnerabilities, the default danger value might be an object containing the "__proto__" attribute (such as {"__proto__": {"isAdmin": true}}), used to modify the prototype of the target object; for SQL injection vulnerabilities, the default danger value could be a string such as OR1=1 --, used to tamper with SQL query logic.

[0132] In this context, a test case refers to the specific input content obtained by replacing the random values ​​in a valid input parameter template with preset dangerous values. Test cases can retain the parameter structure (such as attribute nesting hierarchy and parameter type) in the valid input parameter template that enables the value to propagate to the vulnerability's convergence point, and only replace the random values ​​with preset dangerous values ​​that are offensive.

[0133] For example, if the valid input parameter template is {"user": {"id": "random value 1", "config": "random value 2"}}, and the default danger value for the prototype chain pollution vulnerability is "__proto__" related content, then the test case might be {"user": {"id": "123", "config": {"__proto__": {"privilege": "root"}}}}.

[0134] It's important to note that test cases can be run to verify whether the vulnerability aggregation point triggers vulnerabilities (such as privilege escalation or data leakage) when receiving hazardous values, providing practical verification of vulnerability exploitability. Understandably, valid input parameter templates ensure that preset hazardous values ​​reach the vulnerability aggregation point along the correct path, and these preset hazardous values ​​are responsible for triggering the vulnerability behavior. Therefore, test cases can accurately hit vulnerability triggering conditions and simulate real attack scenarios, providing an executable verification tool for assessing the actual harm of vulnerabilities.

[0135] S602. Input the test cases into the sub-function for execution and determine the triggering result of the vulnerability.

[0136] S603. If the trigger result is that the vulnerability is triggered, then generate vulnerability exploit code containing test cases.

[0137] In one embodiment, the aforementioned triggering result refers to the actual vulnerability-related result generated after the test case is input into the sub-function and executed, used to determine whether the test case successfully activated the vulnerability. That is, the triggering result includes whether the vulnerability was triggered or not.

[0138] In this case, if a pre-defined danger value in a test case reaches the vulnerability's convergence point along a valid path and causes unexpected security consequences, the vulnerability can be considered triggered. For example, a prototype chain pollution test case causes the target object to inherit malicious attributes (such as `isAdmin:true`); an SQL injection test case causes the database to execute a tampered query (such as returning all user data); and a code injection test case successfully executes a malicious script.

[0139] Furthermore, if a dangerous value in a test case does not trigger a security consequence, it may be due to the presence of a protection mechanism in the target environment (such as input filtering), an incorrect dangerous value format, or the existence of a propagation path but the failure to meet additional conditions for vulnerability triggering (such as specific branch logic). In such cases, the triggering result can be considered that the vulnerability has not been triggered.

[0140] When the trigger result indicates that a vulnerability has been exploited, this test case can be used as the core input of the exploit code to ensure that it can stably reproduce the parameter passing path that triggers the vulnerability. Afterwards, necessary calling code (such as `subFunction`) can be added based on the calling method of the sub-function (e.g., function name, parameter passing format) to simulate function call scenarios in a real-world environment.

[0141] It's worth noting that if the vulnerability triggering depends on specific environment configurations (such as variable initialization or pre-function calls), pre-function operations can be added to the exploit code to ensure the code can run directly in the target environment. Additionally, result verification logic can be added to the exploit code (such as checking whether malicious attributes are generated or sensitive data is returned) to help users confirm whether the vulnerability has been successfully exploited.

[0142] For example, for a prototype chain pollution vulnerability, if the test case {"user": {"__proto__": {"isAdmin": true}}} triggers privilege escalation, the generated exploit code can include the test case as input, along with the statement triggerVulnSubFunc that calls a sub-function, and include verification logic to check whether the isAdmin attribute is effective, thus generating the exploit code.

[0143] In this embodiment, test cases are generated by replacing random values ​​in the valid input parameter template with preset danger values. This retains the parameter structure in the valid template that has been verified to propagate values ​​completely to the vulnerability convergence point, and the test cases are given offensive capabilities by preset danger values ​​that match the vulnerability type. This solves the problem of danger values ​​failing to reach the vulnerability point due to structural errors or having correct structures but lacking offensive capabilities, making the test cases both effective in propagation and targeted in attack. Next, the test cases are input into sub-functions and the triggering results are determined. Execution feedback in a real environment verifies whether the vulnerability can be triggered, avoiding the generation of seemingly reasonable but unusable code based on theoretical speculation. That is, if the vulnerability is not triggered, the mismatch between the preset danger value and the environment (such as interception by protection mechanisms) or the lack of triggering conditions (such as failure to meet specific branch logic) can be promptly identified, providing a clear direction for optimizing the test cases; if the vulnerability is triggered, it proves that the structure of the test cases and the preset danger values ​​are compatible with the vulnerability logic. Finally, exploit code is generated only based on test cases where the vulnerability is triggered, ensuring that the final output code is an effective tool that has been verified to reliably trigger the vulnerability, rather than an empty structural template. Furthermore, this not only reduces the cost of generating redundant code based on invalid test cases, but also ensures that the exploit code can truly reflect the exploitability of the vulnerability through verification in actual operating scenarios, providing an accurate and operable basis for vulnerability risk assessment and remediation verification.

[0144] To more clearly illustrate the solutions in this application, specific embodiments are used below to explain the solutions. See details below. Figure 7 , Figure 7 This is a flowchart illustrating the implementation of a vulnerability detection method provided in another embodiment of this application.

[0145] Taking a JavaScript function as an example, where the target function suffers from prototype chain pollution, electronic devices can first perform dynamic runtime analysis on the target function (e.g., functions that handle object properties like mergeConfig) to collect runtime characteristic information. This includes information such as the target function call order, the assignment path of user input to internal objects, and the objects it points to.

[0146] Specifically, when the first tainted parameter is input into the target function, the values ​​generated by each expression in the target function at runtime can be determined. If the value originates from the first tainted parameter, the expression is identified as a tainted expression, and the first position of the expression is determined as runtime characteristic information. Furthermore, the target object pointed to by the tainted expression at runtime is determined; if the target object is a data object, the second position of the target object and its corresponding prototype chain information are determined as runtime characteristic information; or, if the target object is a function, the function is determined as runtime characteristic information.

[0147] Furthermore, during the execution of the objective function, the target attribute to be accessed when executing the attribute access expression is determined. If the first tainted parameter does not include the parameter corresponding to the target attribute, a second tainted parameter corresponding to the target attribute is added, and the execution characteristic information of the tainted expression corresponding to the first tainted parameter and the second tainted parameter is recorded.

[0148] Finally, the electronic device can dynamically run based on the objective function to obtain runtime characteristic information and statically analyzed vulnerability information to derive taint propagation, obtain a valid input parameter template, and synthesize vulnerability exploitation code based on the valid parameter input template.

[0149] Specifically, the electronic device can obtain the vulnerability convergence point and, during the execution of the target function, determine the sub-functions in the execution path that include the vulnerability convergence point. Then, based on the parameter structure, it generates multiple input parameter templates, with one or more placeholders in each template filled with random values. Next, for any given input parameter template, it is input into the sub-function for execution, determining the valid input parameter templates whose random values ​​are propagated to the vulnerability convergence point. Finally, for any valid input parameter template, the random values ​​in the valid input parameter template are replaced with preset danger values ​​to obtain test cases. These test cases are then input into the sub-function for execution. When the trigger result indicates that the vulnerability has been triggered, exploit code containing the test cases is generated.

[0150] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a vulnerability detection device provided in an embodiment of this application. The vulnerability detection device in this embodiment includes modules used for execution... Figures 1 to 6 The steps in the corresponding embodiments. Please refer to the details. Figures 1 to 6 as well as Figures 1 to 6 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown. See also... Figure 8 The vulnerability detection device 800 may include: a first generation module 810, a recording module 820, and a detection module 830, wherein: The first generation module 810 is used to generate first taint parameters that conform to the parameter structure of the target function to be detected.

[0151] The recording module 820 is used to input the first taint parameter into the target function for execution and record the execution characteristic information of the tainted expression corresponding to the first taint parameter; the execution characteristic information includes at least one of the following: information describing the position of the tainted expression in the target function and information describing the object pointed to by the tainted expression during execution.

[0152] The detection module 830 is used to perform vulnerability detection on runtime characteristic information using static analysis to obtain vulnerability information.

[0153] In one embodiment, the recording module 820 is further configured to: When the first taint parameter is input into the objective function, the values ​​generated by each expression in the objective function during runtime are determined; if the value originates from the first taint parameter, the expression is determined as a tainted expression, and the first position of the expression is determined as the position information in the runtime feature information.

[0154] In one embodiment, the recording module 820 is further configured to: Determine the target object that the pollution expression points to during runtime; when the target object is a data object, determine the second position of the target object and the corresponding prototype chain information as the object information in the runtime characteristic information; when the target object is a function, determine the function as the object information in the runtime characteristic information.

[0155] In one embodiment, the recording module 820 is further configured to: Determine the target property to be accessed when executing the property access expression during the execution of the target function; if the first tainted parameter does not include the parameter corresponding to the target property, add a second tainted parameter corresponding to the target property; record the execution characteristic information of the tainted expression corresponding to the first tainted parameter and the second tainted parameter.

[0156] In one embodiment, the vulnerability detection device 800 further includes: The acquisition module is used to acquire vulnerability convergence points; the vulnerability convergence point is the location in the target function that receives the first taint parameter and triggers the vulnerability. The determination module is used to identify sub-functions in the execution path that include vulnerability convergence points when the target function is running.

[0157] The second generation module is used to generate a combination of input parameter templates based on the parameter structure. The combination of input parameter templates includes multiple input parameter templates, and one or more placeholders in each input parameter template are filled with random values.

[0158] The input module is used to input any input parameter template into a sub-function for execution, and to determine the valid input parameter templates for which random values ​​are propagated to the vulnerability convergence point.

[0159] The third generation module is used to generate exploit code based on valid input parameter templates.

[0160] In one embodiment, the determining module is further configured to: During the execution of the sub-function, if all random values ​​in the input parameter template are propagated to the vulnerability convergence point, the input parameter template is determined to be a valid input parameter template; if at least one random value in the input parameter template does not pass through the vulnerability convergence point, the input parameter template is determined to be an invalid input parameter template.

[0161] In one embodiment, the third generation module is further configured to: For any valid input parameter template, a random value in the valid input parameter template is replaced with a preset danger value to obtain a test case; the test case is input into a sub-function for execution to determine the triggering result of the vulnerability; if the triggering result is that the vulnerability is triggered, vulnerability exploitation code containing the test case is generated.

[0162] When it is understood that, Figure 8 In the schematic diagram of the vulnerability detection device shown, each module is used to perform... Figures 1 to 6 The steps in the corresponding embodiments, and for Figures 1 to 6 The steps in the corresponding embodiments have been explained in detail in the above embodiments. Please refer to them for details. Figures 1 to 6 as well as Figures 1 to 6 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0163] Figure 9 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Figure 9 As shown, the electronic device 900 of this embodiment includes: a processor 910, a memory 920, and a computer program 930 stored in the memory 920 and executable on the processor 910, such as a program for a vulnerability detection method. When the processor 910 executes the computer program 930, it implements the steps in the various embodiments of the vulnerability detection methods described above, for example... Figure 1 S101 to S103 are shown. Alternatively, the processor 910 implements the above when executing the computer program 930. Figure 8 The functions of each module in the corresponding embodiments, for example, Figure 8 For details on the functions of each module shown, please refer to [link / reference]. Figure 8 The relevant descriptions in the corresponding embodiments.

[0164] For example, the computer program 930 can be divided into one or more modules, one or more of which are stored in the memory 920 and executed by the processor 910 to implement the vulnerability detection method provided in the embodiments of this application. One or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 930 in the electronic device 900. For example, the computer program 930 can implement the vulnerability detection method provided in the embodiments of this application.

[0165] Electronic device 900 may include, but is not limited to, processor 910 and memory 920. Those skilled in the art will understand that... Figure 9This is merely an example of electronic device 900 and does not constitute a limitation on electronic device 900. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0166] The processor 910 may be a central processing unit, or it may be other general-purpose processors, digital signal processors, application-specific integrated circuits, off-the-shelf programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0167] The memory 920 can be an internal storage unit of the electronic device 900, such as a hard disk or RAM of the electronic device 900. The memory 920 can also be an external storage device of the electronic device 900, such as a plug-in hard disk, smart memory card, flash memory card, etc., equipped on the electronic device 900. Furthermore, the memory 920 can include both internal storage units and external storage devices of the electronic device 900.

[0168] This application provides a computer-readable storage medium, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the vulnerability detection methods as described in the above embodiments.

[0169] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the vulnerability detection methods described in the above embodiments.

[0170] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A vulnerability detection method characterized by, The method comprises: For a target function to be detected, a first taint parameter conforming to a parameter structure of the target function is generated; The first taint parameter is input into the target function, and running feature information of a pollution expression corresponding to the first taint parameter is recorded; the running feature information comprises at least one of position information for describing the pollution expression in the target function and object information for describing an object pointed to by the pollution expression in running time; Vulnerability information of a vulnerability is obtained by performing vulnerability detection on the running feature information in a static analysis manner.

2. The method of claim 1, wherein, The first taint parameter is input into the target function, and running feature information of a pollution expression corresponding to the first taint parameter is recorded, comprising: When the first taint parameter is input into the target function, a value generated by each expression in the target function in running time is determined; If the value is derived from the first taint parameter, the expression is determined as the pollution expression, and a first position of the expression is determined as the position information in the running feature information.

3. The method of claim 1, wherein, The first taint parameter is input into the target function, and running feature information of a pollution expression corresponding to the first taint parameter is recorded, comprising: A target object pointed to by the pollution expression in running time is determined; When the target object is a data object, a second position of the target object and corresponding prototype chain information are determined as the object information in the running feature information; When the target object is a function, the function is determined as the object information in the running feature information.

4. The method of claim 1, wherein, The first taint parameter is input into the target function, and running feature information of a pollution expression corresponding to the first taint parameter is recorded, comprising: A target attribute to be accessed when an attribute access expression is executed in the target function running process is determined; If the target attribute corresponding parameter is not included in the first taint parameter, a second taint parameter corresponding to the target attribute is added; Running feature information of a pollution expression corresponding to the first taint parameter and the second taint parameter is recorded.

5. The method according to any one of claims 1 to 4, characterized in that, After the vulnerability information of the vulnerability is obtained by performing vulnerability detection on the running feature information in a static analysis manner, the method further comprises: A vulnerability convergence point of the vulnerability is obtained; the vulnerability convergence point is a position in the target function that receives the first taint parameter and triggers the vulnerability; When the target function is running, a sub-function including the vulnerability convergence point in an execution path is determined; An input parameter template combination is generated according to the parameter structure; the input parameter template combination comprises a plurality of input parameter templates, and one or more placeholders included in each input parameter template are respectively filled with random values; For any input parameter template, the input parameter template is input into the sub-function to run, and an effective input parameter template in which the random value is propagated to the vulnerability convergence point is determined; A vulnerability exploit code is generated based on the effective input parameter template.

6. The method of claim 5, wherein, The input parameter template is input into the sub-function to run, and it is determined that the random value is propagated to the effective input parameter template of the vulnerability convergence point, comprising: During the running of the sub-function, if all the random values in the input parameter template are propagated to the vulnerability convergence point, it is determined that the input parameter template is an effective input parameter template; If at least one of the random values in the input parameter template does not pass through the vulnerability convergence point, it is determined that the input parameter template is an invalid input parameter template.

7. The method of claim 6, wherein, The vulnerability exploit code is generated based on the effective input parameter template, comprising: For any effective input parameter template, a preset dangerous value is used to replace the random value in the effective input parameter template to obtain a test case; The test case is input into the sub-function to run, and the trigger result of the vulnerability is determined; If the trigger result is that the vulnerability is triggered, a vulnerability exploit code containing the test case is generated.

8. A vulnerability detection apparatus characterized by comprising: The device comprises: A first generation module configured to generate, for a target function to be detected, a first tainted parameter conforming to a parameter structure of the target function; A recording module configured to input the first tainted parameter into the target function to run and record running feature information of a pollution expression corresponding to the first tainted parameter; the running feature information comprises pointing information of the pollution expression and position information of the pollution expression; A detection module configured to perform vulnerability detection on the running feature information in a static analysis manner to obtain vulnerability information of a vulnerability.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method of any one of claims 1 to 7.

10. A computer program product, characterised in that, When the computer program product runs on the electronic device, the electronic device is caused to implement the method of any one of claims 1 to 7.

Images