A Java RESTful Interface Security Testing Method Based on Static Analysis

Abstract

The application relates to the technical field of network security, in particular to a Java Restful interface security test method based on static analysis, which comprises the following steps: generating a Jimple intermediate representation of source code of a target Java application; performing data flow analysis based on the Jimple intermediate representation to generate a complete data flow graph; identifying a pollution source and tracking a pollution propagation path on the basis of the data flow graph, judging whether a pollution object reaches a convergence point, and determining a vulnerable interface; extracting an interface routing signature in the pollution analysis process to generate routing signature information; grouping interfaces based on parent routing of the interfaces, performing interface security test in combination with the routing signature information, introducing a reinforcement learning method to dynamically optimize a test strategy, performing parameter variation and attack load injection of a test case on the vulnerable interface; and setting a security monitoring strategy in a dynamic plug-in manner, and completing interface security risk judgment according to recorded logs and the test case.

Description

Technical Field

[0001] The embodiments of this application relate to the field of network security technology, and in particular to a JavaRestful interface security testing method based on static analysis. Background Technology

[0002] With the large-scale deployment of microservice architectures and distributed systems, service interfaces, as the core carriers of data interaction and business linkage between the front-end and back-end of a system and between multiple service modules, are widely used in various Internet business systems. Mainstream service interfaces can be categorized into Restful, SOAP, GraphQL, gRPC, and WebSocket based on differences in communication protocols and data transmission modes. Among them, Restful interfaces are designed based on the REST (Representational State Transfer) architecture, a typical stateless network architecture style, and are the most widely used interface architecture pattern in the industry. Before an interface goes live, comprehensive and accurate automated testing is crucial for identifying interface vulnerabilities, mitigating business anomalies, and defending against network attacks. For the currently largest existing number of Restful interfaces, existing automated testing technologies are mainly divided into two branches: security testing and robustness testing. The implementation principles and testing objectives of these two types of testing technologies differ significantly.

[0003] The core objective of security testing is to uncover potential security vulnerabilities in interfaces. The mainstream approach combines passive traffic analysis with proactive vulnerability detection to conduct interface asset inventory and security risk assessment. Passive traffic analysis is primarily achieved through interface documentation crawling and network traffic interception, automatically identifying all interface endpoints, input parameter structures, output parameter formats, and other basic interface assets within the system. Proactive vulnerability detection can be divided into two categories: DAST (Dynamic Application Security Testing) and interactive application security testing. DAST technology directly launches simulated attacks against real online interfaces, constructing and delivering various malicious attack payloads in batches, observing the interface feedback results, and identifying risks such as privilege escalation, injection, and sensitive information leakage. Interactive application security testing relies on dynamic code instrumentation technology to embed monitoring probes within the service code, monitoring in real time whether external malicious input data can penetrate the interface validation logic and reach the monitoring points of the backend core business code, accurately locating security vulnerabilities at the code level.

[0004] The core objective of robustness testing is to verify the operational stability of an interface under abnormal input, invalid parameters, and abnormal call sequences. It is guided by code coverage and interface path coverage, primarily relying on parsing OpenAPI documentation to automatically generate standardized test cases. Based on whether the test is aware of the interface's internal code logic, existing robustness testing is divided into black-box testing and fuzz testing. Black-box testing relies solely on publicly available interface documentation, with its core research focus on the proper orchestration of multiple interface request sequences and the construction of complete business call chains to improve full-chain test coverage. Fuzz testing, on the other hand, is an automated mutation test. It uses test probes to collect code execution coverage data in real time for each round of testing. Using this coverage data as feedback, it automatically generates random parameters, malformed parameters, and boundary abnormal parameters in batches and continuously sends requests to the interface to uncover defects such as program crashes and business logic errors caused by abnormal input.

[0005] While existing RESTful API security and robustness testing systems have achieved automated testing implementation, in practical engineering applications, current automated testing solutions for RESTful APIs suffer from several shortcomings, including misaligned test guidelines, incomplete API asset collection, failure to consider parameters and API dependencies, and unreasonable test result judgment rules. These shortcomings make it difficult to meet the demands of high-precision, high-efficiency, and end-to-end integrated security and robustness testing in today's complex microservice scenarios. Therefore, there is an urgent need in this field for a novel automated testing method for RESTful APIs to address the technical pain points of existing technologies. Summary of the Invention

[0006] In view of this, embodiments of this application propose a Java RESTful interface security testing method based on static analysis. The method aims to accurately identify interface vulnerabilities through taint analysis technology, automatically extract interface routing signatures to improve interface information, dynamically optimize testing strategies based on reinforcement learning, and combine dynamic instrumentation to monitor security risks during interface runtime, thereby significantly improving the relevance and effectiveness of RESTful interface security testing.

[0007] To achieve the above objectives, embodiments of this application propose a Java implementation based on static analysis. A RESTful interface security testing method applicable to RESTful interfaces of Java applications includes the following steps: 1) Using the Soot tool to generate a Jimple intermediate representation of the target Java application's source code, unifying the modeling of various statement types into a combination structure of multiple statements and expressions; 2) Using the interface as the analysis entry point, performing data flow analysis based on object pointer analysis on the Jimple intermediate representation, constructing a pointer relationship graph, and then generating a complete data flow graph; 3) Based on the data flow graph, performing taint analysis, identifying taint sources and tracing taint propagation paths, determining whether tainted objects reach the convergence point, thereby identifying vulnerable interfaces; 4) Automating the extraction of interface route signatures during taint analysis, generating route signature information including at least the interface route, request method, parameter set, and parameter constraints; 5) Grouping interfaces based on their parent routes, and performing interface security testing in conjunction with the route signature information, introducing reinforcement learning methods to dynamically optimize the testing strategy during the interface security testing process, while simultaneously performing parameter mutation and attack payload injection for test cases on vulnerable interfaces; 6) Setting up security monitoring strategies through dynamic instrumentation, inserting monitoring probes into the target Java application, and determining interface security risks based on log records and test cases when the monitoring probes are triggered.

