Fuzzy test verification method and system for password service interface
By constructing a feature library for cryptographic service interfaces and a multi-dimensional fuzzing mutation strategy, the adaptability and coverage issues of existing fuzzing techniques on cryptographic service interfaces are solved, achieving efficient and accurate vulnerability location and automated testing, applicable to cryptographic service interfaces with various protocols and data formats.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI UNI SENTRY INTELLIGENT TECH CO LTD
- Filing Date
- 2026-02-26
- Publication Date
- 2026-05-15
AI Technical Summary
Existing fuzzing techniques have poor adaptability to cryptographic service interfaces, incomplete test coverage, low vulnerability location efficiency, and low automation, making it difficult to meet the security testing needs of large-scale cryptographic service interfaces.
Construct a feature library for cryptographic service interfaces, design multi-dimensional fuzzing mutation strategies, achieve protocol and data format adaptation through a dynamic adaptation module, generate optimized test case sets, collect response information in real time, conduct in-depth analysis and construct vulnerability association maps, and generate standardized test reports.
It enables efficient and accurate security verification of cryptographic service interfaces, improves test coverage and vulnerability location efficiency, enhances automation, is applicable to multiple protocols and data formats, and supports large-scale testing needs.
Smart Images
Figure CN122053183A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of cryptographic service technology and software testing technology, and in particular to a fuzz testing verification method and system for cryptographic service interfaces. Background Technology
[0002] With the rapid development of information technology, cryptographic services are increasingly widely used in key areas such as finance, government affairs, and e-commerce. As the core entry point for providing cryptographic services, the security of the cryptographic service interface directly affects the secure and stable operation of the entire information system. Fuzz testing, as a highly efficient software vulnerability discovery technique, discovers potential security vulnerabilities by inputting unexpected test cases into the target system and observing the system's abnormal responses. It has been widely used in the security testing of various software interfaces.
[0003] However, existing fuzzing techniques have several shortcomings when applied to cryptographic service interfaces: First, poor adaptability. Cryptographic service interfaces have diverse protocol types, complex parameter structures, and include encryption processing, while existing fuzzing tools are mostly designed for general interfaces, making it difficult to accurately adapt to different types of cryptographic service interfaces. This results in test cases failing to execute properly or achieving poor test results. Second, incomplete test coverage. Existing technologies often focus on parameter variations at the syntax level, ignoring the unique encryption scenario anomalies and semantic logic anomalies of cryptographic service interfaces, leading to low test coverage and difficulty in discovering deep-seated security vulnerabilities. Third, low vulnerability localization efficiency. The testing process only collects simple response information, lacking in-depth analysis of abnormal data and tracing of vulnerability trigger paths. When anomalies occur, developers find it difficult to quickly locate the root cause of the vulnerability. Fourth, low level of test automation. Extensive manual intervention is required in the test case design, interface adaptation, and result analysis processes, resulting in low testing efficiency and making it difficult to meet the testing needs of large-scale cryptographic service interfaces.
[0004] Given the unique characteristics of cryptographic service interfaces, designing a fuzzy testing verification method and system that is highly adaptable, provides comprehensive test coverage, accurately locates vulnerabilities, and is highly automated has become an urgent technical problem to be solved in the field of cryptographic service security testing.
[0005] Therefore, this application provides a fuzzing verification method and system for cryptographic service interfaces. Summary of the Invention
[0006] The purpose of this invention is to propose a fuzzing verification method and system for cryptographic service interfaces to solve the problems mentioned in the background art: to solve the problems of poor adaptability, incomplete test coverage, low efficiency in vulnerability location and low degree of automation of existing fuzzing techniques for cryptographic service interfaces, and to achieve efficient and accurate security verification of cryptographic service interfaces.
[0007] To achieve the above objectives, this invention provides a fuzzing verification method for cryptographic service interfaces, comprising the following steps: Step S1: Interface Feature Collection and Feature Library Construction: Collect feature information of the target cryptographic service interface; standardize the collected feature information and construct a cryptographic service interface feature library. The cryptographic service interface feature library supports dynamic updates and expansion of feature information. Step S2: Multi-dimensional mutation strategy design and test case generation: Based on the cryptographic service interface feature library, design a multi-dimensional fuzzing mutation strategy; according to the multi-dimensional fuzzing mutation strategy, combined with the normal value range and constraint rules of the target cryptographic service interface parameters, generate an initial test case set, and perform deduplication and priority sorting on the initial test case set to obtain the final fuzzing test case set; Step S3: Dynamic Adaptation and Test Execution: Set up the test execution environment, parse the communication protocol and data format of the target cryptographic service interface through the dynamic adaptation module, and realize the communication adaptation between the test cases and the target cryptographic service interface; according to the priority order of the test cases, call the target cryptographic service interface to perform fuzz testing in sequence, and collect the response code, response data, execution time and server running status information of the target cryptographic service interface in real time to form a test process dataset; Step S4: Anomaly Detection and Vulnerability Analysis: Based on preset anomaly judgment rules, the test process dataset is filtered to identify abnormal response data and abnormal running status; the anomaly information is analyzed in depth to determine the vulnerability type, trace the test cases and call paths that trigger the vulnerability, and construct a vulnerability association graph; Step S5: Test Report Generation: Generate a standardized test report based on the test execution results and vulnerability analysis results.
[0008] Preferably, in step S1, the interface feature collection adopts a combination of static parsing and dynamic probing: static parsing of the development documents and definition files of the target cryptographic service interface to extract basic feature information; dynamic probing by sending preset normal requests to collect the actual response data and interaction process information of the target cryptographic service interface to supplement and improve the feature information; the feature information includes the target cryptographic service interface protocol type, request parameter structure, parameter constraints, supported encryption algorithm types, data transmission format and calling permission information.
[0009] Preferably, in step S1, the matching degree between the target cryptographic service interface and the feature information of the standard cryptographic service interface in the cryptographic service interface feature library is calculated using the following formula: ; in, The degree of matching between the target cryptographic service interface and the feature information of standard cryptographic service interfaces in the cryptographic service interface feature library. For the first Weights of class feature information For the target cryptographic service interface The similarity between class feature information and corresponding feature information of standard cryptographic service interfaces. This represents the total number of feature information categories.
[0010] Preferably, in step S2, the multi-dimensional fuzzing mutation strategy includes syntax-level mutation, semantic-level mutation, and encryption scenario-level mutation: Syntactic variations: The format, type, and length of the request parameters for the target cryptographic service interface are varied, including parameter type conversion errors, parameter length exceeding the limit, insertion of special characters, and missing parameters; Semantic variation: Based on the semantic constraints of the target cryptographic service interface parameters, generate parameter values that do not conform to business logic, including parameter values that are out of the valid range, related parameters that do not match, and abnormal business status. Encryption scenario-level variations: For the encryption algorithms supported by the target cryptographic service interface, generate test cases with abnormal encryption parameters, including encryption key errors, encryption algorithm mismatches, plaintext data format errors, and signature verification failure scenarios.
[0011] Preferably, in step S2, the test case priority is calculated using the following formula: ; ; in, For the first Priority of each test case The feature coverage for this use case. This represents the probability of triggering historical vulnerabilities. For use case complexity, , , These are the weighting coefficients.
[0012] Preferably, in step S4, the anomaly determination rules include response code anomaly rules, response data format anomaly rules, execution time threshold rules, and server resource usage anomaly rules; the vulnerability types include input validation vulnerabilities, privilege bypass vulnerabilities, encryption algorithm application vulnerabilities, and resource leakage vulnerabilities.
[0013] Preferably, in step S5, the test report includes a test overview, test coverage statistics, vulnerability details, risk level assessment, and remediation recommendations.
[0014] A fuzzing verification system for a cryptographic service interface, implementing a fuzzing verification method for the cryptographic service interface, including: Feature extraction module: used to collect feature information of the target cryptographic service interface, standardize the feature information, and build and maintain the cryptographic service interface feature library; Test case generation module: Connects to the feature extraction module, designs a multi-dimensional fuzzing mutation strategy based on the cryptographic service interface feature library, and generates and optimizes the fuzzing test case set; Dynamic Adaptation Module: Used to parse the communication protocol and data format of the target cryptographic service interface, realize the communication adaptation between test cases and the target cryptographic service interface, and support the conversion of multiple protocol types and data formats; Test execution module: Connects to the dynamic adaptation module, calls the target password service interface to perform fuzz testing according to priority, and collects various data in real time during the testing process; Anomaly Analysis Module: Connects to the test execution module, filters anomaly information based on preset anomaly judgment rules, performs in-depth analysis of the anomaly information, and locates the vulnerability type and trigger path; Report generation module: Connects to the anomaly analysis module and generates a standardized test report based on the test execution results and vulnerability analysis results. The report includes a test overview, coverage statistics, vulnerability details, and remediation suggestions.
[0015] Preferably, the test case generation module includes a strategy design unit, a test case generation unit, and a test case optimization unit; the strategy design unit designs multi-dimensional fuzzy testing mutation strategies at the syntax, semantic, and encryption scenario levels based on the cryptographic service interface feature library; the test case generation unit generates an initial test case set according to the multi-dimensional fuzzy testing mutation strategies; and the test case optimization unit performs deduplication and priority sorting on the initial test case set to improve testing efficiency.
[0016] Preferably, the anomaly analysis module includes an anomaly filtering unit, a vulnerability location unit, and a correlation analysis unit; the anomaly filtering unit filters anomaly information from the test process dataset based on preset rules; the vulnerability location unit determines the vulnerability type and the corresponding triggering test case; the correlation analysis unit constructs a correlation graph between the vulnerability and the call path and parameter variation type to assist in vulnerability tracing.
[0017] Therefore, the fuzzing verification method and system for cryptographic service interfaces described above have the following advantages: (1) Strong adaptability: By constructing a cryptographic service interface feature library and combining it with a dynamic adaptation module, this invention achieves accurate adaptation of cryptographic service interfaces for various protocol types, data formats and encryption algorithms, solves the problem of poor adaptability of existing technologies for cryptographic service interfaces, and expands the application scope of fuzz testing. (2) Comprehensive test coverage: This invention designs a multi-dimensional fuzzy testing mutation strategy at the syntax, semantic and encryption scenario levels. It not only covers traditional syntax anomaly testing, but also focuses on encryption scenario anomalies and semantic logic anomalies in response to the special characteristics of cryptographic service interfaces, which significantly improves test coverage and can discover deep-seated security vulnerabilities. (3) Accurate vulnerability location: This invention constructs a correlation graph between vulnerabilities, test cases, and cryptographic service interface call paths through in-depth analysis of test process data, which can quickly locate vulnerability types and triggering root causes, and improve vulnerability repair efficiency; (4) High degree of automation: The present invention realizes full automation from the collection of cryptographic service interface feature information, test case generation, test execution to anomaly analysis and report generation, reducing manual intervention, significantly improving test efficiency, and meeting the testing needs of large-scale cryptographic service interfaces.
[0018] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description
[0019] Figure 1 This is a flowchart of the method steps of a fuzzy testing verification method and system for a cryptographic service interface mentioned in an embodiment of the present invention; Figure 2 This is a schematic diagram of the system module structure of a fuzzy testing verification method and system for a cryptographic service interface mentioned in an embodiment of the present invention. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
[0021] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0022] Example like Figures 1-2As shown, this invention provides a fuzzing verification method for a cryptographic service interface, comprising the following steps: Step 1: Interface Feature Acquisition and Feature Library Construction Collect characteristic information of the target cryptographic service interface, including interface protocol type (such as HTTP / HTTPS, TCP, UDP, custom private protocol, etc.), request parameter structure (including required parameters, optional parameters, parameter data type, parameter length constraints, etc.), parameter constraints (including parameter value range, format specifications, related parameter dependencies, etc.), supported encryption algorithm types (such as SM2, SM3, SM4, RSA, AES, etc.), data transmission format (such as JSON, XML, binary format, etc.), and interface call permission information (such as whether identity authentication is required, authentication method, token validity period, etc.).
[0023] Feature collection employs a combination of static analysis and dynamic probing: static analysis of the target cryptographic service interface's development documentation and definition files (such as Swagger documentation, Protobuf files, etc.) extracts basic feature information; dynamic probing involves sending pre-defined normal requests to the target interface to collect actual response data, protocol details during the interaction process, and authorization verification process information, supplementing and refining the feature information. The collected feature information is standardized, unifying data formats and description specifications to construct a cryptographic service interface feature library. This feature library supports dynamic updates and expansions of feature information, and can be maintained in real-time based on new cryptographic service interface types or changes in feature information. The matching degree of feature information is calculated using the following formula: ; in, The degree of matching between the target cryptographic service interface and the feature information of standard cryptographic service interfaces in the cryptographic service interface feature library. For the first Weights of class feature information For the target cryptographic service interface The similarity between class feature information and corresponding feature information of standard cryptographic service interfaces. This represents the total number of feature information categories.
[0024] This formula can accurately determine the degree of matching between the target interface and the standard interfaces in the cryptographic service interface feature library, providing data support for subsequent dynamic adaptation.
[0025] Step 2: Multi-dimensional mutation strategy design and test case generation: Based on the feature library of cryptographic service interfaces and considering their unique characteristics, a multi-dimensional fuzzing mutation strategy is designed. This strategy includes syntax-level mutation, semantic-level mutation, and encryption scenario-level mutation, as detailed below: Syntactic variations: Variations are made to the syntax rules of the password service interface request parameters, including changing string type parameters to numeric type, parameter length exceeding the maximum limit specified by the password service interface, inserting special characters (such as single quotes, double quotes, backslashes, etc.) into parameters, missing required parameters, and repeatedly passing the same parameter. Semantic variations: Based on the semantic constraints and business logic of the password service interface parameters, parameter values that do not conform to business rules are generated, including parameter values that exceed the valid range (such as setting the password length parameter to a negative number), mismatched associated parameters (such as the encryption algorithm type and key length not matching), and abnormal business status (such as calling an authorized interface without completing identity authentication). Encryption scenario-level variations: For the encryption algorithms and encryption processing procedures supported by the cryptographic service interface, generate test cases with abnormal encryption parameters, including using the wrong encryption key, selecting an encryption algorithm type not supported by the cryptographic service interface, inputting plaintext data with abnormal format (such as plaintext data length not meeting the requirements of the encryption algorithm), inputting tampered signature data in the signature verification scenario, and missing signature parameters.
[0026] Based on the aforementioned multi-dimensional fuzzing mutation strategy, and combined with the normal value range and constraint rules of interface parameters, an initial test case set is generated using test case generation algorithms (such as genetic algorithms and particle swarm optimization algorithms). The initial test case set is then deduplicated, removing duplicate or redundant test cases. Based on the vulnerability trigger probability of the test cases, they are prioritized, with test cases covering key parameters and special encryption scenarios set as high priority, resulting in the final fuzzing test case set to improve testing efficiency. The test case priority is calculated using the following formula: ; ; in, For the first Priority of each test case The feature coverage for this use case. This represents the probability of triggering historical vulnerabilities. For use case complexity, , , These are the weighting coefficients.
[0027] Step 3: Dynamic adaptation and test execution: The test execution environment is set up, including configuring the test server, network environment, and access permissions for the target cryptographic service interface. A dynamic adaptation module parses the communication protocol and data format of the target cryptographic service interface. Based on feature information in the cryptographic service interface feature library, it automatically matches the corresponding protocol parsing rules and data conversion templates to achieve communication adaptation between test cases and the target interface. This dynamic adaptation module supports adaptation to multiple communication protocols and can adaptively convert different protocol types (such as HTTP / HTTPS, TCP, UDP, etc.) and data formats (such as JSON, XML, etc.). It also supports simulation of interface call permissions and can automatically generate compliant authentication information (such as tokens, signatures, etc.) to ensure that test cases can interact normally with the target interface.
[0028] Following the priority order of the test cases, the test execution module sequentially calls the target cryptographic service interface to perform fuzz testing. During test execution, the response information (including response code, response data, response time, etc.) and server operating status information (including CPU utilization, memory utilization, disk I / O, etc.) of the target cryptographic service interface are collected in real time. The collected information is associated with and stored with the corresponding test cases to form a test process dataset.
[0029] Step 4: Anomaly Detection and Vulnerability Analysis: Preset exception judgment rules, including response code exception rules (such as returning error codes above 400, returning undefined custom error codes, etc.), response data format exception rules (such as response data format is inconsistent with the format specified by the interface, response data is empty or contains garbled characters, etc.), execution time threshold rules (such as the interface call time exceeds the preset threshold), and server resource usage exception rules (such as CPU usage suddenly soaring to above 90%, memory leak, etc.).
[0030] Based on the aforementioned anomaly detection rules, the test process dataset is filtered to identify abnormal response data and abnormal operational states. In-depth analysis is then performed on the filtered anomaly information: First, by combining the corresponding test cases, the parameter mutation type and specific value triggering the vulnerability are determined; second, the interface call path of the test case is traced to analyze the execution flow of the interface when handling abnormal input; finally, based on the anomaly behavior and execution flow, the vulnerability type is determined, including input validation vulnerabilities, privilege escalation vulnerabilities, encryption algorithm application vulnerabilities, resource disclosure vulnerabilities, and denial-of-service vulnerabilities. A correlation graph is constructed between vulnerabilities and test cases, interface call paths, and parameter mutation types to assist developers in quickly tracing the root cause of vulnerabilities.
[0031] Step 5: Test Report Generation: Based on the test execution results and vulnerability analysis results, the report generation module generates a standardized fuzz test report. This report includes the following core contents: test overview (including test objects, test time, test scope, test environment, etc.), test coverage statistics (including parameter coverage, mutation policy coverage, interface function coverage, etc.), vulnerability details (including vulnerability number, vulnerability type, risk level, triggering conditions, impact scope, etc.), risk level assessment (classifying risk levels based on the severity and exploitation difficulty of the vulnerability, such as high-risk, medium-risk, and low-risk), and remediation recommendations (providing specific remediation solutions and technical guidance for each vulnerability). The test report supports export in multiple formats (such as PDF, Word, HTML, etc.), facilitating communication between testers and developers and subsequent vulnerability remediation work.
[0032] A fuzzing system for a cryptographic service interface, implementing a fuzzing verification method for the cryptographic service interface, including: Feature Extraction Module: This module collects feature information from the target cryptographic service interface. It employs a combination of static parsing and dynamic probing to acquire feature data, standardizes the feature information, and builds and maintains a cryptographic service interface feature library. This module includes a static parsing unit and a dynamic probing unit. The static parsing unit is responsible for parsing the development documents and definition files of the target cryptographic service interface to extract basic feature information. The dynamic probing unit is responsible for sending normal requests to the target cryptographic service interface, collecting information about the actual interaction process, and supplementing and improving the cryptographic service interface feature library. The test case generation module connects to the feature extraction module. Based on the cryptographic service interface feature library, it designs multi-dimensional fuzzy testing mutation strategies at the syntax, semantic, and encryption scenario levels. It uses a test case generation algorithm to generate an initial test case set, and then performs deduplication and priority sorting on the initial test case set to obtain an optimized fuzzy test case set. This module includes a strategy design unit, a test case generation unit, and a test case optimization unit. The strategy design unit is responsible for designing multi-dimensional fuzzy testing mutation strategies; the test case generation unit is responsible for generating the initial test case set; and the test case optimization unit is responsible for optimizing the initial test case set to improve testing efficiency. Dynamic Adaptation Module: This module parses the communication protocol and data format of the target cryptographic service interface, automatically matches the corresponding protocol parsing rules and data conversion templates, and achieves communication adaptation between test cases and the target interface. This module supports conversion of various protocol types and data formats, and also supports simulation of interface call permissions to ensure that test cases can execute correctly. Test execution module: Connects to the dynamic adaptation module, calls the target password service interface to perform fuzz testing according to the priority order of test cases, collects response information and server running status information in real time during the test process, forms a test process dataset and stores it in association; Anomaly Analysis Module: Connected to the test execution module, this module filters anomaly information based on preset anomaly judgment rules, performs in-depth analysis of the anomaly information, determines the vulnerability type and trigger path, and constructs a vulnerability association graph. This module includes an anomaly filtering unit, a vulnerability localization unit, and an association analysis unit. The anomaly filtering unit is responsible for filtering anomaly information; the vulnerability localization unit is responsible for determining the vulnerability type and triggering test cases; and the association analysis unit is responsible for constructing a vulnerability association graph to assist in vulnerability tracing. Report generation module: Connects to the anomaly analysis module and generates standardized test reports based on test execution results and vulnerability analysis results. These reports include a test overview, coverage statistics, vulnerability details, and remediation suggestions, and support export in multiple formats.
[0033] A specific implementation process is as follows: like Figure 1 As shown, this embodiment provides a fuzzing verification method for a cryptographic service interface, including the following steps: Step 1: Interface Feature Acquisition and Feature Library Construction The test target is the password service interface of a certain government system. This interface supports the SM2 asymmetric encryption algorithm and the SM3 hash algorithm, uses HTTP / HTTPS protocol for communication, the request parameter format is JSON, and identity authentication is required through a token.
[0034] Feature information is collected using a combination of static parsing and dynamic probing: Static parsing involves analyzing the Swagger documentation of the API to extract the API address, request method (POST), and required parameters including "plaintext" (plaintext data, string type, length 1-1024), "algorithm" (encryption algorithm type, string type, value "SM2"), and "token" (authentication token, string type). Optional parameters include "encoding" (encoding method, values "UTF-8" or "GBK"). Dynamic probing involves sending normal requests carrying valid tokens to collect the API response format (JSON), containing "code" (response code), "message" (response information), and "result" (encryption result) fields. The token is valid for 2 hours, and the API call timeout is 5 seconds. The collected feature information is standardized and entered into the cryptographic service API feature library. The matching degree of the feature information is calculated using the following formula: ; With protocol type, encryption algorithm, and parameter structure weights set to 0.3, 0.4, and 0.3 respectively, the matching degree between this interface and the standard HTTP+SM2 interface in the cryptographic service interface feature library is calculated. It was determined to be a high match.
[0035] Step 2: Multi-dimensional mutation strategy design and test case generation: Based on the feature information of this interface, a multi-dimensional fuzz testing mutation strategy is designed: Syntactic variations: Change the "plaintext" parameter to a numeric type (e.g., 123456), set the length of the "plaintext" parameter to 2048 (exceeding the maximum limit of 1024), insert special characters into the "token" parameter (e.g., "token'123"), omit the required "plaintext" parameter, and repeatedly pass the "algorithm" parameter; Semantic variations: Set the "algorithm" parameter to "RSA" (not supported by the interface), set the "encoding" parameter to "UTF-16" (not supported by the interface), and call the interface using an expired token; Encryption scenario-level variations include: using an incorrect SM2 private key for encryption, setting the "plaintext" parameter to an empty string (which does not meet the SM2 encryption plaintext format requirements), passing in tampered token data, and missing the "token" authentication parameter.
[0036] An initial test case set of 200 cases was generated using a genetic algorithm. The initial test case set was then deduplicated, removing 15 duplicate cases. Finally, the test cases were sorted based on a priority formula. ; Pick =0.4、 =0.4、 =0.2, the priority of test cases such as "encrypting with an incorrect SM2 private key" and "incoming tampered token data" were calculated to be 0.85 and 0.82 respectively, and set as high priority, resulting in a final set of 185 test cases.
[0037] Step 3: Dynamic adaptation and test execution: Set up the test environment and configure the test server address and access permissions for the target password service interface. The dynamic adaptation module parses the HTTP / HTTPS protocol and JSON data format of the interface, matches the corresponding protocol parsing rules and JSON data conversion template, and simulates the generation of a valid token (for normal test case execution). According to the test case priority order, the test execution module sequentially calls the target interface to perform fuzz testing, collecting interface response information in real time (such as response codes 400 and 500, response data "parameter format error," "signature verification failed," etc.) and server running status information (such as CPU utilization, memory usage, etc.) to form a test process dataset.
[0038] Step 4: Anomaly Detection and Vulnerability Analysis: Preset exception handling rules: Response codes of 400, 401, 403, 500 and above are considered response code exceptions; response data formats other than JSON or containing garbled characters are considered response data format exceptions; API call taking more than 5 seconds is considered execution time exceptions; CPU utilization exceeding 90% is considered server resource utilization exceptions.
[0039] Based on the above rules, the test process dataset was filtered, and it was found that the test case "encryption using an incorrect SM2 private key" triggered response code 500, with the response data "encryption processing failed," and the server CPU utilization spiked to 95%; the test case "inputting tampered token data" triggered response code 401, with the response data "authentication failed." In-depth analysis of the anomalies revealed that: "encryption using an incorrect SM2 private key" caused the interface encryption processing logic to collapse, which was determined to be an encryption algorithm application vulnerability, with the trigger path being "test case → dynamic adaptation module → target interface encryption processing unit → abnormal server resource usage"; "inputting tampered token data" caused authentication failure, which was determined to be an authorization verification vulnerability, with the trigger path being "test case → dynamic adaptation module → target interface authorization verification unit → return authentication failure response." A vulnerability association graph was constructed, associating vulnerability types, triggering test cases, and interface call paths.
[0040] Step 5: Test Report Generation: The report generation module generates a standardized test report based on the test execution results and vulnerability analysis results. This report is exported as a PDF and provided to testers and developers.
[0041] like Figure 2 As shown, this embodiment also provides a fuzz testing verification system for cryptographic service interfaces, including a feature extraction module, a test case generation module, a dynamic adaptation module, a test execution module, an anomaly analysis module, and a report generation module.
[0042] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.
Claims
1. A fuzzing verification method for a cryptographic service interface, characterized in that: Includes the following steps: Step S1: Interface Feature Collection and Feature Library Construction: Collect feature information of the target cryptographic service interface; standardize the collected feature information and construct a cryptographic service interface feature library. The cryptographic service interface feature library supports dynamic updates and expansion of feature information. Step S2: Multi-dimensional mutation strategy design and test case generation: Based on the cryptographic service interface feature library, design a multi-dimensional fuzz testing mutation strategy; Based on the multi-dimensional fuzzing mutation strategy, combined with the normal value range and constraint rules of the password service interface parameters, an initial test case set is generated. The initial test case set is then deduplicated and prioritized to obtain the final fuzzing test case set. Step S3: Dynamic Adaptation and Test Execution: Set up the test execution environment, parse the communication protocol and data format of the target cryptographic service interface through the dynamic adaptation module, and realize the communication adaptation between the test cases and the target cryptographic service interface; according to the priority order of the test cases, call the target cryptographic service interface to perform fuzz testing in sequence, and collect the response code, response data, execution time and server running status information of the target cryptographic service interface in real time to form a test process dataset; Step S4: Anomaly Detection and Vulnerability Analysis: Based on preset anomaly judgment rules, the test process dataset is filtered to identify abnormal response data and abnormal operating states; Perform in-depth analysis of abnormal information to determine the vulnerability type, trace the test cases and call paths that triggered the vulnerability, and construct a vulnerability association map; Step S5: Test Report Generation: Generate a standardized test report based on the test execution results and vulnerability analysis results.
2. The fuzzing verification method for a cryptographic service interface according to claim 1, characterized in that: In step S1, the interface feature collection adopts a combination of static parsing and dynamic probing: static parsing of the development documents and definition files of the target cryptographic service interface to extract basic feature information; dynamic probing by sending preset normal requests to collect the actual response data and interaction process information of the target cryptographic service interface to supplement and improve the feature information. The characteristic information includes the target cryptographic service interface protocol type, request parameter structure, parameter constraints, supported encryption algorithm types, data transmission format, and call permission information.
3. The fuzzing verification method for a cryptographic service interface according to claim 1, characterized in that: In step S1, the matching degree between the target cryptographic service interface and the feature information of the standard cryptographic service interface in the cryptographic service interface feature library is calculated using the following formula: ； in, The degree of matching between the target cryptographic service interface and the feature information of standard cryptographic service interfaces in the cryptographic service interface feature library. For the first Weights of class feature information For the target cryptographic service interface The similarity between class feature information and corresponding feature information of standard cryptographic service interfaces. This represents the total number of feature information categories.
4. The fuzzing verification method for a cryptographic service interface according to claim 1, characterized in that: In step S2, the multi-dimensional fuzzing mutation strategy includes syntax-level mutation, semantic-level mutation, and encryption scenario-level mutation: Syntactic variations: The format, type, and length of the request parameters for the target cryptographic service interface are varied, including parameter type conversion errors, parameter length exceeding the limit, insertion of special characters, and missing parameters; Semantic variation: Based on the semantic constraints of the target cryptographic service interface parameters, generate parameter values that do not conform to business logic, including parameter values that are out of the valid range, related parameters that do not match, and abnormal business status. Encryption scenario-level variations: For the encryption algorithms supported by the target cryptographic service interface, generate test cases with abnormal encryption parameters, including encryption key errors, encryption algorithm mismatches, plaintext data format errors, and signature verification failure scenarios.
5. The fuzzing verification method for a cryptographic service interface according to claim 1, characterized in that: In step S2, the test case priority is calculated using the following formula: ； ； in, For the first Priority of each test case This represents the feature coverage for this use case. This represents the probability of triggering historical vulnerabilities. For use case complexity, , , These are the weighting coefficients.
6. The fuzzing verification method for a cryptographic service interface according to claim 1, characterized in that: In step S4, the anomaly determination rules include response code anomaly rules, response data format anomaly rules, execution time threshold rules, and server resource usage anomaly rules; the vulnerability types include input validation vulnerabilities, privilege bypass vulnerabilities, encryption algorithm application vulnerabilities, and resource leakage vulnerabilities.
7. The fuzzing verification method for a cryptographic service interface according to claim 1, characterized in that: In step S5, the test report includes a test overview, test coverage statistics, vulnerability details, risk level assessment, and remediation recommendations.
8. A fuzzing verification system for a cryptographic service interface, implementing the fuzzing verification method for a cryptographic service interface as described in any one of claims 1-7, characterized in that: include: Feature extraction module: used to collect feature information of the target cryptographic service interface, standardize the feature information, and build and maintain the cryptographic service interface feature library; Test case generation module: Connects to the feature extraction module, designs a multi-dimensional fuzzing mutation strategy based on the cryptographic service interface feature library, and generates and optimizes the fuzzing test case set; Dynamic Adaptation Module: Used to parse the communication protocol and data format of the target cryptographic service interface, realize the communication adaptation between test cases and the target cryptographic service interface, and support the conversion of multiple protocol types and data formats; Test execution module: Connects to the dynamic adaptation module, calls the target password service interface to perform fuzz testing according to priority, and collects various data in real time during the testing process; Anomaly Analysis Module: Connects to the test execution module, filters anomaly information based on preset anomaly judgment rules, performs in-depth analysis of the anomaly information, and locates the vulnerability type and trigger path; Report generation module: Connects to the anomaly analysis module and generates a standardized test report based on the test execution results and vulnerability analysis results. The report includes a test overview, coverage statistics, vulnerability details, and remediation suggestions.
9. A fuzz testing verification system for a cryptographic service interface according to claim 8, characterized in that: The test case generation module includes a strategy design unit, a test case generation unit, and a test case optimization unit; the strategy design unit designs multi-dimensional fuzzy testing mutation strategies at the syntax, semantic, and encryption scenario levels based on the cryptographic service interface feature library; The test case generation unit generates an initial test case set based on a multi-dimensional fuzz testing mutation strategy. The test case optimization unit performs deduplication and priority sorting on the initial test case set to improve testing efficiency.
10. A fuzz testing verification system for a cryptographic service interface according to claim 8, characterized in that: The anomaly analysis module includes an anomaly filtering unit, a vulnerability location unit, and a correlation analysis unit; the anomaly filtering unit filters anomaly information from the test process dataset based on preset rules; the vulnerability location unit determines the vulnerability type and the corresponding triggering test case; The correlation analysis unit constructs a correlation graph between vulnerabilities and target cryptographic service interface call paths and parameter variation types to assist in vulnerability tracing.