Web application server-side vulnerability testing method and device

Abstract

This application provides a method and apparatus for testing server-side vulnerabilities in web applications. It effectively uncovers potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing web application pages, extracting key elements, and deriving field matching rules based on server feedback, it generates semantic input samples that conform to the application logic. By comparing historical execution paths, it automatically discovers new paths and further explores potential deep-seated vulnerabilities through mutation operations. This method not only improves test coverage and depth but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of web applications and providing developers with more accurate and efficient vulnerability detection methods.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method and apparatus for testing vulnerabilities on the web application server side. Background Technology

[0002] With a large number of web applications built on interpreted server-side scripting languages ​​(such as PHP, Python, Node.js, etc.), the risk of server attacks is increasing globally. Although various security detection tools and techniques are available, such as static scanners (e.g., SonarQube, PHPCS) and black-box vulnerability scanning tools (e.g., ZAP, WFUZZ, etc.), these technologies still have inherent flaws, including high false positive rates, superficial detection dimensions, and inability to reproduce attacks.

[0003] A particularly prominent issue in server-side vulnerability detection is the combination of the following three attributes: First, highly complex input structures, including multi-layered nested JSON, combinations of POST parameters, and CSRF field validation in forms; second, the state dependency of web operations, meaning that an input often alters the database, session, and cache state, affecting subsequent executions; and third, vulnerability triggering requires complex conditions and exhibits "non-explicit" crash characteristics, such as SQL injection appearing unaffected but only manifesting as anomalies in echoes, database operations, and middleware interactions. Therefore, traditional fuzzing centered on "crash equals vulnerability" is ineffective in server-side web environments.

[0004] Especially PHP-based applications exhibit the following typical characteristics: interpreted line-by-line execution, dynamically typed variables, frequent unsafe function calls, diverse and unfiltered input paths, and reliance on runtime mechanisms such as sessions. In this structure, web vulnerabilities are often hidden in the handling of paths, permissions, template variables, or user-defined components, making them difficult to detect through conventional code analysis, and impossible to construct matching inputs through fuzzing.

[0005] As the world's most widely deployed server-side scripting language, PHP has been the subject of numerous major security incidents over the years, including SQL injection vulnerabilities in WordPress plugins, remote code execution (RCE) in Drupal, arbitrary file reading in Discuz, and unauthorized privilege escalation in PrestaShop. Due to the lightweight nature of the PHP runtime environment, low deployment costs, and the varying skill levels of programmers, security issues are constantly emerging, and traditional web scanning techniques are no longer sufficient for the needs of actual vulnerability discovery.

[0006] Currently, there are several recognized technical approaches in the industry, which can be divided into three main categories:

[0007] The first category consists of black-box input scanners, such as WFUZZ and ZAP. These tools use dictionary and fuzzy search methods to enumerate and test web page front-end forms, URL parameters, or common paths. Their advantage lies in their low barrier to entry, making them suitable for quickly identifying known variant attack methods (such as XSS and SQL injection templates). However, their disadvantages are particularly obvious: they lack understanding of application logic, backend paths, and input validation mechanisms; they cannot adaptively generate input based on feedback paths; and they cannot bypass CAPTCHAs / tokens / interface permissions. Their detection accuracy is far lower than the application execution level, and they lack replay capabilities.

[0008] The second category consists of static analysis scanners, such as PHPCS, Psalm, and SonarPHP. These static tools use AST analysis, regular expressions to identify unsafe functions, and output unfiltered variables, providing a high degree of visibility and clear code structure identification capabilities. However, these tools rely on complete source code and correct modeling strategies and are easily affected by coding style and complex conditional branches, leading to numerous false positives or difficulty in identifying runtime-related issues such as path concatenation, database injection, and multi-role privilege escalation. These issues can only be discovered during actual runtime.

[0009] The third category comprises preliminary attempts at feedback-driven fuzzy systems, such as WITHTHER and FuzzRequest. WITHTHER employs a path feedback mechanism, using HTML prompts during web target execution to determine if a potentially dangerous area has been entered, such as displaying error messages or POST field error messages. It also sets up specific analysis modules to attempt to identify SQL injection or command execution paths. Although WITHTHER is a representative feedback-driven web fuzzy framework, its analysis granularity is limited to the page interaction level; it cannot directly identify path construction and semantic processing in interpreter operations, nor does it employ a snapshot approach to address state dependency issues.

[0010] Overall, existing solutions mostly adopt the "input-mutation-response" approach, which can only probe shallow logic and cannot fully identify structural or context-dependent vulnerabilities such as command injection, file upload, and object injection. Furthermore, they lack the ability to identify and construct structures before testing (such as automatically identifying valid field names and generating test values ​​based on regular expressions), resulting in poor performance in terms of credibility, reproducibility, and testing depth. Summary of the Invention

[0011] To address the problems in the existing technology, this application provides a method and apparatus for testing vulnerabilities on the web application server side, which can achieve comprehensive vulnerability identification and improve the credibility, reproducibility and depth of vulnerability identification.

[0012] To solve at least one of the above problems, this application provides the following technical solution:

[0013] Firstly, this application provides a method for testing vulnerabilities on a web application server side, including:

[0014] Parse the web application page to obtain its key elements, including form structure, field names, and constraints; obtain the feedback from the server after receiving the input sample, and deduce the matching rules for the key fields based on the feedback; construct semantic input samples based on the key elements and the deduced key field matching rules.

[0015] The semantic input sample is injected into the server and executed; the execution path of the semantic input sample is obtained, and the execution path is compared with the historical execution path to determine whether the semantic input sample generates a new path during the execution process;

[0016] Perform semantic mutation operations on the abnormal fields in the semantic input sample that generates the new path to obtain the mutated semantic input sample; re-inject the mutated semantic input sample into the server for execution.

[0017] Monitor the execution of semantic input samples and determine whether the semantic input samples trigger server vulnerabilities.

[0018] Furthermore, the web application server-side vulnerability testing method also includes a snapshot recovery mechanism, which includes:

[0019] Before performing the test, take a state snapshot of the server environment, including memory, disk, database connections, PHP sessions, and session values.

[0020] After each test is executed, the server is restored to its initial state based on the snapshot, so that each test can start from a consistent environment.

[0021] Furthermore, the step of constructing semantic input samples based on key elements and derived key field matching rules includes:

[0022] Construct a structured request body based on known paths and constant values; generate field values ​​based on field types and constraint rules;

[0023] Based on the structured request body, the field values ​​of the key elements are populated using an existing specialized dictionary;

[0024] The input structure for field values ​​is determined based on the key field matching rules.

[0025] Furthermore, the step of injecting the semantic input sample into the server and performing the operation includes:

[0026] Semantic input samples are injected into the processing flow of the web server via a web request interface;