[0008] To achieve the above objectives, embodiments of this application also propose a Java RESTful interface security testing system based on static analysis, applicable to RESTful interfaces of Java applications. The system includes: an intermediate representation generation module, a data flow analysis module, a taint analysis module, a route signature extraction module, an interface security testing module, and a probe monitoring module. The intermediate representation generation module uses the Soot tool to generate a Jimple intermediate representation of the target Java application's source code, uniformly modeling various types of statements into a combination structure of multiple statements and expressions. The data flow analysis module uses the interface as the analysis entry point to perform object-oriented data flow analysis on the Jimple intermediate representation, constructing a pointer relationship graph to generate a complete data flow graph. The taint analysis module performs taint analysis based on the data flow graph, identifying taint sources and tracing them. The system tracks the propagation path of taints to determine whether tainted objects reach the convergence point, thereby identifying vulnerable interfaces. A route signature extraction module automatically extracts interface route signatures during taint analysis, generating route signature information that includes at least the interface route, request method, parameter set, and parameter constraints. An interface security testing module groups interfaces based on their parent routes and performs security testing using route signature information. Reinforcement learning methods are introduced to dynamically optimize testing strategies during interface security testing, while parameter mutation and payload injection are performed on vulnerable interfaces. A probe monitoring module sets up security monitoring strategies through dynamic instrumentation, inserting monitoring probes into the target Java application. When a monitoring probe is triggered, interface security risks are determined based on logs and test cases.

[0009] To achieve the above objectives, embodiments of this application also propose an electronic device comprising: a processor and a memory, wherein the memory stores instructions executable by the processor, and the processor is configured to execute the instructions such that the electronic device can implement a static analysis-based JavaRestful interface security testing method as described above.

[0010] To achieve the above objectives, embodiments of this application also propose a computer-readable storage medium storing a computer program that, when executed by a processor, enables a static analysis-based Java RESTful interface security testing method as described above.

[0011] Optionally, the method of generating a Jimple intermediate representation of the target Java application's source code using the Soot tool unifies the modeling of various types of statements into a combination structure of multiple statements and expressions, including: The source code of the target Java application is loaded using the Soot tool, and intermediate transformations are performed to generate the Jimple intermediate representation corresponding to the target Java application. Identify the statement types in the Jimple intermediate representation, including basic operation statements, assignment statements, branching statements, cross-procedural control flow statements, monitor statements, and exception handling statements; Branch statements, monitor statements, and exception handling statements are discarded. Basic operation statements and assignment statements are refined. The refined basic operation statements, refined assignment statements, and cross-process control flow statements are then modeled into a unified structure of multiple statements and expressions. In the composite structure, the expression is used to represent the data access object, data assignment object, and method call object in the corresponding statement. The expression is divided into lvalue expression and rvalue expression. The lvalue expression is used to represent the data carrier object that is assigned or referenced, and the rvalue expression is used to represent the data source object that propagates data to the lvalue expression.

[0012] Optionally, the step of using the interface as the analysis entry point to perform data flow analysis based on object pointer analysis on the Jimple intermediate representation, constructing a pointer relationship graph, and then generating a complete data flow graph includes: Using the interface as the analysis entry point, we traverse the Jimple intermediate representation and extract the interface and the data access object in the interface call chain based on the composite structure in the Jimple intermediate representation. Data access objects are abstracted into pointers, and pointer types include at least local variable pointers, static property pointers, instance property pointers, method parameter pointers, return value pointers, and receiver pointers; Create a pointer set for each pointer, and record the heap objects that the pointers can point to; where, the first... The set pointed to by each pointer is denoted as . , , Represents a heap object; Based on the statement types in the Jimple intermediate representation, the corresponding data flow propagation rules are determined, and the pointer set and the propagation relationship between different pointers are updated based on the data flow propagation rules. Specifically, when object creation statements and constructor call statements are identified in basic operation statements, a new heap object is created, and the newly created heap object is added to the pointer set that receives its creation result. When assignment statements are identified, the pointer set corresponding to its rvalue expression is propagated to the pointer set corresponding to its lvalue expression. When instance property access statements are identified in cross-procedural control flow statements, the corresponding heap object is determined based on the pointer set of the instance object, and the propagation relationship between the instance property pointer and the target pointer of the corresponding heap object is established. When static property access statements are identified in cross-procedural control flow statements, the propagation relationship between the static property pointer and the target pointer is established. When method call statements are identified in cross-procedural control flow statements, the pointer set of the method parameter pointers at the call point is propagated to the method parameter pointer of the called method, and the pointer set of the return value pointer of the called method is propagated to the receiving pointer at the call point to construct cross-procedural pointer relationships. Construct a pointer relationship graph based on the pointer propagation relationship between different pointers. , , This represents a set of nodes consisting of pointers. This represents the set of propagation edges generated by the data stream propagation rules; Based on the pointer relationship graph and the pointer set of each pointer, a complete data flow graph is generated.

[0013] Optionally, the step of performing taint analysis based on the data flow graph, identifying taint sources and tracing taint propagation paths, and determining whether tainted objects reach the convergence point to identify vulnerable interfaces includes: For all nodes and propagation edges in the data flow graph, data access objects related to external inputs are identified as taint sources, and heap objects in the set pointed to by the pointers corresponding to the taint sources are marked as taint objects. In the data flow graph, tainted objects are traced for taint propagation. Based on preset taint propagation rules, cross-node updates are performed on all assignment relationships, object attribute access relationships, and method call relationships. Here, it is assumed that the tainted object is... pointers The collection being pointed to contains tainted objects, and there are... Pointing to the pointers The propagation edge will then The tainted object in the pointer collection is propagated to In the method call relationship, the tainted objects in the collection pointed to by the method parameter pointers at the calling point are propagated to the method parameter pointers of the called method, and the tainted objects in the collection pointed to by the return value pointers of the called method are propagated to the receiving pointer at the calling point. Set a convergence point in the data flow graph. The convergence point includes the nodes corresponding to the methods used to perform sensitive operations and their parameters. Determine whether the tainted object has propagated to the convergence point, that is, determine whether the set pointed to by the method parameter pointers of the convergence point contains the tainted object. If the tainted object has propagated to the convergence point, then based on the tainted object's pollution propagation path, determine the interface corresponding to the reachability relationship from the tainted source to the convergence point as the vulnerable interface.

