An Interface Traversal Method and System Based on Multidimensional Traffic Analysis and Intelligent Fuzzy Testing

Abstract

This invention discloses an interface traversal method and system based on multi-dimensional traffic analysis and intelligent fuzz testing. The method includes: acquiring multi-source interface data of the software under test; preprocessing the multi-source interface data to obtain full initial interface data; performing intelligent fuzz testing on the full initial interface data to identify and supplement potential hidden interface data into the full initial interface data, obtaining full final interface data; visualizing the full final interface data and generating a software interface traversal test report. The method and system provided by this invention, through multi-dimensional interface data fusion and intelligent fuzz testing, achieve full interface discovery and precise control of interface security risks.

Description

Technical Field

[0001] This invention relates to the field of software testing interface technology, and in particular to an interface traversal method and system based on multidimensional traffic analysis and intelligent fuzz testing. Background Technology

[0002] With the continuous evolution of software architecture and the widespread adoption of technologies such as microservices and API gateways, the number of interfaces in modern software systems is surging, and the state of these interfaces is constantly changing. Interface testing has become a core component in ensuring software quality and operational security, directly impacting the stability, data security, and business continuity of the software system. However, current mainstream interface testing methods suffer from significant dependency defects, resulting in insufficient interface test coverage, leaving numerous security blind spots, and failing to meet the testing needs of modern software systems.

[0003] Currently, existing software interface testing technologies suffer from the following three significant shortcomings, making them difficult to adapt to testing scenarios of complex software systems. These are as follows:

[0004] First, there is a heavy reliance on manual documentation, leading to gaps in test coverage. Testers often rely heavily on the API documentation provided by the development team, using the information recorded in the documentation as the basis for testing. However, in actual development, API documentation is frequently neglected due to developer oversight, failure to update documentation promptly after API changes, or the presence of temporary debugging or management APIs not included in the documentation. This results in a large number of APIs not being tested. These uncovered APIs are highly susceptible to becoming sources of security vulnerabilities such as unauthorized access and data breaches. Especially in high-security sectors like healthcare and finance, such vulnerabilities can lead to serious privacy breaches, business disruptions, and irreparable losses.

[0005] Second, static analysis techniques have inherent limitations, resulting in incomplete interface discovery. Existing static code scanning techniques (such as extracting interfaces by analyzing code annotations) can only discover some interfaces explicitly defined in the software source code. They cannot identify interfaces dynamically generated at runtime, interfaces that are exposed only depending on specific configuration states, or interfaces introduced by third-party libraries or middleware. This leads to significant blind spots in interface discovery and makes it impossible to achieve full coverage of all interfaces in the software system.

[0006] Third, test cases have coverage blind spots, failing to discover newly added or hidden interfaces. Existing interface testing mostly adopts regression testing methods based on existing test cases. Its core purpose is to verify whether the known functions of the software system are normal. It cannot discover newly added interfaces that have never been covered by test cases, nor can it detect hidden interfaces that are not documented or discovered by static analysis, further exacerbating the problem of insufficient coverage in interface testing.

[0007] In summary, existing interface testing and discovery technologies are limited by their reliance on manual documentation and pre-set test cases, and fail to effectively integrate dynamic and static analysis technologies. They cannot achieve comprehensive and automated discovery of all interfaces of a software system, and are unable to solve the technical pain points of insufficient interface coverage and security blind spots. Summary of the Invention

[0008] In view of the above-mentioned shortcomings in the current field of software testing interface technology, this invention provides an interface traversal method based on multi-dimensional traffic analysis and intelligent fuzz testing. Through multi-dimensional interface data fusion and intelligent fuzz testing, it can achieve full-scale interface discovery and precise control of interface security risks.

[0009] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0010] An interface traversal method based on multidimensional traffic analysis and intelligent fuzz testing, the method comprising:

[0011] Acquire multi-source interface data of the software under test. The multi-source interface data includes dynamic interface datasets generated by dynamic traffic monitoring, static interface datasets generated by static code analysis, and configuration interface datasets generated by configuration file scanning. Each of the dynamic interface dataset, static interface dataset, and configuration interface dataset contains at least the interface access path and HTTP request method.

[0012] The multi-source interface data is fused and deduplicated to obtain the full initial interface data of the software under test.

[0013] Perform intelligent fuzz testing on the full initial interface data to identify and supplement potential hidden interface data into the full initial interface data, thereby obtaining the full final interface data.