[0027] The semantic input sample is passed to the PHP container, and the PHP interpreter receives and processes the semantic input sample.

[0028] After receiving the input sample, the PHP interpreter processes it according to the PHP script logic on the server side and generates the corresponding server response.

[0029] Collect server response information, including feedback information for deriving matching rules and execution path information for analyzing abnormal fields.

[0030] Furthermore, the step of comparing the execution path with historical execution paths to determine whether a new path is generated during the execution of the semantic input sample includes:

[0031] Collect the control flow path during execution, compare the current execution path with the historical execution paths, and analyze whether the current path is being touched for the first time;

[0032] If the current path is different from the historical path, record the path as a new path and determine whether the path touches deep application logic or uncovered code areas.

[0033] Based on the discovery of the new pathway, the effectiveness of the test inputs will be further evaluated, and a decision will be made on whether to conduct further sample variation or testing based on the evaluation results.

[0034] Furthermore, the step of performing semantic mutation operations on the anomalous fields in the semantic input sample that generates the new path to obtain the mutated semantic input sample includes:

[0035] Based on the semantic input samples that generate new paths, we analyze which fields have an impact on the generation of new paths;

[0036] Perform semantic mutation operations on the fields that generate new paths. The semantic mutation operations include modifying field values, adding field content, trying boundary values, or trying limit values.

[0037] And / or adjust field values ​​using known mutation strategies, including dictionary replacement, random concatenation, structural perturbation, or nested deletion.

[0038] Furthermore, the step of monitoring the execution of semantic input samples and determining whether the semantic input samples trigger server vulnerabilities includes:

[0039] The monitoring server processes the input samples during execution and collects relevant data, including function call stacks, memory changes, and database queries.

[0040] Detect whether the PHP script responds abnormally to the input sample, including database errors, memory overflow, and unprocessed input;

[0041] Classify abnormal responses to determine whether they trigger server vulnerabilities;

[0042] If a vulnerability is detected, the semantic input sample is marked as a potential vulnerability and detailed execution information is recorded for subsequent vulnerability analysis and remediation.

[0043] Secondly, this application provides a web application server-side vulnerability testing device, comprising:

[0044] The sample generation module is used to parse the web application page to obtain its key elements, including form structure, field names and constraints; obtain the feedback made by the server after receiving the input sample, and deduce the matching rules of the key fields based on the feedback; and construct semantic input samples based on the key elements and the deduced key field matching rules.

[0045] The execution test module is used to inject the semantic input sample into the server and execute it; obtain the execution path of the semantic input sample, compare the execution path with the historical execution path, and determine whether the semantic input sample generates a new path during the execution process;

[0046] The in-depth exploration module is used to perform semantic mutation operations on anomalous fields in the semantic input samples that generate new paths, to obtain mutated semantic input samples; the mutated semantic input samples are then re-injected into the server for execution.

[0047] The vulnerability detection module monitors the execution of semantic input samples and determines whether the semantic input samples trigger server vulnerabilities.

[0048] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the Web application server-side vulnerability testing method.

[0049] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the Web application server-side vulnerability testing method.

[0050] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the Web application server-side vulnerability testing method.

[0051] As described above, this application provides a method and apparatus for testing vulnerabilities on the server side of a web application. It effectively uncovers potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing web application pages, extracting key elements, and deriving field matching rules based on server feedback, semantic input samples that conform to application logic can be generated. By comparing historical execution paths, new paths are automatically discovered, and further testing is conducted through mutation operations to explore potential deep-seated vulnerabilities. This method not only improves the coverage and depth of testing but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of web applications and providing developers with more accurate and efficient vulnerability detection methods. Attached Figure Description

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

[0053] Figure 1 This is one of the flowcharts illustrating the Web application server-side vulnerability testing method in this application embodiment;

[0054] Figure 2 This is the second flowchart illustrating the Web application server-side vulnerability testing method in this application embodiment;

[0055] Figure 3 This is a system architecture diagram of the Web application server-side vulnerability testing method in the embodiments of this application;

[0056] Figure 4 This is a structural diagram of the Web application server-side vulnerability testing device in the embodiments of this application;

[0057] Figure 5 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0058] Figure label:

[0059] Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0061] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0062] Terminology Explanation

[0063] Fuzzing is an automated, dynamic testing technique that involves continuously providing illegal, abnormal, or random input to a target system and observing its responses, behaviors, or outputs to uncover potential security vulnerabilities or logical flaws. Traditionally, fuzzing was primarily applied to low-level software (such as operating system drivers and protocol parsers), but in recent years it has gradually expanded to web systems, security APIs, and script interpreter layers.

[0064] Feedback-guided fuzzing refers to obtaining information such as the execution path, branches, and coverage nodes of the program under test and feeding it back to the fuzzer to guide the generation of subsequent inputs. This feedback can be static path coverage, dynamic function call stacks, or memory changes, significantly enhancing the tester's ability to delve into complex logic and improving testing efficiency.

[0065] Snapshot-based reinitialization is a system restoration method based on virtualization technology. It saves the complete state of the host system (including memory, disk, I / O, intermediate states, etc.) at the initial stage of testing. Subsequent test executions can then restore from this initial snapshot state, achieving accurate and repeatable execution and significantly reducing test startup time.

[0066] A bug oracle is a constructed vulnerability detection mechanism that typically uses instrumentation, embedded hooks, or behavioral pattern recognition methods to determine whether the program under test has been affected by input and triggered potential attack semantic paths. Unlike traditional systems based on "crash equals vulnerability," oracles can identify logical vulnerabilities (such as SQL injection, SSRF, etc.).

[0067] Coverage-guided approaches evaluate and guide the novelty of inputs by recording coverage metrics such as functions, basic blocks, and path nodes. This provides feedback control over the exploration depth and trigger point effectiveness of test inputs, and selectively retains input samples that can increase path coverage as seeds for the next round.

[0068] The core objective of this invention is:

[0069] • Establish a structured fuzz testing framework that supports the PHP interpreter;

[0070] • Use virtualization snapshot technology to solve the problems of environment inconsistency and state interference;

[0071] • Use feedback mechanisms to obtain test directions from specific functions, regular expressions, and paths;

[0072] • Build a vulnerability oracle engine to identify logical vulnerabilities (such as SQLi, upload vulnerabilities, and RCE);

[0073] • Evolve fuzz testing from “system-level random collision” to “semantic-level guided execution”.

[0074] This system does not rely on an external HTTP stack and embeds the test directly into the PHP executor container, effectively bypassing the constraints of the web server configuration; it adopts the FastCGI native channel input method, resulting in excellent performance; the test process can be continuously dispatched, and the results are accurate and controllable, truly filling the systemic technical gap in the field of dynamic discovery of server-side web vulnerabilities.