[0014] Optionally, the step of automatically extracting interface route signatures during taint analysis and generating route signature information that includes at least the interface route, request method, parameter set, and parameter constraints includes: During taint analysis, route declaration information associated with the interface is identified, and the service path, parent route, and child route of the interface are extracted based on the route declaration information. The service path, parent route, and child route are combined to generate the interface route path. ; Identify the request method corresponding to the interface and generate the request type. ; Generate a unique route identifier for the interface. , ;in, This is a unique identifier for the interface route; Extract the request media type corresponding to the interface. and parameter set Generate routing information representation , ; right Provide a structured description. , Indicates the parameter name. This indicates the position of the parameter in the request method. Represents a collection of parameter types. Represents the set of parameter constraints; according to and Generate interface route signature , and will It associates with vulnerable interfaces identified by taint analysis, providing interface routes, request methods, parameter sets, and parameter constraints for interface security testing.

[0015] Optionally, interfaces are grouped based on their parent routes, and interface security testing is performed using route signature information. Reinforcement learning methods are introduced to dynamically optimize the testing strategy during the interface security testing process. Simultaneously, parameter mutation and attack payload injection are performed on vulnerable interfaces, including: Extract the corresponding parent route based on the interface routing path in the routing signature information, and group interfaces with the same parent route into the same interface group; For each interface group, a test context set is constructed. The test context set shall contain at least the interface's historical request data, historical response data, and parameter candidate data generated based on the parameter constraint set in the route signature information. The request method, interface route, and parameter set of the interface to be tested are determined based on the route signature information, and test cases are generated in combination with the corresponding test context set. The interface security testing process is abstracted as a reinforcement learning process, and the interface test state is represented as a state variable. , It should include at least the interface grouping information, the interface to be tested information, the parameter combination information, and the historical test feedback information; The test action is represented as , It includes at least one or more of the following: interface access order selection, parameter combination selection, and attack payload selection; according to Perform interface security tests and obtain test feedback results, then calculate the reward value based on the test feedback results. , Related to the triggering conditions of fragile interfaces; based on Update the testing strategy and dynamically adjust the interface testing order and parameter combination priority according to the updated testing strategy, and reduce the test weight of interfaces and parameter combinations that have been successfully accessed. For vulnerable interfaces, the set of parameters to be mutated is determined based on their routing signature information and parameter constraint set, and parameter mutation processing is performed on the parameters to be mutated to obtain mutated test cases; wherein, parameter mutation processing includes at least one of boundary value mutation, type mutation, format mutation, length mutation and constraint violation mutation. The attack payload matching the convergence point is injected into the mutated test cases to generate security test cases, and security verification tests are performed on the vulnerable interfaces based on the security test cases.

[0016] Optionally, a security monitoring strategy can be set up using dynamic instrumentation to insert monitoring probes into the target Java application. When a monitoring probe is triggered, the interface security risk is determined based on recorded logs and test cases, including: Dynamic instrumentation is performed on the target Java application to insert monitoring probes into the interface call path and key data processing nodes without modifying the business logic. The monitoring probe is used to monitor the input data, method call behavior and execution results in the interface request process in real time, and the monitoring results are recorded in the form of logs. The log data is associated and matched with the test cases generated during the interface security testing process to form a correspondence between test behaviors and runtime behaviors; When the monitoring probe is triggered, a security risk assessment is performed on the interface execution path based on the trigger location, trigger type, and corresponding test case. If the monitoring result matches the preset security risk characteristics, it is determined that the current interface has a security risk, and the corresponding risk judgment result is output. The risk judgment result includes at least the vulnerable interface identifier, risk type, and corresponding contamination propagation path.

[0017] This application proposes a static analysis-based security testing method for Java RESTful interfaces, which achieves the following improvements compared to traditional interface testing methods.

[0018] First, it eliminates the reliance on API documentation, enabling the automated construction of prior test knowledge. This application synchronously performs automated extraction of route signatures during the static analysis phase. This design completely solves the problem in traditional RESTful API testing where incomplete, outdated, or poorly defined OpenAPI documentation prevents the generation of effective test cases. This application recreates the actual API topology through underlying code, providing a scientific, complete, and accurate data foundation for subsequent automated testing, ensuring high test case coverage.

[0019] Secondly, it breaks through the limitations of traditional coverage-oriented approaches, significantly improving the accuracy of vulnerability detection. Traditional robustness testing blindly pursues code coverage, making it difficult to provide effective guidance for security testing. This application takes interface vulnerability as its core focus, using Jimple intermediate representation to perform pointer modeling and cross-process data flow analysis on various statements. Through rigorous pollution propagation tracing, it accurately determines the entire chain process from the taint source to the convergence point, thereby identifying high-risk vulnerable interfaces in advance and greatly reducing the scope of ineffective testing.

[0020] Third, reinforcement learning is introduced to optimize testing strategies, significantly improving the efficiency and depth of testing. Addressing the shortcomings of traditional security testing, such as strong randomness, disorder, and difficulty in handling multi-parameter dependencies, this application introduces reinforcement learning and a dynamic priority scheduling mechanism. This scientifically and adaptively adjusts the interface call order and parameter combination strategy, automatically tilting computing resources towards high-risk, underexplored dependency paths, thus avoiding wasting computing power on security interfaces.

[0021] Fourth, a dynamic and static integrated monitoring system has been constructed to effectively eliminate false positives for security risks. Existing interface testing often relies on a single HTTP status code as the basis for judgment, which cannot accurately reflect substantial security vulnerabilities. This application uses dynamic instrumentation technology to deploy monitoring probes, capturing runtime context in real time without changing business logic. It quantifies and matches runtime trigger locations, exception types, and input attack payload characteristics, and strongly correlates them with statically generated security test cases. This accurately filters execution errors caused by ordinary code defects, outputs conclusive security vulnerability determinations and complete pollution propagation paths, significantly reducing the false positive rate. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies of this application will be briefly introduced below. The following drawings 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. The drawings described herein are only used to explain this application and are not intended to limit this application.

[0023] Figure 1 This is a flowchart of a Java Restful interface security testing method based on static analysis provided in one embodiment of this application; Figure 2 This is a schematic diagram illustrating the details of a static analysis-based security testing method for Java Restful interfaces provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of a Java Restful interface security testing system based on static analysis provided in another embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. Those skilled in the art will understand that many technical details have been provided in the embodiments of this application to facilitate better understanding. However, the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments. The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of this application. The following embodiments can be combined with and referenced by each other without contradiction.

[0025] One embodiment of this application proposes a static analysis-based security testing method for Java RESTful interfaces, applicable to RESTful interfaces of Java applications. The implementation details of the static analysis-based security testing method for Java RESTful interfaces proposed in this embodiment are described below. The following implementation details are provided for ease of understanding and are not necessary for implementing this solution.