[0014] The full set of final interface data is visualized, and a software interface traversal test report is generated.

[0015] According to one aspect of the present invention, the multi-source interface data includes a dynamic interface dataset generated by dynamic traffic monitoring, a static interface dataset generated by static code analysis, and a configuration interface dataset generated by configuration file scanning, wherein the dynamic interface dataset, the static interface dataset, and the configuration interface dataset all contain at least an interface access path and an HTTP request method.

[0016] According to one aspect of the present invention, the dynamic interface dataset generated by dynamic traffic monitoring specifically involves: deploying a traffic acquisition agent to capture the network traffic of the software under test; driving an automated test script to traverse the software under test; extracting the interface access path and HTTP request method; and organizing and generating the dynamic interface dataset.

[0017] According to one aspect of the present invention, the static interface dataset generated by static code analysis specifically involves: obtaining the target code file of the software under test; parsing the target code file based on abstract syntax tree technology; reconstructing the complete interface access path and associating it with the corresponding HTTP request method to generate a static interface dataset.

[0018] According to one aspect of the present invention, the configuration interface dataset generated by scanning the configuration file specifically involves: scanning the configuration file of the software under test, parsing the interface access paths and associated HTTP request methods in the configuration file, and generating the configuration interface dataset.

[0019] According to one aspect of the present invention, the preprocessing for fusing and deduplicating the multi-source interface data specifically involves: performing data fusing and deduplicating preprocessing based on the interface access path and request method.

[0020] According to one aspect of the present invention, the data fusion and deduplication preprocessing based on the interface access path and request method specifically comprises:

[0021] The interface access paths of each dataset in the multi-source interface data are normalized to obtain normalized interface access paths.

[0022] Using the normalized interface access path and HTTP request method as a composite unique key, the datasets in the multi-source interface data are merged and deduplicated to generate full initial interface data.

[0023] According to one aspect of the present invention, performing intelligent fuzz testing on the full initial interface data specifically includes:

[0024] Iterate through all the initial interface data and generate a test case set based on the parameter types of each interface;

[0025] The intelligent testing engine sends the test requests corresponding to the test case set to the software under test. All test requests are sent through a traffic collection proxy.

[0026] Monitor the system response of the software under test to all test requests, and collect system response data to identify potential hidden interfaces.

[0027] According to one aspect of the present invention, the collection of system response data to identify potential hidden interfaces specifically involves: filtering out interfaces from the system response data whose response status codes are neither 404 nor 405, and whose corresponding interface access paths and HTTP request method combinations are not included in the full set of initial interface data, as potential hidden interfaces.

[0028] According to one aspect of the present invention, the visualization of the full final interface data, data comparison and risk assessment, and generation of a software interface traversal test report specifically include:

[0029] Obtain data from the development and testing interface;

[0030] Visualize the full final interface data;

[0031] The full set of final interface data is compared with the development and testing interface data, and the interfaces that have not been tested are highlighted.

[0032] A risk assessment is performed on the full set of final interface data, and a software interface traversal test report is generated.

[0033] An interface traversal system based on multidimensional traffic analysis and intelligent fuzz testing, the system comprising:

[0034] The data acquisition module acquires multi-source interface data of the software under test. The multi-source interface data includes dynamic interface datasets generated by dynamic traffic monitoring, static interface datasets generated by static code analysis, and configuration interface datasets generated by configuration file scanning. Each of the dynamic interface datasets, static interface datasets, and configuration interface datasets contains at least the interface access path and the HTTP request method.

[0035] The data processing module performs fusion and deduplication preprocessing on the multi-source interface data to obtain the full initial interface data of the software under test.

[0036] The intelligent fuzz testing module performs intelligent fuzz testing on the full initial interface data, identifies and supplements potential hidden interface data into the full initial interface data, and obtains the full final interface data.

[0037] The results generation module visualizes the full set of final interface data and generates a software interface traversal test report.

[0038] The advantages of this invention are as follows: By collecting multi-source interface data through dynamic traffic monitoring, static code analysis, and configuration file scanning, combined with intelligent closed-loop detection through fuzz testing and real-time traffic monitoring, and coupled with intelligent comparison of untested interfaces and targeted risk assessment, it achieves synergistic complementarity in multi-dimensional interface discovery, breaking through the coverage limitations of single interface discovery methods. This solution completely eliminates the reliance on manual documentation and preset test cases, not only comprehensively discovering regular interfaces but also proactively uncovering deep, conditionally triggered hidden interfaces. It can also accurately locate unknown interfaces and complete targeted risk assessments, improving interface test coverage, eliminating security blind spots, and exposing security vulnerabilities such as unauthorized access and data leakage in advance, effectively ensuring the interface security and operational stability of the software system. Attached Figure Description

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