[0075] To address the problems existing in current technologies, this application provides a method and apparatus for testing server-side vulnerabilities in web applications. This method effectively uncovers potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing web application pages, extracting key elements, and deriving field matching rules based on server feedback, semantic input samples that conform to application logic can be generated. By comparing historical execution paths, new paths are automatically discovered, and further testing through mutation operations explores potential deep-seated vulnerabilities. This method not only improves test coverage and depth but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of web applications and providing developers with more accurate and efficient vulnerability detection methods.

[0076] To achieve comprehensive vulnerability identification and improve the reliability, reproducibility, and depth of vulnerability identification, this application provides an embodiment of a web application server-side vulnerability testing method. See [link to embodiment]. Figure 1The web application server-side vulnerability testing method specifically includes the following:

[0077] Step S101: Parse the web application page to obtain its key elements, including form structure, field names, and constraints; obtain the feedback from the server after receiving the input sample, and deduce the matching rules for the key fields based on the feedback; construct a semantic input sample based on the key elements and the deduced key field matching rules.

[0078] Optionally, this embodiment uses HTML parsing and structure matching to extract form fields, tokens, CSRF tags, etc. from the target application response page. It automatically constructs a structured request body based on known paths and constant values ​​(such as automatically filling in username / password / captcha fields in a POST / login request). It uses a regular expression reverse generator to reverse-engineer field types and value range constraints, effectively improving the legality of the sample structure and providing semantically complete seeds for subsequent fuzzy testing input.

[0079] During this stage, the system automatically crawls the target page, parses the HTML DOM, and analyzes its... <form>The form structure and field names are defined, and the submission results are simulated to obtain the server's feedback logic (such as the username field must exist, field values ​​must be at least 5 characters, etc.). Then, the key field matching rules are derived by reverse deduction through regular expressions, and the field values ​​are filled and generated in combination with the existing dedicated dictionary to ensure that the fuzz test seed sample has an effective input structure and high logical rationality.

[0080] Optionally, this embodiment provides a specific method for parsing a web application page to obtain its key elements:

[0081] 1. Parse web application pages:

[0082] The system first loads the target web application page, which can be an HTML page, a dynamically generated form, API documentation, etc. During the loading process, the system scans the page content and extracts all form elements and fields related to user input.

[0083] 2. Extract the form structure:

[0084] Form structure refers to the way forms are organized and the order of fields in a web page, typically including tags and various input controls (such as...). <input> , <select>、< / select> <textarea> (etc.). The system will extract the type, order, name, and function of each form field. For example, username, password, checkboxes, and file upload fields. It will also identify multi-level forms or dynamically generated form fields, such as fields whose display or hiding is controlled by JavaScript.< / textarea>

[0085] 3. Extract field names:

[0086] The system will parse out the field name (name attribute) and ID of each form field; these field names are identifiers for the input data. For example, if the page has... <input name＝"username"type＝"text"> and <input name＝"password"type＝"password"> The system will extract the field names: username and password.

[0087] 4. Extract key fields:

[0088] The system can determine which fields are critical based on form and request structure analysis (such as form structure analysis and field name analysis), business logic analysis (such as business function analysis and the correlation between fields and system functions), front-end validation and constraint rules (such as front-end validation rules), server feedback and runtime logic (such as server feedback and path analysis), and vulnerability history and security research.

[0089] 5. Constraints on the analysis field:

[0090] The system obtains field constraints by analyzing HTML tag attributes (such as required, maxlength, pattern, type, etc.) and potentially embedded front-end validation scripts (such as JavaScript validation). Specifically, data type constraints include: type="email" means the field must conform to an email format, and type="number" means the field should be a number. Length constraints include: maxlength="20" means the input length of the field is limited to 20 characters, and minlength="8" means the password field must have at least 8 characters. Required fields include: required means the field cannot be empty. Regular expression constraints: through the pattern attribute, the field may need to meet specific regular expression formats (such as phone number, email address, etc.).

[0091] 6. Extract possible dynamic validation rules:

[0092] The system also extracts JavaScript validation rules, such as whether dynamically validated field inputs are valid and whether input values ​​meet format requirements (e.g., username length, password complexity, email format). If the page contains dynamic form fields (e.g., fields controlled by JS for showing / hiding), the system parses the relevant JavaScript code to obtain the field dependencies and constraints.

[0093] 7. Construct metadata for key elements:

[0094] The system constructs a metadata structure from the extracted form structure, field names, and constraints. This structure describes information such as the type, constraints, validation rules, and possible value range for each field.

[0095] Ultimately, the system will output a set of field names, field types, field constraints, and field validation rules, providing a foundation for subsequent input sample generation (such as the construction of semantic input samples).

[0096] Optionally, this embodiment provides a specific method for constructing semantic input samples:

[0097] 1. Obtain server feedback logic and deduce key field matching rules.

[0098] The system submits semantic input samples to the server for processing and receives feedback responses (such as error messages, HTTP status codes, database verifications, etc.). Based on the server's feedback (e.g., incorrect username or password, empty fields, etc.), field matching rules are derived. For example: if a field is empty, it is deduced that the field is required; if the server indicates an incorrect password length, the minimum length constraint for the password field is deduced; if the format is incorrect, it is deduced that the field should follow a specific format (such as email format). In the initial test, since there is no feedback, the generation of matching rules can rely on automatic derivation and static analysis.

[0099] 2. Construct a structured request body

[0100] After obtaining the field names, form structure, and constraints, the system uses known paths and constant values ​​as the basis for request data to construct a structured request body that meets the requirements of the web application. This request body defines the data format, order, and other necessary structural information of the fields. For example, for a login form, the structured request body might include the fields username and password, ensuring that each field has an appropriate type and format: {"username":"user123","password":"P@ssw0rd"}. At this point, the field values ​​may be filled according to static analysis rules, but the structure itself does not contain all the business logic constraints; it is only a preliminary request framework.

[0101] 3. Construct semantic input samples

[0102] Based on the structured request body and combined with the extracted field names and derived matching rules, the system begins to construct semantic input samples: It generates compliant input samples according to the type and constraints of the target field (such as maximum length, minimum length, and required fields). For text fields (such as usernames), the system generates appropriately long and valid text values ​​(e.g., user123); for password fields, it generates passwords that meet security requirements (e.g., P@ssw0rd); and for email fields, it generates data conforming to email format (e.g., user@example.com). Dynamic data validation rules further ensure that the samples comply with front-end validation rules, such as ensuring that phone numbers conform to regular expression validation. The semantic input samples not only conform to the data structure of the web application but also follow business logic and validation rules, enabling effective interaction with the web application.

[0103] Optionally, this embodiment also provides an environment initialization and snapshot process before testing:

[0104] Before testing, the system will automatically load the components required by the target application, including the PHP runtime container, MySQL / PostgreSQL database nodes, web framework script files, etc., and perform the relevant configuration population process to ensure that the target test path is reachable.

[0105] Once the environment is ready, a snapshot of the current state is taken based on virtualization images such as NYX or KVM, including memory, disk, and session values, to ensure state consistency. Even if subsequent executions destroy the original state, it can be restored immediately, laying the foundation for ensuring independent execution in the future.

[0106] Once the test is complete, the snapshot recovery mechanism immediately intervenes, replacing the changes made to the Web state by the aforementioned inputs and reverting the container state to the initial snapshot. This state restoration includes database rollback, session destruction, file cache cleanup, and PHP shared memory reset, technically ensuring the "precise reproducibility" of the test results and the ability to construct training multiple rounds. It also makes the test rooms completely independent, enabling concurrent fuzz testing.

[0107] In other words, based on high-performance virtual snapshot technology such as NYX, the system records the complete state of the target execution container during initialization (including disk, database connection, PHP session state, etc.), and restores the state immediately after each round of input execution, ensuring that the test is uncontaminated and the results are reproducible, providing a foundation for subsequent vulnerability confirmation and secondary debugging.

[0108] Step S102: Inject the semantic input sample into the server and execute it; obtain the execution path of the semantic input sample, and compare the execution path with the historical execution path to determine whether the semantic input sample generates a new path during the execution process.

[0109] Optionally, this embodiment also provides a specific method for performing the test:

[0110] During the test input phase, the mutated input is injected into the PHP container via the FastCGI interface. This interface skips the traditional web server stacking process (such as path rewriting and static rule transformation in Nginx), reducing execution interference. Each input is directly passed to the core control script, where an automatic URL path analyzer locates the execution trunk and invokes the corresponding module or function, enabling "precise penetration" of the test.

[0111] In other words, the system directly accesses the FastCGI protocol port to convert fuzzy-generated input into a unified FastCGI request that the PHP interpreter can recognize. This bypasses the caching / protection rules / rewrite conditions of Web layers such as Apache / Nginx, ensuring that every input can be accurately mapped to a PHP file function. At the same time, it improves execution efficiency and interrupt control capabilities, achieving a highly efficient and integrated fuzzy execution flow.

[0112] Optionally, this embodiment also provides a specific method for feedback collection:

[0113] In the preceding steps, the system has already generated semantic input samples based on field types, constraints, and key field matching rules. Next, the system submits these samples to the target web application server via a web request. By submitting the request, the system triggers the web application's business logic or validation process; the server then processes the request and returns a response.

[0114] The system monitors the number of hits of basic blocks, conditional branches, and abnormal branches through the interpreter extension module, compares them with the historical execution path set, and determines whether a new path hit has occurred. If there is an extension, it means that the input is valuable, and it is retained in the scheduling model and can enter multiple rounds of synthetic mutation to realize the test evolution path of "coverage-extraction-enhancement".

[0115] The oracle system uses hooks to cover core functions in PHP that frequently cause vulnerabilities and observes whether these functions receive user input and execute abnormal logic flows. For example, if an invalid SQL statement causes a syntax error, or if an uploaded file is written from the temporary area to an unexpected directory, the system determines that the test input has a security bias, considers it as having hit the actual vulnerability logic, and stores it in a high-priority record pool for subsequent auditing and analysis.

[0116] Specifically:

[0117] 1. Logic for obtaining server feedback

[0118] Server feedback logic refers to the response returned by the web server after executing the received input sample. Feedback may include: HTTP status codes: for example, 200 OK indicates a successful request, 400 Bad Request indicates invalid request parameters, and 404 Not Found indicates the requested resource does not exist; error messages: for example, duplicate username, incorrect password format, or field values ​​not meeting requirements; success / failure page responses: for example, returning the homepage after successful login or returning an error page when login fails; redirection: the server may return a redirect response, instructing the client to jump to another page.

[0119] Feedback Collection Method: After receiving a response from the server, the system parses the feedback content and extracts key information. For web page responses, the system extracts the HTML content and analyzes it for error messages or verification information. For API responses, the system parses the returned JSON / XML data and extracts fields and their values. For example, for a login form, the server might return a 400 Bad Request with the error message "Username already exists." The system will use this error message as feedback data to further analyze whether the field needs modification.

[0120] 2. Obtain execution path and feedback path information

[0121] The system monitors the execution path of input samples using coverage tracking tools such as pcov and xdebug. These tools record whether each function, conditional branch, and basic block is triggered during program execution. The system obtains information about the current execution path, records the path, and compares it with previous historical paths to determine whether the current input sample has triggered a new path. Historical paths are derived from previous input samples, while new paths refer to previously uncovered paths, indicating that the input sample has touched upon new functionality or logic in the web application. If, after execution, the input sample triggers an unaccessed function or an unexecuted code branch in the web application, the system considers the input sample to have triggered a new path.

[0122] 3. Compare with historical execution paths to determine if a new path has been generated.

[0123] The system compares the current path with historical paths to determine if any new paths have been accessed. Paths are based on the control flow during program execution and can include conditional statements, loops, function calls, etc.

[0124] Criteria for determining a new path:

[0125] If an input sample triggers a code path in the web application that was not previously covered (e.g., a specific error handling branch, or an uncommon user interaction path), the input sample is considered to have touched a new path.

[0126] If the input sample does not trigger a new path, the sample will be considered a known path and will not enter the depth test.

[0127] 4. Collection of abnormal branches

[0128] In addition to path coverage, the system also analyzes anomalous branches, i.e., whether the input sample led to errors or abnormal behavior. Common anomalies include:

[0129] SQL errors: For example, database errors caused by SQL injection attacks.

[0130] Permission verification error: For example, when an invalid credential is entered, the system may return 401 Unauthorized or 403 Forbidden.

[0131] Input validation error: For example, if a field is not formatted correctly, the server may return a specific error message, such as "Incorrect email address format".

[0132] If a certain field causes an abnormal branch to be triggered, the system will record the branch and mark it as a potential vulnerability or a path to be further analyzed.

[0133] 5. Collect feedback and perform mutation operations.

[0134] After collecting feedback from the server, especially after triggering new paths or abnormal branches, the system will backtrack and analyze to identify the key fields that generated the new path. These fields will be further modified to explore deeper logical paths or potential vulnerabilities. For example, if a change in the username field leads to a new path being reached, the system may fine-tune the username field to generate different usernames to continue digging deeper into that path, or adjust the password field to generate values ​​that conform to different rules to see if other uncovered paths can be reached.

[0135] Step S103: Perform semantic mutation operation on the abnormal fields in the semantic input sample that generates the new path to obtain the mutated semantic input sample; re-inject the mutated semantic input sample into the server for execution.