[0026] The specific process of the Java RESTful interface security testing method based on static analysis proposed in this embodiment can be described as follows: Figure 1 As shown, its visual details can be as follows Figure 2 As shown, the method includes: Step 11: Use the Soot tool to generate a Jimple intermediate representation of the source code of the target Java application, and model all types of statements into a unified structure of multiple statements and expressions.

[0027] Specifically, traditional interface testing often uses coverage as a guide to mutate test cases. However, coverage cannot actually guide security testing, and security testing tends to be randomized and unordered, resulting in low efficiency due to its lack of specificity. This embodiment chooses to abstract the program code into a Jimpile intermediate representation and design processing rules for related statements. Based on these rules, an object-oriented analysis algorithm is designed to handle data flow issues. Based on the data flow analysis, taint analysis is performed on the interface to identify vulnerable interfaces. In other words, obtaining the Jimpile intermediate representation is fundamental to interface security testing. This embodiment uses the Soot tool to generate a Jimpile intermediate representation of the target Java application's source code, unifying the modeling of various statement types into a combination structure of multiple statements and expressions.

[0028] In one example, we use the Soot tool to load the source code of the target Java application and perform intermediate transformation to generate the corresponding Jimpile intermediate representation. Then, we identify the statement types in the Jimpile intermediate representation, including basic operation statements, assignment statements, branching statements, cross-procedural control flow statements, monitor statements, and exception handling statements. Different types of statements require different processing. To simplify the analysis process, we discard branching statements, monitor statements, and exception handling statements, refine the basic operation statements and assignment statements, and model the refined basic operation statements, refined assignment statements, and cross-procedural control flow statements as a unified combination structure of various statements and expressions. The expression is the core part of the combination structure. Expressions in the combination structure represent the data access objects, data assignment objects, and method call objects in the corresponding statements. Expressions are divided into lvalue expressions and rvalue expressions. Lvalue expressions represent the data carrier objects that are assigned or referenced, and rvalue expressions represent the data source objects that propagate data to the lvalue expressions.

[0029] Step 12: Using the interface as the analysis entry point, perform data flow analysis based on object pointer analysis on the Jimple intermediate representation, construct a pointer relationship graph, and then generate a complete data flow graph.

[0030] Specifically, after obtaining the Jimple intermediate representation corresponding to the target Java application, the interface can be used as the analysis entry point to perform data flow analysis based on object pointer analysis on the Jimple intermediate representation, construct a pointer relationship graph, and then generate a complete data flow graph.

[0031] In one example, we use the interface as the analysis entry point, traversing the Jimpile intermediate representation. Based on the composite structure in the Jimpile intermediate representation, we extract the interface and the data access objects in the interface's call chain, abstracting these data access objects as pointers. Pointer types include, but are not limited to, local variable pointers, static property pointers, instance property pointers, method parameter pointers, return value pointers, and receiver pointers. Subsequently, we create a pointer set for each pointer, recording the heap objects that the pointer can point to. The set pointed to by each pointer is denoted as . , , This represents a heap object. Next, based on the statement types in the Jimpile intermediate representation, the corresponding data flow propagation rules are determined, and the set of pointers and the propagation relationships between different pointers are updated based on these rules. Finally, a pointer relationship graph is constructed based on the propagation relationships between different pointers. , , This represents a set of nodes consisting of pointers. This represents the set of propagation edges generated by the data flow propagation rules. Based on the pointer relationship graph and the set of pointers, a complete data flow graph can be generated.

[0032] It is understandable that the pointing relationship between pointers reflects the flow of heap objects between different variables. By analyzing the propagation of heap objects between pointers, an effective analysis of the data flow relationship across processes can be achieved.

[0033] In one example, upon identifying object creation statements and constructor calls within basic operation statements, a new heap object is created, and this new heap object is added to the set of pointers that receive its creation result. Upon identifying an assignment statement, the set of pointers corresponding to its rvalue expression is propagated to the set of pointers corresponding to its lvalue expression. Upon identifying instance property access statements within cross-procedural control flow statements, the corresponding heap object is determined based on the set of pointers to the instance object, and a pointer propagation relationship is established between the instance property pointers of the corresponding heap object and the target pointer. Upon identifying static property access statements within cross-procedural control flow statements, a pointer propagation relationship is established between the static property pointers and the target pointer. Upon identifying method call statements within cross-procedural control flow statements, the set of pointers to the method parameters at the call point is propagated to the method parameter pointers of the called method, and the set of pointers to the return value of the called method is propagated to the receiving pointer at the call point, thus constructing cross-procedural pointer relationships.

[0034] Step 13: Based on the data flow graph, perform taint analysis to identify taint sources and trace the taint propagation path, determine whether the tainted object has reached the convergence point, and thus identify vulnerable interfaces.

[0035] Specifically, after obtaining the data flow graph, taint analysis can be performed on the data flow graph to identify taint sources and trace the path of taint propagation, determine whether tainted objects have reached the convergence point, and thus identify vulnerable interfaces.

[0036] Taint analysis comprises three parts. First, the taint source: taint source identification is automatic. When an interface method is detected, a corresponding pointer is automatically created for its parameters, and a heap object is added to the set pointed to by that pointer, marked as a tainted object. This serves as the starting point for data flow tracing. Second, taint propagation (Transfers): during data flow analysis, if a statement conforms to taint propagation rules, the pointer relationships are updated according to predefined propagation rules, realizing the transfer and propagation of tainted objects between pointers. Third, sinks: when the analysis path reaches a method and its parameters defined by sink rules, it is determined whether the pointer set corresponding to that method's parameters contains tainted objects. If it does, it indicates a potential security risk on that path.

[0037] In one example, please refer to Figure 2 For all nodes and propagation edges in the data flow graph, data access objects related to external input are identified as taint sources, and heap objects in the set pointed to by the pointers corresponding to the taint sources are marked as tainted objects. Subsequently, we perform taint propagation tracing on the tainted objects in the data flow graph. Based on preset taint propagation rules, we perform cross-node propagation updates on all assignment relationships, object attribute access relationships, and method call relationships. It's important to note that in method call relationships, tainted objects in the set pointed to by the method parameter pointers at the calling point are propagated to the method parameter pointers of the called method, and tainted objects in the set pointed to by the return value pointers of the called method are propagated to the receiving pointer at the calling point. A sink point is set in the data flow graph, which includes the nodes corresponding to the methods used to perform sensitive operations and their parameters. During taint propagation tracing, we determine whether a tainted object has propagated to the sink point, i.e., whether the set pointed to by the method parameter pointers of the sink point contains a tainted object. If a tainted object has propagated to the sink point, the interface corresponding to the reachability relationship from the taint source to the sink point is identified as a vulnerable interface based on the taint propagation path of the tainted object. If the tainted object does not propagate to the sink, the interface corresponding to the reachability relationship from the tainted source to the sink can be determined as a normal interface.