[0040] Figure 1 This is a schematic flowchart of the interface traversal method based on multidimensional traffic analysis and intelligent fuzz testing described in this invention.

[0041] Figure 2 This is a visual interface diagram of the interface traversal method based on multidimensional traffic analysis and intelligent fuzz testing described in this invention.

[0042] Figure 3 This is a structural diagram of the interface traversal system based on multidimensional traffic analysis and intelligent fuzz testing described in this invention. Detailed Implementation

[0043] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0044] Example 1

[0045] like Figure 1 and Figure 2 As shown, the interface traversal method based on multidimensional traffic analysis and intelligent fuzz testing specifically includes the following steps:

[0046] Step S1: Obtain multi-source interface data of the software under test;

[0047] The multi-source interface data in step S1 includes a dynamic interface dataset generated through dynamic traffic monitoring, a static interface dataset generated through static code analysis, and a configuration interface dataset generated through configuration file scanning. Each of the dynamic, static, and configuration interface datasets contains at least an interface access path and an HTTP request method. The data acquisition process is as follows:

[0048] (1) Dynamic interface dataset generated through dynamic traffic monitoring

[0049] In practical applications, the dynamic interface dataset generated through dynamic traffic monitoring specifically involves: deploying a traffic acquisition agent to capture the network traffic of the software under test; driving automated test scripts to traverse the software under test; extracting interface access paths and HTTP request methods; and organizing them to generate the dynamic interface dataset. Specifically, this includes the following steps:

[0050] Step S111: Deploy the traffic collection agent;

[0051] Start Ingress as a traffic acquisition proxy on the test server of the software under test, and configure it to listen on port 8080. By adjusting the network configuration of the test environment or the proxy settings of the client, the traffic forwarding rules are configured to ensure that all network traffic sent to the application system under test (running on port 8081) is forwarded through the Ingress proxy, thereby achieving bypass capture of all network traffic entering and leaving the system under test.

[0052] Step S112: Drive the automated test script to traverse the software under test;

[0053] Drive automated test scripts and simulate user operations to perform full-function traversal of the software under test: Use Selenium to write automated test scripts to simulate user login, registration check, list query and other core business process operations; at the same time, use Postman to drive API test collections to make batch calls to known interfaces in the system to achieve full coverage of common interface access scenarios.

[0054] Step S113: Extract the interface access path and HTTP request method to generate a dynamic interface dataset.

[0055] During the automated traversal operation, the Ingress proxy's custom plugin captures all HTTP API requests entering and leaving the tested system in real time. For each captured request, the API request information is extracted and standardized using the original HTTP request message as the data source. In this example, taking the request http: / / host:port / api / v1 / users / 123 as an example, the extracted and processed standardized information is as follows:

[0056] { "url":" / api / v1 / users / {id}", # Normalize the path parameter {id} "method":"GET", "parameters":{"id":"123"}, "headers":{"Authorization":"Bearerxyz"}, "source":"dynamic"}

[0057] Here, url is the standardized interface access path; method is the HTTP request method, which is GET in this example. In actual applications, this field can also include POST, PUT, DELETE, etc.; parameters is the set of interface request parameters, which only includes the concrete value "123" for the path parameter {id} in this example. In actual applications, this field can cover path parameters, query parameters, body parameters, and other parameters required for interface calls; headers is the structured storage format of the HTTP request headers, which only includes the authorization field Authorization in this example. In actual applications, this field can also include authorization fields such as Token and Cookie, as well as non-authorization fields such as Content-Type; source is the source type identifier of the interface data. In this example, the value "dynamic" indicates that the interface data comes from dynamic traffic monitoring.

[0058] Using the standardized interface access path and HTTP request method as composite unique keys (url, method), all standardized API request information is deduplicated and filtered. The filtered unique request combinations and their complete association information are stored to form a dynamic interface dataset.

[0059] (2) Static interface dataset generated through static code analysis

[0060] In practical applications, the static interface dataset generated through static code analysis specifically involves: obtaining the target code file of the software under test; parsing the target code file based on abstract syntax tree (AST) technology; reconstructing the complete interface access path and associating it with the corresponding HTTP request methods to generate the static interface dataset. This includes the following steps:

[0061] Step S121: Obtain the target code file of the software under test;

[0062] Based on the technical architecture of the software under test, its source code or bytecode files are retrieved as target code files for static code analysis. In this embodiment, for the application system under test developed based on the .NET framework, the latest main branch source code of the system in the Git code repository is retrieved. If the system under test only provides compiled artifacts, the compiled bytecode files (such as .dll files) are obtained.

[0063] Step S122: Parse the target code file based on abstract syntax tree technology.

[0064] The static code scanning engine is launched, traversing all target code files to complete file format verification and encoding unification. In this embodiment, for C# code files (.cs files), the Roslyn compiler open-source toolset is used to parse each .cs file into an Abstract Syntax Tree (AST). All nodes of the AST are traversed, and features (C#) / annotations (Java, etc.) related to interface definitions in the code are accurately identified according to preset feature rules. The specific classification and identification rules are as follows:

[0065] Class-level attributes: Filter controller classes marked with the [ApiController] attribute, and extract the path parameters from the [Route("...")] attribute of that class;

[0066] Method-level attributes: Within the scope of the identified controller classes, further filter member methods marked with HTTP request method attributes such as [HttpGet], [HttpPost], [HttpPut], and [HttpDelete], and extract the path parameters from the [Route("...")] attribute on the method.

[0067] Step S123: Reconstruct the complete interface access path and associate it with the corresponding HTTP request method to generate a static interface dataset.

[0068] Parse the class-level and method-level path parameters mentioned above, concatenate the method-level path with the path of its class to reconstruct the complete interface access path, and associate it with the corresponding HTTP request method (such as GET, POST, etc.). The specific reconstruction logic is as follows:

[0069] Parse path values ​​in class-level attributes: If dynamic placeholders are included (such as [controller]), replace them with the lowercase form of the controller class name without the "Controller" suffix (such as replacing UserController with users);

[0070] Parse the path value in the method-level attribute (such as "{id}" in HttpGet("{id}")], and concatenate it to the class-level path to form the complete interface path; if the method-level path starts with " / ", then directly overwrite the end part of the class-level path;

[0071] Associate the HTTP request method corresponding to the associated method-level feature, record the placeholder format of dynamic parameters in the path (such as {id}), and complete the reconstruction of a single interface information.

[0072] In this embodiment, a UserController class is defined in the code under test. This class inherits from ControllerBase and is marked with the [Route("api / v1 / [controller]")] attribute. Its internal GetUser method is marked with the [HttpGet("{id}")] attribute. The specific code is as follows:

[0073] [ApiController] [Route("api / v1 / [controller]")] public class UserController : ControllerBase { [HttpGet("{id}")] public ActionResult <user>GetUser(string id) { ...} }

[0074] Based on the above refactoring rules, the complete interface access path for this class and method is / api / v1 / users / {id}, and the corresponding HTTP request method is GET.

[0075] All reconstructed complete interface access paths, corresponding HTTP request methods, and related annotation information are compiled and organized to form a static interface dataset.

[0076] (3) Scan the generated configuration interface dataset through the configuration file.

[0077] In practical applications, the configuration interface dataset generated by scanning the configuration file specifically involves: scanning the configuration file of the software under test, parsing the interface access paths and associated HTTP request methods in the configuration file, and generating the configuration interface dataset. This includes the following steps:

[0078] Step S131: Scan the configuration files of the software under test;

[0079] The configuration files of the software under test include system configuration files and static resource files. In this embodiment, for the system under test developed based on the .NET framework, files that accompany the source code are pulled from the Git code repository, and relevant files that take effect at runtime are extracted from the test deployment environment. The scanning scope includes the following two types of files:

[0080] System configuration files: core configuration files such as appsettings.json and appsettings.Development.json;

[0081] Static resource files: Swagger / OpenAPI specification files (swagger.json, openapi.json), API gateway routing rule configuration files, etc.

[0082] Step S132: Parse the interface access path and associated HTTP request method in the configuration file to generate a configuration interface dataset.

[0083] For different types of target files, appropriate parsing tools are used to perform structured parsing and extract interface definition-related information according to preset rules. In this embodiment, JSON format files are uniformly parsed using a JSON parsing library, and the specific parsing rules are as follows:

[0084] System configuration file: Traverse the key-value pair structure of the file to extract explicit interface access path information such as route prefix, health check path, and service endpoint path;

[0085] Static resource files: For Swagger / OpenAPI specification files, locate the core paths object node in the file, parse all interface paths under this node, and associate the corresponding HTTP request method (GET / POST / PUT / DELETE, etc.) for each path; for API gateway routing rule configuration files, parse the routing forwarding configuration and extract the valid target interface paths pointing to the system under test.

[0086] All core interface information extracted from the parsing is summarized to generate an independent configuration interface dataset. For example, the interface path / health is extracted from the configuration item "HealthChecks-UI":{"HealthChecks":[{"Uri":" / health"}]} in the appsettings.json file, and the method is marked as "to be verified"; the path / api / v1 / roles and the corresponding GET and POST request methods are parsed from the paths node in the swagger.json file; the extracted interface information is organized and archived to finally generate the configuration interface dataset.

[0087] Step S2: Perform fusion and deduplication preprocessing on the multi-source interface data to obtain the full initial interface data of the software under test;

[0088] The preprocessing for fusion and deduplication of the multi-source interface data in step S2 specifically involves: performing data fusion and deduplication preprocessing based on the interface access path and request method. This includes the following steps:

[0089] Step S21: Normalize the interface access paths of each dataset in the multi-source interface data to obtain normalized interface access paths.

[0090] First, the data fusion engine is started, loading all interface information from the dynamic interface dataset, static interface dataset, and configuration interface dataset into memory. Then, a unified normalization process is performed on all interface access paths in the three datasets in memory, converting the concrete path parameters into a standardized template format to achieve a unified format for the same interface access path across different datasets. Specifically, concrete numerical and character path parameters in the interface access path (such as 123 in / api / v1 / users / 123 and NO001 in / api / v1 / orders / NO001) are uniformly replaced with placeholder formats (such as {id} and {orderNo}) to form a normalized access path (normalized_url). Interface access paths without path parameters (such as / health) retain their original format, ensuring that the template format of all interface access paths is consistent.

[0091] Step S22: Using the normalized interface access path and HTTP request method as a composite unique key, merge and deduplicate the datasets in the multi-source interface data to generate full initial interface data.

[0092] Using the normalized interface access path and HTTP request method as composite unique keys (normalized_url, http_method), an in-memory set is created and all normalized interface information is traversed. Intelligent deduplication and multi-source information fusion operations are performed. The core processing rules are as follows:

[0093] If the composite key of the interface being traversed is not in the collection, then add the interface information to the collection and mark its original source (such as dynamic, static, configuration).

[0094] If the composite key of the interface being iterated over is already in the collection, it is determined to be the same interface, and it is not added again. Only the source field of that interface is merged and updated, and the source information of all datasets is retained.

[0095] In this embodiment, after normalization, both / api / v1 / users / 123 (GET) in the dynamic interface dataset and / api / v1 / users / {id} (GET) in the static interface dataset have the composite key ( / api / v1 / users / {id},GET), indicating that they are the same interface. After merging, only one interface record is retained, and the source field is marked as [dynamic, static]. If the interface also exists in the configuration interface dataset, the source field is updated to [dynamic, static, configuration].

[0096] After normalizing, deduplicating, and merging all interfaces, the processed interface information in the memory set is summarized and organized in a structured format. The summarized interface information is then checked for completeness to ensure that there are no omissions or duplicates, and finally, standardized full initial interface data is generated.

[0097] Step S3: Perform intelligent fuzz testing on the full initial interface data to identify and supplement potential hidden interface data into the full initial interface data, thereby obtaining the full final interface data;

[0098] The intelligent fuzz test performed on the full initial interface data in step S3 specifically includes:

[0099] Step S31: Traverse the entire initial interface data and generate a test case set according to the parameter types of each interface; specifically:

[0100] The intelligent testing engine is activated, traversing every interface in the full initial interface data. Based on the interface parameter type (path parameter, query parameter, Body parameter), it automatically generates a set of structured test cases covering valid values, boundary values, and outliers, and defines test case generation rules for different parameter types.

[0101] Path parameters (e.g., / users / {id}): Generate test values ​​covering normal valid values ​​(1, 100), boundary values ​​(0, 999999), and abnormal values ​​(-1, / etc / passwd, special character combinations @#$), covering abnormal scenarios such as numerical out-of-bounds errors and path traversal.

[0102] Query parameters (e.g., ?name=xxx): Generate multiple types of test strings, including valid regular strings (testuser), excessively long strings (random characters exceeding the interface parameter length limit), and malicious injection fragments (e.g., SQL injection: 'OR'1'='1, XSS attack:). <script>alert(1) < / script> ), null values, NULL, and other abnormal values;

[0103] Body parameter (JSON format): Parses the C# model class structure associated with the interface (such as the User model containing id, name, and age fields), generating three types of JSON payloads:

[0104] Valid JSON: A standard format with complete fields and matching types ({"id":"1", "name":"test","age":20});

[0105] Abnormal JSON: missing core field ({"id":"1"}), incorrect field type ({"age":"abc"}, the numeric age field was passed the string "abc") and other non-standard formats;

[0106] Malicious JSON: Non-standard formats that embed SQL injection and XSS attack fragments.

[0107] Step S32: The intelligent testing engine sends the test requests corresponding to the test case set to the software under test, wherein all test requests are sent through a traffic acquisition proxy; specifically:

[0108] Based on the generated test case set, fuzz testing is performed through an intelligent testing engine, and the system's full response traffic is continuously monitored. In this embodiment, the HttpClient library in C# is used for the system under test with the .NET technology stack, or the requests library in Python is used in general scenarios. The request payloads corresponding to all test cases are sent to the application system under test one by one. All test requests are forcibly routed to the Ingress traffic collection proxy deployed in step S111 to ensure that the proxy can capture the complete response data of each request.

[0109] Step S33: Monitor the system responses of the software under test to all test requests, and collect system response data to identify potential hidden interfaces. Specifically:

[0110] The Ingress traffic acquisition agent records system response data for all test requests in real time, including response status codes, response bodies, response headers, interface access paths, and HTTP request methods, forming complete system response data to support subsequent identification of potential hidden interfaces. The response analysis engine is then activated to parse the system response data captured by the Ingress traffic acquisition agent and identify potential hidden interfaces according to preset rules.

[0111] In practical applications, the collection of system response data to identify potential hidden interfaces specifically involves: filtering out interfaces from the system response data whose response status codes are neither 404 nor 405, and whose corresponding interface access paths and HTTP request method combinations are not included in the full set of initial interface data, as potential hidden interfaces. Specifically:

[0112] Filter request records with response status codes 404 (Not Found) and 405 (Method Not Allowed), retaining only records with status codes other than 404 / 405, such as 200 (OK), 400 (Bad Request), 403 (Forbidden), and 500 (Internal Server Error). Interface dataset comparison: Extract the (url, method) combination of the filtered records and compare it with the full initial interface data. If the combination does not exist in the dataset, it is determined to be a potential hidden interface. In this embodiment, after sending a fuzzy payload to the known interface / api / v1 / users / 1 (GET), the system returns a 500 error. Simultaneously, the Ingress proxy captures the response (status code 500) of the internal debugging interface / api / debug / dump (GET) triggered by this request. Comparison reveals that / api / debug / dump (GET) is not in the full initial interface data, thus determining it to be a potential hidden interface and adding it to the full initial interface data.

[0113] Next, a recursive probing process is initiated to iteratively expand the interface dataset until no new interfaces are discovered. Specifically, all valid potential hidden interfaces are added to the full initial interface data, identified as hidden interfaces, and a new interface dataset is formed after iteration. Using the new interface dataset as input, steps S31 to S33 are repeated to generate dedicated test cases for the newly added hidden interfaces, perform fuzz testing, and identify a new round of potential hidden interfaces. In this embodiment, the preset recursive rounds are 3. If no new potential hidden interfaces are found after a certain round of recursion, or if the preset rounds of recursive probing have been completed, the process is terminated. Finally, a full final interface dataset containing all interfaces is generated.

[0114] Step S4: Visualize the full set of final interface data, perform data comparison and risk assessment, and generate a software interface traversal test report. This specifically includes the following steps:

[0115] Step S41: Obtain development and testing interface data;

[0116] Read the development test interface data (Excel or JSON format) provided by the developers before testing, extract the core fields such as "interface access path" and "HTTP request method" from the development test interface data, and unify the format according to the normalized interface access path rules in step S2.

[0117] Step S42: Visualize and present all final interface data;

[0118] Integrate all the final interface data generated in step S3 to produce a structured, interactive full interface graph, clearly presenting the business affiliation, hierarchical relationship, and call dependencies of the interfaces. Specifically, it is presented in the form of a tree structure or a network diagram. The tree structure shows the business module affiliation and hierarchical relationship of the interfaces, while the network diagram shows the call dependencies between interfaces. This embodiment uses the ECharts visualization library to complete the graph rendering. The visualization interface after the graph rendering includes:

[0119] Interface statistics module: Displays key metrics such as total number of interfaces, number of dynamically discovered interfaces, number of statically discovered interfaces, number of interfaces detected by configuration scanning, number of interfaces detected by fuzz testing, and number of hidden interfaces;

[0120] Interface List Module: Displays core interface information in tabular form, including HTTP request method (GET, PUT, etc.), normalized URL, source (dynamic, static, configuration), status (normal, hidden), and description (interface discovery source description).

[0121] Hidden Interface List Module: Displays hidden interface information separately, including request method, URL, discovery method (dynamic / static / config), and description (discovery scenario description).

[0122] Step S43: Compare the full set of final interface data with the development and testing interface data, and highlight the interfaces that have not been tested; specifically:

[0123] The entire final interface data is compared with the development and testing interface data to filter out the untested interfaces that only exist in the entire final interface data; finally, the untested interfaces are highlighted. In this embodiment, the source field of the interface list module is highlighted with a red border and red background, and a "hidden" label is marked inside the border.

[0124] Step S44: Perform a risk assessment on the full set of final interface data and generate a software interface traversal test report. Specifically:

[0125] Focusing on two risk scenarios—unauthorized access and sensitive information leakage—a risk assessment was conducted on all interfaces (with a focus on the highlighted interfaces that have not yet been submitted for testing).

[0126] Unauthorized access test logic: Remove authorization fields such as Token, Cookie, and Authorization from the request headers, send a request without authentication information to each interface, and perform one standardized access test; if the interface returns a success status code such as 200 (OK) or 201 (Created), it is judged as "high risk - unauthorized access"; if it returns an authorization error code such as 401 (Unauthorized) or 403 (Forbidden), it is judged as "low risk - authorization control is effective";

[0127] Sensitive information leakage detection logic: Parse the interface response body content (the core data returned by the server to the requester after receiving the HTTP request from the interface), and match sensitive information features through a preset regular expression library, such as mobile phone number (^1[3-9]\d{9}$), ID card number (^\d{17}[\dXx]$), etc.; if any sensitive information regular expression rule is matched, it is judged as "medium risk - sensitive information leakage"; if no match is found, it is marked as "low risk - no sensitive information leakage";

[0128] The system integrates all final interface data, interface comparison results, and risk assessment data to generate a structured HTML-formatted software interface traversal test report. This report includes the total number of final interfaces, the total number of interfaces not submitted for testing, information on high-risk interfaces, and recommendations. It also supports exporting to Excel format, facilitating developers' precise identification and remediation of untested and high-risk interfaces.

[0129] Example 2

[0130] like Figure 3 As shown, an interface traversal system based on multidimensional traffic analysis and intelligent fuzz testing is used to implement the method described in Embodiment 1. The system includes:

[0131] The data acquisition module M1 acquires multi-source interface data of the software under test. The multi-source interface data includes a dynamic interface dataset generated by dynamic traffic monitoring, a static interface dataset generated by static code analysis, and a configuration interface dataset generated by configuration file scanning. The dynamic interface dataset, static interface dataset, and configuration interface dataset all contain at least the interface access path and HTTP request method.

[0132] The data processing module M2 performs fusion and deduplication preprocessing on the multi-source interface data to obtain the full initial interface data of the software under test.

[0133] The intelligent fuzz testing module M3 performs intelligent fuzz testing on the full initial interface data to identify and supplement potential hidden interface data into the full initial interface data, thereby obtaining the full final interface data.

[0134] The result generation module M4 visualizes the full set of final interface data and generates a software interface traversal test report.

[0135] The advantages of this invention are as follows: By collecting multi-source interface data through dynamic traffic monitoring, static code analysis, and configuration file scanning, combined with intelligent closed-loop detection through fuzz testing and real-time traffic monitoring, and coupled with intelligent comparison of untested interfaces and targeted risk assessment, it achieves synergistic complementarity in multi-dimensional interface discovery, breaking through the coverage limitations of single interface discovery methods. This solution completely eliminates the reliance on manual documentation and preset test cases, not only comprehensively discovering regular interfaces but also proactively uncovering deep, conditionally triggered hidden interfaces. It can also accurately locate unknown interfaces and complete targeted risk assessments, improving interface test coverage, eliminating security blind spots, and exposing security vulnerabilities such as unauthorized access and data leakage in advance, effectively ensuring the interface security and operational stability of the software system.

[0136] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / user>

Claims

1. An interface traversal method based on multidimensional traffic analysis and intelligent fuzz testing, characterized in that, The method includes: Acquire multi-source interface data of the software under test. The multi-source interface data includes dynamic interface datasets generated by dynamic traffic monitoring, static interface datasets generated by static code analysis, and configuration interface datasets generated by configuration file scanning. Each of the dynamic interface dataset, static interface dataset, and configuration interface dataset contains at least the interface access path and HTTP request method. The multi-source interface data is fused and deduplicated to obtain the full initial interface data of the software under test. Perform intelligent fuzz testing on the full initial interface data to identify and supplement potential hidden interface data into the full initial interface data, thereby obtaining the full final interface data. The full set of final interface data is visualized, data is compared, risk assessment is conducted, and a software interface traversal test report is generated.

2. The interface traversal method according to claim 1, characterized in that, The dynamic interface dataset generated through dynamic traffic monitoring specifically involves: deploying a traffic acquisition agent to capture the network traffic of the software under test; driving automated test scripts to traverse the software under test; extracting interface access paths and HTTP request methods; and organizing them to generate a dynamic interface dataset.

3. The interface traversal method according to claim 1, characterized in that, The static interface dataset generated through static code analysis specifically involves: obtaining the target code file of the software under test; The target code file is parsed using abstract syntax tree technology; the complete interface access path is reconstructed, and the corresponding HTTP request methods are associated to generate a static interface dataset.

4. The interface traversal method according to claim 1, characterized in that, The configuration interface dataset generated by scanning the configuration file specifically involves scanning the configuration file of the software under test, parsing the interface access paths and associated HTTP request methods in the configuration file, and generating the configuration interface dataset.

5. The interface traversal method according to any one of claims 1 to 4, characterized in that, The specific method for performing fusion and deduplication preprocessing on the multi-source interface data is as follows: data fusion and deduplication preprocessing is performed based on the interface access path and request method.

6. The interface traversal method according to claim 5, characterized in that, The data fusion and deduplication preprocessing based on the interface access path and request method specifically involves: The interface access paths of each dataset in the multi-source interface data are normalized to obtain normalized interface access paths. Using the normalized interface access path and HTTP request method as a composite unique key, the datasets in the multi-source interface data are merged and deduplicated to generate full initial interface data.

7. The interface traversal method according to claim 6, characterized in that, The process of performing intelligent fuzz testing on the full initial interface data specifically includes: Iterate through all the initial interface data and generate a test case set based on the parameter types of each interface; The intelligent testing engine sends the test requests corresponding to the test case set to the software under test. All test requests are sent through a traffic collection proxy. Monitor the system response of the software under test to all test requests, and collect system response data to identify potential hidden interfaces.

8. The interface traversal method according to claim 7, characterized in that, The specific steps of collecting system response data to identify potential hidden interfaces are as follows: filtering out interfaces whose response status codes are not 404 or 405, and whose corresponding interface access paths and HTTP request method combinations are not included in the full set of initial interface data, as potential hidden interfaces.

9. The interface traversal method according to claim 1, characterized in that, The process of visualizing the full set of final interface data, comparing data, conducting risk assessments, and generating a software interface traversal test report specifically includes: Obtain data from the development and testing interface; Visualize the full final interface data; The full set of final interface data is compared with the development and testing interface data, and the interfaces that have not been tested are highlighted. A risk assessment is performed on the full set of final interface data, and a software interface traversal test report is generated.

10. An interface traversal system based on multidimensional traffic analysis and intelligent fuzz testing, wherein the system is implemented based on the interface traversal method based on multidimensional traffic analysis and intelligent fuzz testing as described in any one of claims 1 to 9, characterized in that, The system includes: The data acquisition module acquires multi-source interface data of the software under test. The multi-source interface data includes dynamic interface datasets generated by dynamic traffic monitoring, static interface datasets generated by static code analysis, and configuration interface datasets generated by configuration file scanning. Each of the dynamic interface datasets, static interface datasets, and configuration interface datasets contains at least the interface access path and the HTTP request method. The data processing module performs fusion and deduplication preprocessing on the multi-source interface data to obtain the full initial interface data of the software under test. The intelligent fuzz testing module performs intelligent fuzz testing on the full initial interface data, identifies and supplements potential hidden interface data into the full initial interface data, and obtains the full final interface data. The results generation module visualizes the full set of final interface data and generates a software interface traversal test report.

Images