[0136] Optionally, this embodiment also provides a method for constructing mutated semantic input samples:

[0137] For different field types, such as integer, boolean, email, hash, and JSON fields, custom semantic labels are used for classification and definition. Combined with fuzzy strategies (dictionary replacement, random concatenation, structural perturbation, nested deletion, etc.) and feedback scores, the most meaningful subsequent test inputs are dynamically generated to ensure that the samples are "reasonable in style, controllable in value range, and comprehensive in boundaries".

[0138] Specifically, server feedback (such as error messages, path overriding information, etc.) can guide the depth and direction of mutations. For example, if mutation of the username field triggers a database error or permission error, the system can further mutate the password field to expose deeper vulnerabilities such as privilege escalation or SQL injection; if the file upload field causes path resolution errors or security warnings, the system can further increase the file size or try malicious file formats (such as files with executable code) for in-depth testing.

[0139] Step S104: Monitor the execution of the semantic input sample and determine whether the semantic input sample has triggered a vulnerability in the server.

[0140] Optionally, in this embodiment, since web server-side vulnerabilities often manifest as logical deviations or changes in specific data processing flows, and do not necessarily cause the interpreter to "crash" or the system to collapse, signals such as SIGSEGV, illegal access, and memory errors in traditional fuzzing cannot be used as vulnerability detection standards. Therefore, this invention introduces a "vulnerability oracle engine".

[0141] Its working principle is as follows: In the PHP interpreter execution layer, pre-defined execution path monitoring logic for key functions is used. When functions such as `mysqli_query()`, `unserialize()`, `eval()`, `include()`, and `move_uploaded_file()` are executed, the system records the parameter content, context input source, return value, and error message. When these functions are confirmed to receive controllable external fuzzy input parameters and trigger a certain degree of abnormal behavior (such as syntax errors, undefined functions, file operation failures, etc.), it is considered a "hit oracle." This process, combined with traditional trace analysis, can improve the actual vulnerability discovery rate, and is particularly suitable for scenarios without page feedback.

[0142] The vulnerability oracle engine primarily determines whether input triggers potential vulnerabilities from the following perspectives: Error triggering: such as SQL exceptions, undefined functions. Structural collapse: such as disordered deserialized object structure. Command execution anomalies: such as incorrectly formatted system commands that are partially executed. Sensitive path modification: such as including fuzzy path constructs. File upload escape: monitoring uploaded files to bypass extension checks.

[0143] This module moves the oracle mechanism from the page shell result feedback to the internal logic flow of the interpreter, greatly enhancing the ability to identify high-order vulnerabilities.

[0144] By integrating PHP-specific code coverage plugins such as pcov and xdebug, the system can accurately record: the number of functions called; the number of covered statements within each function; and whether the path is the first time the path has been traversed after fuzzy input.

[0145] The system of this invention automatically generates coverage data for each path after executing the input sample and compares it with historical data. If a new control flow path is hit, the input is retained and the system proceeds to the next round of enhanced mutation, guiding the fuzz tester closer to the deeper logic.

[0146] In addition, the system sets up a sustained feedback loop by adding dynamic feedback variables (such as dynamic keys extracted from field names in logical judgment statements), enabling in-depth exploration of critical paths (such as login process and user center controller).

[0147] Key points of this invention:

[0148] This invention proposes a novel Web vulnerability discovery system that integrates "automatic maintenance of fuzzy input + precise backtracking of environment snapshots + feedback path-driven exploration + judgment of objective function hit conditions," possessing the following irreplaceable breakthrough features:

[0149] • Using runtime environment snapshots as the core mechanism, virtual restoration technology is applied to ensure consistency of input test states, reducing false alarms and unreproducible scenarios.

[0150] The structured semantics-driven input engine can infer field names, key value ranges, and regular expression constraints, going beyond ordinary heuristic string concatenation to achieve input construction logic aligned with the actual framework model.

[0151] The right-wing programming model's coverage feedback mechanism is highly integrated with the PHP interpreter, enabling basic block-level path awareness and automatically capturing the increase rate of key control branches.

[0152] The vulnerability oracle mechanism is embedded in the execution engine. Instead of relying on front-end echoes, it directly identifies whether the interpreter layer has triggered code path misuse or sensitive behavior hits, establishing a new paradigm for vulnerability judgment and modeling.

[0153] • Full sandbox archiving capability, allowing the path / output / state of each fuzzy input to be reproduced, facilitating integration into SaaS platforms, vulnerability remediation and retesting platforms, GitHooks semantic security automated scanning links, etc.

[0154] The innovative aspects protected by this invention patent include not only the structure of each functional module, but also the event flow coordination between modules, the sequential conditions of working logic, the interface and FastCGI interaction method, the path feedback calculation standard, and the combination of vulnerability condition triggering logic and judgment instructions.

[0155] As described above, the Web application server-side vulnerability testing method provided in this application can effectively uncover potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing Web application pages, extracting key elements, and deriving field matching rules based on server feedback, semantic input samples that conform to application logic can be generated. By comparing historical execution paths, new paths are automatically discovered, and further testing is conducted through mutation operations to explore potential deep-seated vulnerabilities. This method not only improves the coverage and depth of testing but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in Web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of Web applications and providing developers with more accurate and efficient vulnerability detection methods.

[0156] This invention proposes a technical solution for the field of Web security testing that combines high precision, automation, and the ability to pinpoint reproducible scenarios. Based on a structured fuzzy generation and state preservation mechanism, it is the first to unify the three major bottlenecks in interpreted script vulnerability testing: input structure complexity, uncontrollable runtime state, and imperceptible vulnerabilities.

[0157] By introducing mechanisms such as virtual snapshots, feedback collection, parameter structure reverse analysis, and dynamic coverage scoring, the system achieves wider path detection, lower false positives, faster convergence, and stronger external robustness, making it particularly suitable for the current environment where modern web services have strong dynamic expression capabilities, complex deployments, and high security requirements. It also possesses backup capabilities for various industry scenarios, including internal API testing, PHP plugin analysis, software supply chain auditing, and CICD security testing.

[0158] In the future, the framework of this system will be expanded to support more interpreted languages, including platforms such as Python, Flask, and NodeJS. It can also be combined with model engines such as OpenAI to further enhance the ability to collect dynamic field semantics, moving towards the goal of building an automated "semantic-safe AI Fuzz network", which is of great strategic significance to the security of national basic platforms.

[0159] Optional, see reference Figure 2 As shown in the figure, this embodiment also provides a system architecture diagram for web application server-side vulnerability testing guided by a snapshot recovery and feedback mechanism.