[0038] In one example, suppose the first pointers The collection being pointed to contains tainted objects, and there are... Pointing to the pointers The propagation edge will then The tainted object in the pointer collection is propagated to The set it points to.

[0039] In one example, for the first in the data flow graph The node (i.e., the node) pointers The state update of the collection of tainted objects follows the following propagation equation: ; in, express Precursor nodes propagate to A collection of tainted objects, express The collection of tainted objects that propagate to its subsequent nodes. express A collection of tainted objects generated as a taint source. express A collection of tainted objects that have been blocked by data cleaning or filtering operations.

[0040] Step 14: Automatically extract interface route signatures during taint analysis and generate route signature information that includes at least the interface route, request method, parameter set, and parameter constraints.

[0041] Specifically, traditional API testing methods often rely on OpenAPI documentation or web scraping. However, incomplete or missing documentation can occur during testing, and web scraping methods cannot fully cover all API information. This incompleteness makes it difficult to generate effective test cases and also hinders the analysis of dependencies between APIs. Therefore, during taint analysis, we automatically extract API route signatures, generating route signature information that includes at least the API route, request method, parameter set, and parameter constraints. This effectively ensures high test case coverage.

[0042] In one example, please refer to Figure 2 During taint analysis, we need to identify the routing declaration information associated with the interface, and extract the service path, parent route, and child route of the interface based on the routing declaration information. We then combine the service path, parent route, and child route to generate the interface routing path. .

[0043] Next, identify the request method corresponding to the interface and generate the request type. .

[0044] Subsequently, a unique route identifier is generated for the interface. , .in, This is a number used to uniquely identify the interface route.

[0045] Next, extract the request media type corresponding to the interface. and parameter set Generate routing information representation , .right To provide a structured description, Represented as .in, Indicates the parameter name. This indicates the position of the parameter in the request method. Represents a collection of parameter types. Represents the set of parameter constraints.

[0046] Finally, according to and Generate interface route signature , and will It associates with vulnerable interfaces identified by taint analysis, providing interface routes, request methods, parameter sets, and parameter constraints for interface security testing.

[0047] Step 15: Group the interfaces based on the parent routes of the interfaces, and perform interface security testing in combination with route signature information. During the interface security testing process, reinforcement learning methods are introduced to dynamically optimize the testing strategy. At the same time, parameter mutation and attack payload injection of test cases are performed on vulnerable interfaces.

[0048] Specifically, after generating route signature information, interfaces can be grouped based on their parent routes, and interface security testing can be performed in conjunction with the route signature information. Reinforcement learning methods are introduced during interface security testing to dynamically optimize testing strategies. Simultaneously, parameter mutation and attack payload injection are performed on vulnerable interfaces to automatically allocate computing resources to high-risk, underexplored dependency paths, avoiding wasting computing power on secure interfaces.

[0049] In one example, please refer to Figure 2 After generating route signature information, the corresponding parent routes are extracted based on the interface route paths in the route signature information. Interfaces with the same parent routes are grouped into the same interface group. For each interface group, a test context set is constructed. The test context set contains at least the interface's historical request data, historical response data, and parameter candidate data generated based on the parameter constraint set in the route signature information. Subsequently, the request method, interface route, and parameter set of the interface to be tested are determined based on the route signature information, and test cases are generated in conjunction with the corresponding test context set. Finally, the interface security testing process is abstracted as a reinforcement learning process, and the interface test state is represented as a state variable. ( The test action should include at least the interface grouping information, the interface to be tested information, the parameter combination information, and the historical test feedback information. ( (This includes at least one or more of the following: interface access order selection, parameter combination selection, and attack payload selection). Perform interface security tests and obtain test feedback results, then calculate the reward value based on the test feedback results. ( (Related to the triggering conditions of fragile interfaces), based on Update the testing strategy and dynamically adjust the interface testing order and parameter combination priority according to the updated testing strategy, reducing the test weight of interfaces and parameter combinations that have been successfully accessed.

[0050] In one example, for a vulnerable interface, the set of parameters to be mutated is determined based on its routing signature information and parameter constraint set. Parameter mutation processing is then performed on these parameters to obtain mutated test cases. An attack payload matching the rendezvous point is injected into these mutated test cases to generate security test cases. Security verification tests are then performed on the vulnerable interface based on these security test cases. The parameter mutation processing includes at least one of the following: boundary value mutation, type mutation, format mutation, length mutation, and constraint violation mutation.

[0051] In one example, the reward value It is calculated using the following formula: ; in, Indicate execution The number of newly added vulnerable interfaces or risks triggered. This indicates the number of newly added untested interfaces or parameter combinations. This indicates the penalty for accessing a successfully tested interface, i.e., test redundancy. for The corresponding weighting coefficients, for The corresponding weighting coefficients, for The corresponding weighting coefficients, .

[0052] In one example, the interface test order and parameter combination priority are dynamically adjusted according to the updated test strategy. Specifically, the interface to be tested is adjusted using the following formula (the first...). Interface Dynamic priority weights : ; in, for The number of times the system has successfully accessed and returned the expected response in historical tests. The preset attenuation coefficient, Based on contamination analysis Vulnerability score (determined based on the number of contamination propagation paths reaching the convergence point). and All are preset balance factors. .

[0053] In one example, for a typical API security testing scenario, , For penetration testing scenarios involving interfaces, , For routine online version regression testing and API stability testing scenarios, , .

[0054] Step 16: Set up a security monitoring strategy by dynamically instrumenting the system and insert monitoring probes into the target Java application. When the monitoring probes are triggered, determine the interface security risks based on the recorded logs and test cases.

[0055] Specifically, traditional interface testing uses 5xx response codes as test monitoring. However, for security testing, 5xx responses have limited practical value; this response only indicates a server execution error and does not suggest a security risk. This embodiment sets up a security monitoring strategy through dynamic instrumentation, inserting monitoring probes into the target Java application. When a monitoring probe is triggered, the interface security risk is determined based on recorded logs and test cases.

[0056] In one example, please refer to Figure 2 This embodiment performs dynamic instrumentation on the target Java application. Without modifying the business logic, monitoring probes are inserted into the interface call path and key data processing nodes. These probes monitor the input data, method call behavior, and execution results during the interface request process in real time, and record the monitoring results in log form. This embodiment correlates and matches the log data with test cases generated during interface security testing, establishing a correspondence between test behavior and runtime behavior. When a monitoring probe is triggered, a security risk assessment is performed on the interface execution path based on the trigger location, trigger type, and corresponding test case. If the monitoring result matches preset security risk characteristics, it is determined that the current interface has a security risk, and the corresponding risk assessment result is output. The risk assessment result includes at least a vulnerable interface identifier, risk type, and corresponding contamination propagation path.

[0057] In one example, the monitoring probe needs to be used in conjunction with a risk confidence mechanism to reduce the probability of false alarms. When the risk confidence is greater than a preset risk threshold, it is determined that there is a security risk in the current interface.

[0058] In one example, risk confidence level It is calculated using the following formula: ; in, , , These represent the similarity between the trigger location, trigger type, and attack payload in the input test case and the preset security risk feature matrix, respectively. , , This represents the corresponding decision weight.

[0059] This embodiment proposes a static analysis-based security testing method for Java RESTful interfaces, which achieves the following improvements compared to traditional interface testing methods.

[0060] First, it eliminates the reliance on API documentation, enabling the automated construction of prior test knowledge. This embodiment synchronously performs automated extraction of route signatures during the static analysis phase. This design completely solves the problem in traditional RESTful API testing where missing, outdated, or incomplete OpenAPI documentation prevents the generation of effective test cases. This embodiment recreates the actual API topology through underlying code, providing a scientific, complete, and accurate data foundation for subsequent automated testing, ensuring high test case coverage.

[0061] Secondly, it breaks through the limitations of traditional coverage-oriented approaches, significantly improving the accuracy of vulnerability detection. Traditional robustness testing blindly pursues code coverage, making it difficult to provide effective guidance for security testing. This embodiment takes interface vulnerability as its core focus, using Jimple intermediate representation to perform pointer modeling and cross-process data flow analysis on various statements. Through rigorous pollution propagation tracing, it accurately determines the entire link process from the taint source to the convergence point, thereby identifying high-risk vulnerable interfaces in advance and greatly reducing the scope of ineffective testing.

[0062] Third, reinforcement learning is introduced to optimize testing strategies, significantly improving the efficiency and depth of testing. Addressing the shortcomings of traditional security testing, such as strong randomness, disorder, and difficulty in handling multi-parameter dependencies, this embodiment introduces reinforcement learning and a dynamic priority scheduling mechanism. This scientifically and adaptively adjusts the interface call order and parameter combination strategy, automatically tilting computing resources towards high-risk, underexplored dependency paths, thus avoiding wasting computing power on security interfaces.

[0063] Fourth, a dynamic and static integrated monitoring system was constructed to effectively eliminate false alarms regarding security risks. Existing interface testing often relies on a single HTTP status code as the basis for judgment, which cannot accurately reflect substantial security vulnerabilities. This embodiment uses dynamic instrumentation technology to deploy monitoring probes, capturing runtime context in real time without changing business logic. It quantifies and matches runtime trigger locations, exception types, and input attack payload characteristics, and strongly correlates them with statically generated security test cases. This accurately filters execution errors caused by ordinary code defects, outputs conclusive security vulnerability determinations and complete pollution propagation paths, significantly reducing the false alarm rate.

[0064] The steps described above are merely for clarity in describing the technical solution. In actual implementation, they can be combined into one step, or certain steps can be broken down into multiple steps, as long as they involve the same logical relationship, they are all within the scope of protection of this application. Any insignificant modifications or designs added to the algorithm or process, as long as they do not change the core of the algorithm or process, are also within the scope of protection of this application.

[0065] Accordingly, another embodiment of this application proposes a Java RESTful interface security testing system based on static analysis, applicable to RESTful interfaces of Java applications, to implement a Java RESTful interface security testing method based on static analysis as described in the above method embodiments. The details of the Java RESTful interface security testing system based on static analysis proposed in this embodiment are described below. The following implementation details are provided for ease of understanding and are not essential for implementing this solution.

[0066] Figure 3 This is a schematic diagram of the structure of a Java Restful interface security testing system based on static analysis proposed in this embodiment, including: an intermediate representation generation module 21, a data flow analysis module 22, a taint analysis module 23, a route signature extraction module 24, an interface security testing module 25, and a probe monitoring module 26.

[0067] The intermediate representation generation module 21 is used to generate the Jimple intermediate representation of the source code of the target Java application using the Soot tool, and to uniformly model various types of statements into a combination structure of multiple statements and expressions.

[0068] The data flow analysis module 22 is used to perform data flow analysis based on object pointing to the Jimple intermediate representation, using the interface as the analysis entry point, to construct a pointer relationship graph and generate a complete data flow graph.

[0069] The taint analysis module 23 is used to perform taint analysis based on the data flow graph, identify taint sources and trace the taint propagation path, determine whether the tainted object has reached the convergence point, and thus identify vulnerable interfaces.

[0070] The route signature extraction module 24 is used to automatically extract interface route signatures during taint analysis and generate route signature information that includes at least the interface route, request method, parameter set, and parameter constraints.

[0071] The interface security testing module 25 is used to group interfaces based on their parent routes and perform interface security testing in conjunction with route signature information. During the interface security testing process, reinforcement learning methods are introduced to dynamically optimize the testing strategy, while parameter mutation and attack payload injection of test cases are performed on vulnerable interfaces.

[0072] The probe monitoring module 26 is used to set up security monitoring strategies through dynamic instrumentation, insert monitoring probes into the target Java application, and determine the interface security risks based on the recorded logs and test cases when the monitoring probes are triggered.

[0073] It is worth noting that all modules involved in this embodiment are logical modules. In practical applications, a logical module can be a physical module, a part of a physical module, or an organic combination of multiple physical modules. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce modules that are not closely related to solving the technical problems proposed in this application. However, this does not mean that other modules are absent from this embodiment.

[0074] It is not difficult to see that this embodiment is a system embodiment corresponding to the above method embodiments, and this embodiment can be implemented in conjunction with the above method embodiments. The relevant technical details and technical effects mentioned in the above method embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above method embodiments.