[0160] This system uses a "PHP container-based fuzzy execution platform" as its core architecture. It modularly divides the key functions required throughout the testing lifecycle. These seemingly discrete components form a highly collaborative, sustainably evolving, and highly targeted web server security testing ecosystem. The overall system structure is divided into seven modules, each with independent responsibilities. They work closely together through data flow and control flow to form a closed-loop dynamic vulnerability detection main architecture.

[0161] The first module is the input generator, which automatically extracts suitable input field names and structural styles from web output features such as HTML page responses and JSON structures. It then combines these with static HTML tags and data validation rules from dynamic front-end JavaScript to automatically extract and initialize the input seed set. These inputs become the starting point for the mutation logic, laying the semantic understanding foundation for high-quality fuzzy generation.

[0162] Next is the intelligent mutation engine, which performs "intelligent" optimization on the seed input samples based on semantic information obtained from the input generator. This means it no longer uses the completely discrete, random byte-flipping method of traditional fuzzing, but instead considers the business semantics and constraints of each field, selecting different mutation strategies based on the field's data type (such as integer, boolean, path, file upload, email, etc.). For example, it uses a regular expression generator to extract rules from `preg_match` to generate values ​​that meet the requirements, or it uses dictionary and boundary mutation methods to construct high-hit-rate inputs. This significantly improves the ability of fuzzing to trigger deep logical paths.

[0163] The mutated input will be submitted to the request scheduling hub module, which acts as the "data channel hub" in the entire test chain. It is responsible for converting the fuzzy input constructed by the high-level layer into the FastCGI request input format that can be recognized by the low-level PHP, and delivering it to the target script entry point accurately and quickly. This bypasses the web server cache, scheduling rules, and CAPTCHA mechanism, shortens the feedback loop time, and enhances execution controllability.

[0164] Before being sent to the PHP container, fuzzy requests are restored to their predetermined initial execution state by the snapshot restoration engine. This module, based on underlying virtualization snapshot technology, can capture an image of the entire system immediately after system initialization, including details such as the web framework port listening state, database state, file system cache state, user sessions, and cookies. This ensures that every subsequent test starts from a clean and consistent state, completely resolving the problem of test mutation pollution, while also guaranteeing the replayability of vulnerability verification and the accuracy of vulnerability location and tracing.

[0165] During the execution of the PHP script, the coverage identification module continuously tracks path hits in the interpreter (obtaining Opcode-level paths, function hits, statement branches, etc. through native plugins such as pcov). This mechanism is used to determine whether the current input touches a new path, a new control block, or an exception handling chain. Other coverage guidance technologies work in conjunction with this module to form a feedback channel, which can drive the fuzzer to continuously progress deeper into the logic.

[0166] Meanwhile, during the first or subsequent rounds of program execution, the vulnerability oracle subsystem injects itself into the parser function entry and return points. It monitors the source of parameters, change paths, and potential abnormal behavior at critical points such as `eval`, `mysqli_query`, `include`, `unserialize`, and `move_uploaded_file`. If it detects that the input affects control flow, execution behavior, or results in an abnormal return, it marks the current input as a potential vulnerability path instance and reports detailed information to the log and alerting module.

[0167] Finally, all test records, path changes, and trigger results will be stored in the data archiving and alarm module. This module not only provides lightweight data management capabilities at the SQLite level, but also supports pushing results in real time in log format. It can be integrated into the CI / CD system to automatically mark specific version failure mechanisms and defect instances.

[0168] In summary, the above architecture forms a closed loop with "semantics → mutation → invocation → execution → feedback", creating a web server-side fuzzing system framework with consistent operating status, deeply integrated feedback paths, and accurate vulnerability judgment. This provides a highly versatile and adaptable technical foundation for automated vulnerability discovery.

[0169] Optional, see reference Figure 3 As shown, this embodiment also provides a fuzz test execution workflow diagram for a Web application server-side vulnerability testing system guided by a snapshot recovery and feedback mechanism:

[0170] Unlike the static functional module division presented in the system architecture diagram, the system workflow diagram describes the actual execution order of each step in the dynamic fuzzing lifecycle and the data flow and control logic interaction between the corresponding logics, highlighting the fuzzing execution characteristics and environmental control capabilities.

[0171] The entire fuzzing loop begins with Step 1: Environment Initialization and Snapshot Baseline Establishment. The system automatically loads the components required by the target application, including the PHP runtime container, MySQL / PostgreSQL database nodes, and web framework script files, while simultaneously performing relevant configuration population processes to ensure the target test path is reachable. Once the environment is ready, a snapshot of the current state is taken based on virtualization images such as NYX or KVM, including memory, disk, and session values, to ensure state consistency. Even if subsequent executions corrupt the original state, it can be immediately restored, laying the foundation for ensuring independent execution in subsequent processes.

[0172] Next, we move on to Step 2: Semantic Input Sample Generation. The system automatically crawls the target page, parses the HTML DOM, analyzes the form structure and field names, simulates submission results, and obtains the server's feedback logic (such as the username field must exist, field values ​​must be at least 5 characters, etc.). Then, it reverse-engineers the key field matching rules through regular expressions, and combines them with an existing dedicated dictionary to fill in and generate field values, ensuring that the fuzzy test seed samples have a valid input structure and high logical rationality.

[0173] In Step 3: Execution of Test Input, the mutated input is injected into the PHP container via the FastCGI interface. This interface skips the traditional web server stacking process (such as path rewriting and static rule transformation in Nginx), reducing execution interference. Each input is directly passed to the core control script, which uses an automatic URL path analyzer to locate the execution trunk and invoke the corresponding module or function, enabling the test to "precisely penetrate".

[0174] Step 4: State feedback collection is the most information-dense part of fuzz testing. The system monitors the number of hits of basic blocks, conditional branches, and abnormal branches through the interpreter extension module, compares it with the historical execution path set, and determines whether a new path hit has occurred. If there is an extension, it means that the input is valuable, and it is retained in the scheduling model and can enter multiple rounds of synthetic mutation to realize the test evolution path of "coverage-extraction-reinforcement".

[0175] Next, we proceed to Step 5: Oracle Trigger Logic. The oracle system uses hooks to cover core functions in PHP that commonly cause vulnerabilities and observes whether they receive user input and execute abnormal logic flows. For example, if an invalid SQL input causes a syntax error, or if an uploaded file is written from the temporary area to an unexpected directory, it is determined that the test input has a security deviation, is considered to have hit the actual vulnerability logic, and is stored in a high-priority record pool for subsequent audit analysis.

[0176] Finally, Step 6: The snapshot recovery mechanism will immediately intervene, replacing the effects of the aforementioned inputs on the Web state, and reverting the container state to the initial snapshot. This state restoration includes database rollback, session destruction, file cache cleanup, and PHP shared memory reset, technically ensuring the "precise reproducibility" of test results and the ability to construct training in multiple rounds. It also makes the test rooms completely independent, enabling concurrent fuzz testing.

[0177] In summary, this workflow not only ensures the automatic construction of necessary data structures and consistent states, but also guarantees a closed-loop mechanism for path feedback, vulnerability feedback, and result evidence storage. It establishes a fully automated, secure, reliable, low-interference, and high-hit-rate web server-side vulnerability testing process that can be widely adapted to DevSecOps, threat intelligence, intelligent auditing, and large-scale CMS plugin monitoring platforms.

[0178] To achieve comprehensive vulnerability identification and improve the reliability, reproducibility, and depth of vulnerability identification, this application provides an embodiment of a Web application server-side vulnerability testing apparatus for implementing all or part of the aforementioned Web application server-side vulnerability testing method. See [link to relevant documentation]. Figure 4 The web application server-side vulnerability testing device specifically includes the following components:

[0179] The sample generation module 10 is used to parse the web application page to obtain its key elements, which include form structure, field names and constraints; obtain the feedback made by the server after receiving the input sample, and deduce the matching rules of the key fields based on the feedback; and construct semantic input samples based on the key elements and the deduced key field matching rules.

[0180] The execution test module 20 is used to inject the semantic input sample into the server and execute it; obtain the execution path of the semantic input sample, compare the execution path with the historical execution path, and determine whether the semantic input sample generates a new path during the execution process;

[0181] The in-depth exploration module 30 is used to perform semantic mutation operations on the abnormal fields in the semantic input sample that generates the new path, and obtain the mutated semantic input sample; the mutated semantic input sample is then re-injected into the server for execution.

[0182] The vulnerability detection module 40 monitors the execution of semantic input samples and determines whether the semantic input samples trigger vulnerabilities in the server.

[0183] As described above, the Web application server-side vulnerability testing device provided in this application embodiment can effectively uncover potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing Web application pages, extracting key elements, and deriving field matching rules based on server feedback, it can generate semantic input samples that conform to application logic. By comparing historical execution paths, it automatically discovers new paths and further explores potential deep-level vulnerabilities through mutation operations. This method not only improves the coverage and depth of testing but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in Web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of Web applications and providing developers with more accurate and efficient vulnerability detection methods.

[0184] From a hardware perspective, in order to achieve comprehensive vulnerability identification and improve the credibility, reproducibility, and testing depth of vulnerability identification, this application provides an embodiment of an electronic device for implementing all or part of the Web application server-side vulnerability testing method. The electronic device specifically includes the following components:

[0185] The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to realize information transmission between the Web application server-side vulnerability testing device and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the Web application server-side vulnerability testing method and the Web application server-side vulnerability testing device in the embodiments, the content of which is incorporated herein, and repeated details will not be described again.

[0186] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0187] In practical applications, parts of the web application server-side vulnerability testing method can be executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0188] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0189] Figure 5 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 5 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 5 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0190] In one embodiment, the web application server-side vulnerability testing method functionality can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls:

[0191] Step S101: Parse the web application page to obtain its key elements, including form structure, field names and constraints; obtain the feedback made by the server after receiving the input sample, and deduce the matching rules of the key fields based on the feedback; construct semantic input samples based on the key elements and the deduced key field matching rules.

[0192] Step S102: Inject the semantic input sample into the server and execute it; obtain the execution path of the semantic input sample, and compare the execution path with the historical execution path to determine whether the semantic input sample generates a new path during the execution process;

[0193] Step S103: Perform semantic mutation operation on the abnormal fields in the semantic input sample that generates the new path to obtain the mutated semantic input sample; re-inject the mutated semantic input sample into the server for execution.

[0194] Step S104: Monitor the execution of the semantic input sample and determine whether the semantic input sample has triggered a vulnerability in the server.

[0195] As described above, the electronic device provided in this application embodiment can effectively uncover potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing web application pages, extracting key elements, and deriving field matching rules based on server feedback, it can generate semantic input samples that conform to application logic. By comparing historical execution paths, new paths are automatically discovered, and further in-depth testing through mutation operations is conducted to explore potential deep-seated vulnerabilities. This method not only improves the coverage and depth of testing but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of web applications and providing developers with more accurate and efficient vulnerability detection methods.

[0196] In another embodiment, the Web application server vulnerability testing device can be configured separately from the central processing unit 9100. For example, the Web application server vulnerability testing device can be configured as a chip connected to the central processing unit 9100, and the Web application server vulnerability testing method function can be implemented through the control of the central processing unit.

[0197] like Figure 5 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 5 All components shown; in addition, the electronic device 9600 may also include Figure 5 For components not shown, please refer to existing technologies.

[0198] like Figure 5 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0199] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0200] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0201] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0202] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device's communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0203] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0204] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored audio via the speaker 9131.

[0205] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the Web application server-side vulnerability testing method with a server or client as the execution subject in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the Web application server-side vulnerability testing method with a server or client as the execution subject in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0206] Step S101: Parse the web application page to obtain its key elements, including form structure, field names and constraints; obtain the feedback made by the server after receiving the input sample, and deduce the matching rules of the key fields based on the feedback; construct semantic input samples based on the key elements and the deduced key field matching rules.

[0207] Step S102: Inject the semantic input sample into the server and execute it; obtain the execution path of the semantic input sample, and compare the execution path with the historical execution path to determine whether the semantic input sample generates a new path during the execution process;

[0208] Step S103: Perform semantic mutation operation on the abnormal fields in the semantic input sample that generates the new path to obtain the mutated semantic input sample; re-inject the mutated semantic input sample into the server for execution.

[0209] Step S104: Monitor the execution of the semantic input sample and determine whether the semantic input sample has triggered a vulnerability in the server.

[0210] As described above, the computer-readable storage medium provided in this application embodiment can effectively uncover potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing web application pages, extracting key elements, and deriving field matching rules based on server feedback, semantic input samples that conform to application logic can be generated. By comparing historical execution paths, new paths are automatically discovered, and further in-depth testing through mutation operations is conducted to explore potential deep-seated vulnerabilities. This method not only improves the coverage and depth of testing but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of web applications and providing developers with more accurate and efficient vulnerability detection methods.

[0211] Embodiments of this application also provide a computer program product capable of implementing all steps of the Web application server-side vulnerability testing method with the execution subject being a server or client in the above embodiments. When the computer program / instructions are executed by a processor, they implement the steps of the Web application server-side vulnerability testing method. For example, the computer program / instructions implement the following steps:

[0212] Step S101: Parse the web application page to obtain its key elements, including form structure, field names and constraints; obtain the feedback made by the server after receiving the input sample, and deduce the matching rules of the key fields based on the feedback; construct semantic input samples based on the key elements and the deduced key field matching rules.