[0075] Another embodiment of this application provides an electronic device, such as Figure 4 As shown, it includes a processor 31 and a memory 32. The memory 32 stores instructions that the processor 31 can execute. When the processor 31 is configured to execute the instructions, the electronic device can implement a static analysis-based Java RESTful interface security testing method as described in the above method embodiment.

[0076] The memory and processor are connected via a bus, which includes any number of interconnecting buses and bridges. The bus connects various circuits of one or more processors and the memory. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which also receives and transmits data back to the processor. The processor manages the bus and general processing, and can also provide various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. The memory can be used to store data used by the processor during operation.

[0077] Another embodiment of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, can implement a static analysis-based Java RESTful interface security testing method as described in the above method embodiments.

[0078] That is, those skilled in the art will understand that all or part of the steps in the above method embodiments can be implemented by a program instructing related hardware. The program is stored in a storage medium and includes several instructions to cause a device (such as a microcontroller, chip, etc.) or processor to execute all or part of the steps of the method described in the method embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0079] It will be understood by those skilled in the art that the above embodiments are specific implementations of this application, and in practical applications, various changes can be made in form, detail, and description without departing from the spirit and scope of this application. For those skilled in the art, several improvements and modifications can be made without departing from the principles of this application, and these improvements and modifications are also considered to be within the scope of protection of this application.

Claims

1. A static analysis-based security testing method for Java RESTful interfaces, applicable to RESTful interfaces in Java applications, characterized in that... The method includes: The Soot tool is used to generate a Jimple intermediate representation of the source code of the target Java application, and various types of statements are uniformly modeled as a combination structure of multiple statements and expressions. Using the interface as the analysis entry point, data flow analysis based on object pointer analysis is performed on the Jimple intermediate representation to construct a pointer relationship graph and generate a complete data flow graph. Based on the data flow graph, taint analysis is performed to identify taint sources and trace the path of taint propagation, and to determine whether tainted objects have reached the convergence point, thereby identifying vulnerable interfaces. During taint analysis, the interface route signature is automatically extracted to generate route signature information that includes at least the interface route, request method, parameter set, and parameter constraints. The parent route based on the interface groups the interfaces, and performs interface security testing in combination with the route signature information. During the interface security testing process, reinforcement learning methods are introduced to dynamically optimize the test strategy. At the same time, parameter mutation and attack payload injection of test cases are performed on vulnerable interfaces. Security monitoring strategies are set up by dynamically instrumenting probes into the target Java application. When the probes are triggered, the interface security risks are determined based on the logs and test cases.

2. The Java RESTful interface security testing method based on static analysis according to claim 1, characterized in that, The method of generating a Jimple intermediate representation of the target Java application's source code using the Soot tool unifies the modeling of various statement types into a combination structure of multiple statements and expressions, including: The source code of the target Java application is loaded using the Soot tool, and intermediate transformations are performed to generate the Jimple intermediate representation corresponding to the target Java application. Identify the statement types in the Jimple intermediate representation, including basic operation statements, assignment statements, branching statements, cross-procedural control flow statements, monitor statements, and exception handling statements; Branch statements, monitor statements, and exception handling statements are discarded. Basic operation statements and assignment statements are refined. The refined basic operation statements, refined assignment statements, and cross-process control flow statements are then modeled into a unified structure of multiple statements and expressions. In the composite structure, the expression is used to represent the data access object, data assignment object, and method call object in the corresponding statement. The expression is divided into lvalue expression and rvalue expression. The lvalue expression is used to represent the data carrier object that is assigned or referenced, and the rvalue expression is used to represent the data source object that propagates data to the lvalue expression.

3. The Java RESTful interface security testing method based on static analysis according to claim 1, characterized in that, The method uses the interface as the analysis entry point to perform data flow analysis based on object pointer analysis on the Jimple intermediate representation, constructs a pointer relationship graph, and then generates a complete data flow graph, including: Using the interface as the analysis entry point, we traverse the Jimple intermediate representation and extract the interface and the data access object in the interface call chain based on the composite structure in the Jimple intermediate representation. Data access objects are abstracted into pointers, and pointer types include at least local variable pointers, static property pointers, instance property pointers, method parameter pointers, return value pointers, and receiver pointers; Create a pointer set for each pointer, and record the heap objects that the pointers can point to; where, the first... The set pointed to by each pointer is denoted as . , , Represents a heap object; Based on the statement types in the Jimple intermediate representation, the corresponding data flow propagation rules are determined, and the pointer set and the propagation relationship between different pointers are updated based on the data flow propagation rules. Specifically, when object creation statements and constructor call statements are identified in basic operation statements, a new heap object is created, and the newly created heap object is added to the pointer set that receives its creation result. When an assignment statement is identified, the pointer set corresponding to its rvalue expression is propagated to the pointer set corresponding to its lvalue expression. When an instance property access statement is identified in a cross-procedural control flow statement, the corresponding heap object is determined based on the pointer set of the instance object, and the propagation relationship between the instance property pointer and the target pointer of the corresponding heap object is established. When a static property access statement is identified in a cross-procedural control flow statement, the propagation relationship between the static property pointer and the target pointer is established. When a method call statement is identified in a cross-procedural control flow statement, the pointer set of the method parameter pointers at the call point is propagated to the method parameter pointer of the called method, and the pointer set of the return value pointer of the called method is propagated to the receiving pointer at the call point to construct cross-procedural pointer relationships. Construct a pointer relationship graph based on the pointer propagation relationship between different pointers. , , This represents a set of nodes consisting of pointers. This represents the set of propagation edges generated by the data stream propagation rules; Based on the pointer relationship graph and the pointer set of each pointer, a complete data flow graph is generated.

4. The Java RESTful interface security testing method based on static analysis according to claim 3, characterized in that, Based on the data flow graph, taint analysis is performed to identify taint sources and trace the taint propagation path, determining whether tainted objects reach the convergence point, thereby identifying vulnerable interfaces, including: For all nodes and propagation edges in the data flow graph, data access objects related to external inputs are identified as taint sources, and heap objects in the set pointed to by the pointers corresponding to the taint sources are marked as taint objects. In the data flow graph, tainted objects are traced for taint propagation. Based on preset taint propagation rules, cross-node updates are performed on all assignment relationships, object attribute access relationships, and method call relationships. Here, it is assumed that the tainted object is... pointers The collection being pointed to contains tainted objects, and there are... Pointing to the pointers The propagation edge will then The tainted object in the pointer collection is propagated to In the method call relationship, the tainted objects in the collection pointed to by the method parameter pointers at the calling point are propagated to the method parameter pointers of the called method, and the tainted objects in the collection pointed to by the return value pointers of the called method are propagated to the receiving pointer at the calling point. Set a convergence point in the data flow graph. The convergence point includes the nodes corresponding to the methods used to perform sensitive operations and their parameters. Determine whether the tainted object has propagated to the convergence point, that is, determine whether the set pointed to by the method parameter pointers of the convergence point contains the tainted object. If the tainted object has propagated to the convergence point, then based on the tainted object's pollution propagation path, determine the interface corresponding to the reachability relationship from the tainted source to the convergence point as the vulnerable interface.

5. A Java RESTful interface security testing method based on static analysis according to claim 4, characterized in that, The process of automatically extracting interface route signatures during taint analysis generates route signature information that includes at least the interface route, request method, parameter set, and parameter constraints, including: During taint analysis, route declaration information associated with the interface is identified, and the service path, parent route, and child route of the interface are extracted based on the route declaration information. The service path, parent route, and child route are combined to generate the interface route path. ; Identify the request method corresponding to the interface and generate the request type. ; Generate a unique route identifier for the interface. , ;in, This is a unique identifier for the interface route; Extract the request media type corresponding to the interface. and parameter set Generate routing information representation , ; right Provide a structured description. , Indicates the parameter name. This indicates the position of the parameter in the request method. Represents a collection of parameter types. Represents the set of parameter constraints; according to and Generate interface route signature , and will It associates with vulnerable interfaces identified by taint analysis, providing interface routes, request methods, parameter sets, and parameter constraints for interface security testing.

6. A Java RESTful interface security testing method based on static analysis according to claim 5, characterized in that, Interfaces are grouped based on their parent routes, and interface security testing is performed using route signature information. Reinforcement learning methods are introduced to dynamically optimize the testing strategy during the interface security testing process. Simultaneously, parameter mutation and attack payload injection are performed on vulnerable interfaces, including: Extract the corresponding parent route based on the interface routing path in the routing signature information, and group interfaces with the same parent route into the same interface group; For each interface group, a test context set is constructed. The test context set shall contain at least the interface's historical request data, historical response data, and parameter candidate data generated based on the parameter constraint set in the route signature information. The request method, interface route, and parameter set of the interface to be tested are determined based on the route signature information, and test cases are generated in combination with the corresponding test context set. The interface security testing process is abstracted as a reinforcement learning process, and the interface test state is represented as a state variable. , It should include at least the interface grouping information, the interface to be tested information, the parameter combination information, and the historical test feedback information; The test action is represented as , It includes at least one or more of the following: interface access order selection, parameter combination selection, and attack payload selection; according to Perform interface security tests and obtain test feedback results, then calculate the reward value based on the test feedback results. , Related to the triggering conditions of fragile interfaces; based on Update the testing strategy and dynamically adjust the interface testing order and parameter combination priority according to the updated testing strategy, and reduce the test weight of interfaces and parameter combinations that have been successfully accessed. For vulnerable interfaces, the set of parameters to be mutated is determined based on their routing signature information and parameter constraint set, and parameter mutation processing is performed on the parameters to be mutated to obtain mutated test cases; wherein, parameter mutation processing includes at least one of boundary value mutation, type mutation, format mutation, length mutation and constraint violation mutation. The attack payload matching the convergence point is injected into the mutated test cases to generate security test cases, and security verification tests are performed on the vulnerable interfaces based on the security test cases.

7. A Java RESTful interface security testing method based on static analysis according to claim 6, characterized in that, Security monitoring strategies are configured through dynamic instrumentation, inserting monitoring probes into the target Java application. When a monitoring probe is triggered, interface security risks are assessed based on recorded logs and test cases, including: Dynamic instrumentation is performed on the target Java application to insert monitoring probes into the interface call path and key data processing nodes without modifying the business logic. The monitoring probe is used to monitor the input data, method call behavior and execution results in the interface request process in real time, and the monitoring results are recorded in the form of logs. The log data is associated and matched with the test cases generated during the interface security testing process to form a correspondence between test behaviors and runtime behaviors; When the monitoring probe is triggered, a security risk assessment is performed on the interface execution path based on the trigger location, trigger type, and corresponding test case. If the monitoring result matches the preset security risk characteristics, it is determined that the current interface has a security risk, and the corresponding risk judgment result is output. The risk judgment result includes at least the vulnerable interface identifier, risk type, and corresponding contamination propagation path.

8. A Java RESTful interface security testing system based on static analysis, applicable to RESTful interfaces of Java applications, to implement the Java RESTful interface security testing method based on static analysis as described in any one of claims 1 to 7, characterized in that, The system includes: The intermediate representation generation module is used to generate a Jimple intermediate representation of the source code of the target Java application using the Soot tool, and to uniformly model various types of statements into a combination structure of multiple statements and expressions. The data flow analysis module is used to perform object-oriented data flow analysis on the Jimple intermediate representation, using the interface as the analysis entry point, to build a graph of pointer relationships and generate a complete data flow graph. The taint analysis module is used to perform taint analysis based on the data flow graph, identify taint sources and trace the taint propagation path, determine whether tainted objects have reached the convergence point, and thus identify vulnerable interfaces. The route signature extraction module is used to automatically extract interface route signatures during taint analysis and generate route signature information that includes at least the interface route, request method, parameter set, and parameter constraints. The interface security testing module is used to group interfaces based on their parent routes and perform interface security testing in conjunction with route signature information. During the interface security testing process, reinforcement learning methods are introduced to dynamically optimize the testing strategy, while parameter mutation and attack payload injection of test cases are performed on vulnerable interfaces. The probe monitoring module is used to set up security monitoring strategies through dynamic instrumentation, insert monitoring probes into the target Java application, and determine the interface security risks based on the recorded logs and test cases when the monitoring probes are triggered.

9. An electronic device, characterized in that, include: The electronic device includes a processor and a memory, the memory storing instructions that the processor can execute, and the processor being configured to execute the instructions such that the electronic device can implement a static analysis-based Java RESTful interface security testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it can implement a Java Restful interface security testing method based on static analysis as described in any one of claims 1 to 7.

Images