[0213] Step S102: Inject the semantic input sample into the server and execute it; obtain the execution path of the semantic input sample, and compare the execution path with the historical execution path to determine whether the semantic input sample generates a new path during the execution process;

[0214] Step S103: Perform semantic mutation operation on the abnormal fields in the semantic input sample that generates the new path to obtain the mutated semantic input sample; re-inject the mutated semantic input sample into the server for execution.

[0215] Step S104: Monitor the execution of the semantic input sample and determine whether the semantic input sample has triggered a vulnerability in the server.

[0216] As described above, the computer program product provided in this application can effectively uncover potential vulnerabilities through intelligent analysis and feedback mechanisms. By parsing web application pages, extracting key elements, and deriving field matching rules based on server feedback, semantic input samples that conform to application logic can be generated. By comparing historical execution paths, new paths are automatically discovered, and further in-depth testing through mutation operations is conducted to explore potential deep-seated vulnerabilities. This method not only improves the coverage and depth of testing but also dynamically optimizes test samples based on actual feedback, avoiding the blindness and inefficiency of traditional testing methods. This solution can effectively identify various security vulnerabilities in web applications, such as SQL injection and XSS attacks, enhancing the security and reliability of web applications and providing developers with more accurate and efficient vulnerability detection methods.

[0217] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0218] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0219] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0220] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0221] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.< / form>

Claims

1. A method for testing vulnerabilities on the server side of a web application, characterized in that, The method includes: Parse the web application page to obtain its key elements, including form structure, field names, and constraints; obtain the feedback from the server after receiving the input sample, and deduce the matching rules for the key fields based on the feedback; construct semantic input samples based on the key elements and the deduced key field matching rules. The semantic input sample is injected into the server and executed; the execution path of the semantic input sample is obtained, and the execution path is compared with the historical execution path to determine whether the semantic input sample generates a new path during the execution process; Perform semantic mutation operations on the abnormal fields in the semantic input sample that generates the new path to obtain the mutated semantic input sample; re-inject the mutated semantic input sample into the server for execution. The method monitors and determines whether the semantic input sample triggers a server vulnerability. Specifically, this monitoring and determination involves: monitoring the execution path of a preset key function in the PHP interpreter execution layer; and determining that the key function has triggered a server vulnerability when it receives controllable parameters from the semantic input sample or the mutated semantic input sample and triggers abnormal behavior. The method also includes a snapshot recovery mechanism, which involves: taking a snapshot of the server environment before each test, including snapshot content such as memory, disk, database connections, PHP sessions, and session values; and restoring the server to its initial state based on the snapshot after each test, ensuring that each test starts from a consistent environment.

2. The Web application server-side vulnerability testing method according to claim 1, characterized in that, The steps for constructing semantic input samples based on key elements and derived key field matching rules include: Construct a structured request body based on known paths and constant values; generate field values ​​based on field types and constraint rules; Based on the structured request body, the field values ​​of the key elements are populated using an existing specialized dictionary; The input structure for field values ​​is determined based on the key field matching rules.

3. The Web application server-side vulnerability testing method according to claim 1, characterized in that, The step of injecting the semantic input sample into the server and performing the operation includes: Semantic input samples are injected into the processing flow of the web server via a web request interface; The semantic input sample is passed to the PHP container, and the PHP interpreter receives and processes the semantic input sample. After receiving the input sample, the PHP interpreter processes it according to the PHP script logic on the server side and generates the corresponding server response. Collect server response information, including feedback information for deriving matching rules and execution path information for analyzing abnormal fields.

4. The Web application server-side vulnerability testing method according to claim 1, characterized in that, The step of comparing the execution path with historical execution paths to determine whether a new path is generated during the execution of the semantic input sample includes: Collect the control flow path during execution, compare the current execution path with the historical execution paths, and analyze whether the current path is being touched for the first time; If the current path is different from the historical path, record the path as a new path and determine whether the path touches deep application logic or uncovered code areas. Based on the discovery of the new pathway, the effectiveness of the test inputs will be further evaluated, and a decision will be made on whether to conduct further sample variation or testing based on the evaluation results.

5. The Web application server-side vulnerability testing method according to claim 1, characterized in that, The step of performing semantic mutation operations on the anomalous fields in the semantic input samples that generate new paths to obtain mutated semantic input samples includes: Based on the semantic input samples that generate new paths, we analyze which fields have an impact on the generation of new paths; Perform semantic mutation operations on the fields that generate new paths. The semantic mutation operations include modifying field values, adding field content, trying boundary values, or trying limit values. And / or adjust field values ​​using known mutation strategies, including dictionary replacement, random concatenation, structural perturbation, or nested deletion.

6. The Web application server-side vulnerability testing method according to claim 1, characterized in that, The steps of monitoring the execution of semantic input samples and determining whether the semantic input samples trigger server vulnerabilities include: The monitoring server processes the input samples during execution and collects relevant data, including function call stacks, memory changes, and database queries. Detect whether the PHP script responds abnormally to the input sample, including database errors, memory overflow, and unprocessed input; Classify abnormal responses to determine whether they trigger server vulnerabilities; If a vulnerability is detected, the semantic input sample is marked as a potential vulnerability and detailed execution information is recorded for subsequent vulnerability analysis and remediation.

7. A web application server-side vulnerability testing device, characterized in that, The device includes: The sample generation module is used to parse the web application page to obtain its key elements, including form structure, field names and constraints; obtain the feedback made by the server after receiving the input sample, and deduce the matching rules of the key fields based on the feedback; and construct semantic input samples based on the key elements and the deduced key field matching rules. The execution test module is used to inject the semantic input sample into the server and execute it; obtain the execution path of the semantic input sample, compare the execution path with the historical execution path, and determine whether the semantic input sample generates a new path during the execution process; The in-depth exploration module is used to perform semantic mutation operations on anomalous fields in the semantic input samples that generate new paths, to obtain mutated semantic input samples; the mutated semantic input samples are then re-injected into the server for execution. The vulnerability detection module is used to monitor and determine whether the semantic input sample triggers a server vulnerability. Specifically, the monitoring and determination involves: monitoring the execution path of a preset key function in the PHP interpreter execution layer; when it is confirmed that the key function receives controllable parameters from the semantic input sample or the mutated semantic input sample and triggers abnormal behavior, it is determined that a server vulnerability has been triggered. The module also includes a snapshot recovery mechanism, which includes: taking a state snapshot of the server environment before executing a test, with snapshot content including memory, disk, database connections, PHP sessions, and Session values; and restoring the server to its initial state based on the snapshot after each test, ensuring that each test starts from a consistent environment.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the Web application server-side vulnerability testing method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the Web application server-side vulnerability testing method according to any one of claims 1 to 6.

Images