An automated request discovery method based on dynamic proxies

Abstract

This application discloses an automated request discovery method based on dynamic proxies. It utilizes the Java Instrumentation API to intercept the class loading process of the target application and determines the framework type of the service under test by comparing class inheritance relationships. Based on a predefined function signature rule base, it matches and marks the target parameter acquisition functions on the server side, and dynamically enhances them using a bytecode manipulation framework. It simultaneously performs full parameter collection at the HTTP request level and parameter interception at the server-side function call level, merging and deduplicating parameters from both sources to generate a structured and complete parameter list. This application can identify reserved parameters, hidden parameters, and dynamically generated parameters not transmitted by the client, significantly improving the coverage and vulnerability detection rate of fuzz testing for web applications, and is compatible with various mainstream Java Web frameworks.

Description

Technical Field

[0001] This application belongs to the field of computer security testing technology, specifically relating to an automated request discovery method based on dynamic proxies. Background Technology

[0002] With the rapid iteration of internet technology and the increasing complexity of web application architecture, the functional boundaries of web applications are constantly expanding. The scale of business data and user information they carry continues to grow, and the corresponding security threats are also showing a diversified, covert, and highly dangerous trend, making them a key target for protection in the global cybersecurity system. Fuzz testing, as a highly efficient automated vulnerability discovery technique, can trigger abnormal behavior and discover unknown security vulnerabilities by continuously injecting a large number of randomized and distorted test cases into the system under test. Due to its advantages of not relying on source code and its high degree of automation, it has been widely and deeply applied in the field of web application security testing.

[0003] In the complete process of fuzzing web applications, accurate and comprehensive discovery of request parameters is the foundation and core prerequisite for subsequent testing. Only by clearly defining the parameter names, data types, transmission methods, and possible value ranges of the interface under test can effective mutation test data be constructed in a targeted manner, thereby covering more code execution paths and discovering potential security vulnerabilities. Therefore, the performance and completeness of request parameter discovery technology directly determine the test coverage, vulnerability detection rate, and testing efficiency of fuzzing.

[0004] Currently, mainstream web application request parameter discovery technologies are all implemented from the client's perspective, mainly including two categories: web crawling technology and proxy technology. Web crawling technology simulates human user web browsing behavior, automatically traversing all accessible links and form elements of the tested website, parsing the crawled URL query strings and form submission data to extract parameter information. Proxy technology, on the other hand, deploys an intermediate proxy server between the client and the server, intercepting all HTTP request messages sent from the client to the server, performing structured parsing of the request line, request headers, and request body to extract various parameters contained within.

[0005] While the aforementioned technologies can meet basic parameter discovery needs, they still have inherent limitations that are difficult to overcome in practical engineering applications. First, existing technologies rely entirely on the actual request behavior of the client, and can only discover parameters actually sent by the client during the testing process. They cannot effectively identify reserved parameters that are defined and can be processed in the server-side code but have not yet been transmitted by the client. Second, existing technologies cannot handle hidden parameters that are dynamically generated by the server through backend business logic and are not explicitly transmitted in the client's request message. These parameters are usually deeply coupled with core business logic such as user permission verification and session state management, making them high-risk areas for security vulnerabilities. Finally, for temporary parameters that change dynamically with timestamps and user sessions, if the crawler or proxy fails to intercept a request containing such a parameter within the testing window, permanent parameter misses will occur.

[0006] In summary, existing client-side request parameter discovery technologies suffer from a core flaw: incomplete parameter acquisition. This limits the coverage of fuzz testing cases and makes it difficult to fully discover security vulnerabilities in web applications. Summary of the Invention

[0007] The purpose of this application is to overcome the shortcomings of the existing technology and provide an automated request discovery technology based on dynamic proxies. This technology solves the core problem of incomplete parameter acquisition in existing parameter discovery technologies based on the client's perspective, and achieves comprehensive identification of all parameters processed by the server, thereby improving the coverage and vulnerability detection rate of fuzz testing for web applications.

[0008] To achieve the above technical objectives, this application specifically adopts the following technical solution: In one aspect of this application, an automated request discovery method based on dynamic proxies is provided, comprising the following steps: S1. Utilize the Java Instrumentation API to load the agent program when the JVM starts, register a custom class file converter to intercept the class loading process of the target application; construct the inheritance relationship graph of the loaded classes, compare it with the predefined Java Web framework feature set, and determine the framework type and parameter processing entry component of the service under test. S2. Based on a predefined rule base containing signatures of parameter retrieval functions, match and mark target parameter retrieval functions that directly obtain external input data from the server. S3. Use a bytecode manipulation framework to dynamically enhance the target parameter acquisition function, insert parameter interception logic into the function execution path, and the enhanced code does not change the execution flow and exception propagation path of the original business logic. S4. During the operation of the target application, simultaneously perform full parameter collection at the HTTP request level and parameter interception at the server function call level: first, intercept the HTTP request entry point and collect the original request information sent by the client; then, intercept all calls to the target parameter acquisition function in the server code, and extract the parameter name of each call, including the parameter name corresponding to the function call when the client does not pass the corresponding parameter to the server. S5. Merge and deduplicate the parameters collected from the HTTP request and the parameters intercepted from the server-side function call to generate a structured and complete list of request parameters and output it for use by the subsequent fuzzing module.

[0009] In one implementation, during step S1, when intercepting the class loading process, filtering rules are set to exclude CGLIB dynamically generated classes, Lambda expression classes, Javassist proxy classes, and system internal classes. The predefined Java Web framework feature set covers the core classes and interfaces of Servlet, Spring MVC, WebSocket, and SOAP. Based on the matched framework type, the corresponding general strategy dispatch plugin, Servlet dispatch plugin, WebSocket dispatch plugin, or SOAP dispatch plugin is automatically selected for subsequent processing.

[0010] In one implementation, in step S2, the rule base is configured in XML format and includes three priority functions divided according to security analysis semantics: the first level is the data source function that directly obtains external input, the second level is the data propagation function that transmits transformed data, and the third level is the danger convergence function that triggers security risks. When the system starts, the XML rule base is parsed through the JAXB framework, and each function signature is converted into a method matcher for subsequent matching.

[0011] In one implementation, in step S3, the bytecode enhancement is as follows: the original bytecode of the target class is read by a class reader, a class accessor chain containing a custom policy notification adapter is constructed, and enhanced bytecode is generated by a class writer in a mode that automatically calculates stack frames and local variable tables; scheduling logic is inserted at the entry point of the target function, parameter tracking logic is inserted at the normal return point of the function, and an exception handling block is wrapped around the enhanced code. After catching the exception, the thread context stack is cleaned up before the original exception is rethrown.

[0012] In one implementation, in step S4, the full parameter collection at the HTTP request level involves intercepting the service() method of the Servlet container and the doFilter() method of the Filter chain to extract the request method, real URL, query parameters, request headers, request path, and request body information; wherein the request body is non-intrusively image-cached by instrumenting the ServletInputStream.read() method.

[0013] In one implementation, in step S4, while intercepting parameters at the server-side function call level, fine-grained data stream tracing is performed: when the data source function is called, a taint object is created, stored in the global taint pool, and associated with the payload object of the corresponding request; when the data propagation function is called, if the input parameters have taint markings, a taint propagation chain is constructed; when the danger convergence function is called, if the input parameters have taint markings, the complete propagation chain is extracted and stored in the security issue pool.

[0014] In one implementation, the merging and deduplication process in step S5 includes: deduplicating query parameters by parameter name as the key, and deduplicating request headers by lowercase header name as the key; the generated parameter list adopts a hierarchical JSON structure, with the top layer being the request information object, and each parameter field being encapsulated as a payload structure containing parameter value, injectable tag, data type, and associated mutation dictionary.

[0015] In one implementation, a closed-loop optimization step is included after step S5: during the fuzz test, the code coverage mapping and newly discovered parameter dictionary for each request are sent back to the fuzz test engine in real time; the engine retains the test inputs that improve coverage in the corpus and adds the new dictionary values ​​to the mutation dictionary of the corresponding parameters for priority use.

[0016] In one implementation, in step S3, the bytecode enhancement step can be replaced by using the interceptor mechanism of the server-side framework to call the parameter acquisition function to intercept parameters during the interception phase of request processing.

[0017] In one implementation, in step S3, the bytecode manipulation framework is any one of ASM, Javassist, or CGLIB.

[0018] The beneficial effects of this application are as follows: 1. It solves the core defects of existing technologies and achieves a comprehensive breakthrough in parameter discovery. This application takes a server-side approach, directly intercepting calls to parameter retrieval functions within the application through dynamic bytecode enhancement. This overcomes the limitation of traditional client-side methods, which can only identify explicitly passed parameters. It can capture not only the parameters actually sent by the client but also reserved parameters, hidden parameters, and dynamically generated parameters defined in the server-side code but not passed by the client. This fundamentally solves the problem of incomplete parameter discovery in existing technologies, providing a more comprehensive foundation for fuzz testing.

[0019] 2. It does not intrude on business logic code and has good compatibility and versatility. This system achieves end-to-end non-intrusive instrumentation based on the Java Instrumentation API and bytecode enhancement technologies such as ASM, requiring no modification to the target application's source code and not relying on any specific web framework. Through framework identification and plugin dispatching mechanisms, it can adapt to mainstream Java web application scenarios such as Servlet, Spring MVC, WebSocket, and SOAP, demonstrating excellent compatibility and scalability. Simultaneously, exception handling and context cleanup mechanisms ensure the stability of the target application and do not interfere with business logic.

[0020] 3. A closed-loop optimization mechanism was built to continuously improve the effectiveness of testing. By deeply coupling parameter discovery with the fuzzing process, code coverage and newly discovered parameter information are fed back to the fuzzing engine in real time, driving intelligent mutation and iteration of test cases. This not only continuously supplements and improves the parameter list but also enhances the efficiency of generating high-value test cases, significantly improving the vulnerability discovery capabilities and execution efficiency of fuzzing.

[0021] 4. Provide multi-dimensional support for security analysis and expand the application scenarios of the technology. Simultaneously with parameter discovery, the construction of taint propagation chains enables fine-grained tracking of the flow path of user input data within the application, providing data support for subsequent vulnerability analysis and risk tracing. This technical solution is not only applicable to fuzzing scenarios but can also provide comprehensive parameter information from a server-side perspective for code auditing, security baseline assessment, and other tasks, expanding the application boundaries of the technology. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating an automated request discovery method based on dynamic proxies, as described in this application. Detailed Implementation

[0023] The technical solution of this application will be clearly and completely described below with reference to specific embodiments. However, those skilled in the art will understand that the embodiments described below are only some embodiments of this application, not all embodiments, and are only used to illustrate this application, and should not be regarded as limiting the scope of this application. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] To address the inherent limitations of existing web application request parameter discovery technologies, which rely solely on the client-side perspective and fail to cover implicit server-side parameters, this application adopts a runtime approach, constructing a bidirectional parameter discovery mechanism based on dynamic bytecode enhancement. First, by using Java Instrumentation technology to load a proxy program during the target application's startup phase, it achieves non-intrusive interception of the class loading process, automatically identifying the framework type of the tested application and adapting the corresponding processing logic. Second, based on a predefined method signature rule library, it accurately locates key functions in the application that directly obtain external input, and instrumentes them using dynamic bytecode enhancement technology, achieving full capture of these function calls without affecting the original business logic. Third, by intercepting HTTP request entry points, it comprehensively collects all explicit parameters sent by the client; simultaneously, by capturing server-side function calls, it extracts implicit parameters defined in the application code but not passed by the client. Finally, the two types of parameters are merged and deduplicated to generate a parameter list with complete coverage.

[0025] In one specific implementation, an automated request discovery method based on dynamic proxies is provided, referring to... Figure 1 As shown, it includes the following steps: S1. Target Service Framework Type Identification and Dispatch Plugin Selection By intercepting the Java Virtual Machine (JVM) class loading process at the system level and combining it with a pre-built framework feature matching mechanism, the type of server-side framework that the tested web application depends on is automatically identified, and the core entry components that need to be focused on in subsequent instrumentation operations are determined accordingly.

[0026] Specifically, leveraging the class loading interception capabilities provided by the Java Instrumentation API, a pre-compiled agent package is loaded during JVM startup by specifying the "-javaagent" parameter. This agent internally registers a custom class file converter instance with the JVM. Before any class of the target application is loaded into memory by the JVM, the callback method of this class file converter is triggered, thereby obtaining the complete bytecode data of the class and its metadata, including class name, parent class name, and list of implemented interfaces.

[0027] The proxy program constructs and maintains a dynamically updated class inheritance graph (ClassDiagram) in memory. The specific implementation of the class inheritance graph adopts an ancestor set tracing mechanism: for each intercepted class, the program traverses its inheritance chain and interface implementation chain, aggregating the class's direct parent class, indirect parent class up to the root class, and all its implemented direct and indirect interfaces into a set containing a complete ancestor description.

[0028] Meanwhile, the system pre-configures a set of framework feature definition files stored in structured text format. These files are organized in XML format and contain the fully qualified names of the core component classes and interfaces of current mainstream Java Web frameworks. Specifically, the feature set includes at least: feature items defined for the Servlet specification, such as "javax.servlet.http.HttpServlet" and "javax.servlet.Filter"; feature items defined for the SpringMVC framework, such as "org.springframework.web.servlet.FrameworkServlet"; feature items defined for the WebSocket protocol, such as "javax.websocket.Endpoint"; and feature items defined for the SOAP protocol, such as "javax.xml.ws.Provider".

[0029] When the aforementioned ancestor set and the pre-defined XML framework feature set form a non-empty intersection, it can be determined that the loaded class belongs to a specific web framework ecosystem, and thus the type of underlying framework that the tested service depends on can be inferred. For example, if the ancestor set contains "javax.servlet.http.HttpServlet", it is determined that the target service runs in a Servlet container environment, and its parameter processing logic usually revolves around the relevant methods of the "HttpServletRequest" interface; if the ancestor set contains "FrameworkServlet", it is determined that the target service is built based on Spring MVC, and its parameter parsing mechanism involves annotation binding and parameter resolver chains.

[0030] To further enhance the targeting and efficiency of processing logic, a dispatch plugin architecture is designed internally within the system. This architecture pre-defines independent processing strategy units for different framework types, primarily including: a general strategy dispatch plugin for handling cross-framework common data flow analysis logic; a Servlet dispatch plugin specifically for analyzing HTTP request entry points under the Servlet specification; a WebSocket dispatch plugin specifically for analyzing WebSocket endpoint interactions; and a SOAP dispatch plugin specifically for analyzing XML-RPC service calls. After completing framework type matching, the system automatically activates the corresponding dispatch plugin based on the matching results. This plugin guides the selection range of specific parameter retrieval functions and the location logic of instrumentation points in subsequent steps.

[0031] Furthermore, during class loading interception, to avoid invalidating non-core auxiliary classes and thus increasing system overhead and interfering with analysis results, the proxy program sets explicit filtering and exclusion rules. Specifically, any class identified as dynamically generated by a proxy based on its class name or class loader characteristics—such as proxy subclasses dynamically constructed at runtime by the CGLIB or Javassist libraries, synthesized classes generated internally by the JVM to support Lambda expression syntax, and internal implementation classes under the system namespace—are all marked as non-target classes. The system directly returns the original bytecode of these excluded classes, without further inheritance relationship analysis, and excludes them from subsequent instrumentation enhancements.

[0032] The system supports two instrumentation scope determination modes: explicit whitelist mode and automatic discovery mode. In explicit whitelist mode, users specify the application package name prefixes to be instrumented through a configuration file. In automatic discovery mode, the system requires no user configuration; instead, it maintains an automatic exclusion list containing over 50 known framework and third-party library package name prefixes, covering mainstream frameworks such as org.springframework, org.apache, com.google, and org.hibernate. Classes whose names match any prefix in the automatic exclusion list are skipped, and all other classes are automatically included in the instrumentation scope. This automatic discovery mode allows the agent program to correctly identify and instrument application business code without configuring a separate instrumentation whitelist for each application under test.

[0033] S2. Identification and Labeling of Objective Parameter Acquisition Functions Based on a pre-built function signature rule base, specific methods requiring bytecode enhancement are selected from the classes loaded at runtime on the server side. The rule base is set according to the data flow path when the server processes external requests, dividing the functions to be instrumented into three layers with clear security analysis orientations.

[0034] Specifically, the rule base is stored declaratively within structured XML configuration files. In this implementation, the system maintains two basic configuration files: one for defining first-level functions that directly obtain external input, and second-level functions that pass and transform data within the program logic; the other for defining third-level functions that may trigger security risks. Each rule in the configuration file is recorded using a complete description format of the method signature. This format includes the fully qualified name of the class to which the target method belongs, the method name, and a list of formal parameter types enclosed in brackets, in the form of "full package path.class name.method name(parameter type list)". For example, for methods in the Servlet specification used to obtain request parameters, the rule can be expressed as "javax.servlet.ServletRequest.getParameter(java.lang.String)"; for dangerous methods that execute system commands, the rule can be expressed as "java.lang.Runtime.exec(java.lang.String)".

[0035] During the proxy program startup process, the system uses the JAXB specification, which is used for binding XML to Java objects within the Java ecosystem, to parse the aforementioned XML configuration file. After parsing, each signature rule is instantiated as a dedicated method matcher object. The construction process of this matcher object includes: using a signature parsing tool to decompose the rule string into three independent dimensions: class name, method name, and parameter descriptor, and generating a signature matcher instance capable of accurately comparing the method representation in the JVM.

[0036] The functions to be instrumented are divided into three priority levels according to their role in data flow analysis: The first level consists of data source functions. These functions are the direct entry point for the server program to receive raw request data from the client, and their return values ​​or output content constitute the initial source of external input data. Common first-level functions include, but are not limited to, methods for retrieving query parameters, request headers, cookie values, and input stream content from the HTTP request object. Because these functions are directly related to the parameters passed by the client, they are set as the core focus of the parameter discovery process.

[0037] The second level consists of data propagation functions. These functions do not generate new external inputs but rather process, concatenate, truncate, or format existing data. Typical examples include string substring extraction methods, string concatenation methods, and character replacement methods. The purpose of instrumenting these second-level functions is to construct the propagation path of tainted data, thereby tracing the complete flow of an external input parameter within the server-side business logic.

[0038] The third level consists of dangerous aggregation functions. These functions are typically located at the end of the data flow path, and their execution can trigger sensitive behaviors such as file system operations, database queries, and external command calls. Common functions include methods for executing operating system commands (such as Runtime.exec()), methods for executing structured query language statements (such as Statement.executeQuery()), methods for evaluating expressions (such as SpEL's ExpressionParser.parseExpression(), EL expression evaluation), LDAP directory query methods (such as DirContext.search() and Spring LdapTemplate.search()), template engine rendering methods (such as Velocity's VelocityEngine.evaluate(), Pebble's PebbleEngine.getLiteralTemplate(), and FreeMarker's Template constructor), URL redirection methods (such as HttpServletResponse.sendRedirect()), JNDI lookup methods (such as InitialContext.lookup()), XML parsing methods (such as DocumentBuilder.parse()), and HTTP response header setting methods (such as HttpServletResponse.setHeader() and Spring HttpHeaders.set()). Monitoring of third-level functions aims to determine whether external input data flows into sensitive operation points without proper validation, thereby identifying potential security vulnerabilities.

[0039] After identifying the target class and its framework type in step S1, the system enters the matching process. For each target class identified as a business class, the system uses bytecode analysis tools to extract the signature information of all its declared methods and calls the comparison interface of the aforementioned method matcher one by one to precisely match the extracted method signatures with the preset signature set in the rule base. Once it is confirmed that a method matches a certain signature rule in the rule base, the system marks the method as enhanced, indicating that the method will be included in the scope of bytecode enhancement in subsequent steps. Through this method selection mechanism based on precise signature comparison, it is ensured that instrumentation operations only apply to methods that are of substantial significance for parameter discovery and data flow tracing, avoiding unnecessary code intrusion.

[0040] S3. Bytecode enhancement and parameter interception logic implantation of the target function After identifying and marking the target parameter acquisition function, a bytecode manipulation framework is used to perform runtime enhancements on the marked method, injecting the monitoring code required for parameter capture and taint tracking into the target method body. The enhancement process is based on the fundamental constraint of not affecting the execution result of the original business logic and the exception propagation path.

[0041] In some embodiments, the ObjectWeb ASM (ASM) bytecode manipulation framework is selected as the underlying implementation tool. The ASM framework operates on the binary structure of Java class files based on the event-driven visitor pattern, enabling bytecode parsing, modification, and refactoring during the class loading phase. The specific operation flow is described below: The system reads the raw bytecode data stream of the target class through a ClassReader instance. ClassReader parses the constant pool, field information, method definitions, and attribute table item by item according to the class file format defined by the Java Virtual Machine Specification, and calls back the registered ClassVisitor instance during the parsing process.

[0042] The system constructs a ClassVisitor accessor chain, which contains a custom PolicyAdviceAdapter instance. This PolicyAdviceAdapter inherits from the AdviceAdapter class provided by the ASM framework. AdviceAdapter is specifically designed for scenarios where code snippets are inserted at method entry and exit points. For each target method marked as needing enhancement in step S2, PolicyAdviceAdapter is responsible for rewriting the corresponding MethodVisitor to weave in an additional sequence of monitoring instructions.

[0043] Code insertion follows a dual-location strategy: the method entry point and the normal method return. At the method entry point, the `onMethodEnter` callback method corresponding to `AdviceAdapter` is triggered. The system inserts scheduling logic here, calling the corresponding `enterSource()`, `enterPropagator()`, or `enterSink()` method based on the target function's category—Source, Propagator, or Sink. The responsibility of this entry processing method is to push a new analysis frame onto the call context stack bound to the current thread. This analysis frame records the nesting level of function calls and the function category identifier, providing a basis for constructing the subsequent taint propagation path.

[0044] At the normal return point of the method, the corresponding `onMethodExit` callback method of `AdviceAdapter` is triggered. The system inserts tracing logic here, performing differentiated operations based on the function type: For `Source` type functions, the `trackSourceMethod` logic is executed, obtaining the method return value object reference via the `loadReturn` instruction in ASM, obtaining the method input parameter object reference via the `loadArg` instruction, and calling the corresponding method of the `TaintHandler` processor interface to mark the return value as external input tainted data; for `Propagator` type functions, the `trackPropagatorMethod` logic is executed, checking whether the input parameter already exists in the taint pool. If it does, a new `Taint` node is created for the return value, and a propagation association from input taint to output taint is established; for `Sink` type functions, the `trackSinkMethod` logic is executed, checking whether the input parameter carries a taint mark. If tainted data is detected flowing in, the complete taint propagation chain information is extracted and stored in the security issue log area. The above tracing logic uses the `invokeInterface` instruction in ASM to dispatch the captured object references to the implementation class of the `TaintHandler` interface for unified processing.

[0045] To ensure that the inserted enhancement code does not violate the original exception semantics of the target method, the system wraps the enhanced method body in a try-catch block structure. When any exception is thrown during the execution of the method body, the catch block catches the exception object, first calls the leaveMethod() method to clean up the analysis frame corresponding to this call in the current thread's call context stack, and then re-throws the caught original exception object using the ATHROW instruction. This mechanism guarantees that the exception types and exception propagation paths relied upon by the upper-level business code are not affected by the bytecode enhancement operation.

[0046] The enhanced bytecode is generated using ClassWriter, which is configured in a combination of COMPUTE_FRAMES and COMPUTE_MAXS modes. In this mode, the ASM framework automatically calculates the maximum depth of the operand stack, the number of slots required for the local variable table, and the stack frame mapping, eliminating the need to manually specify these values. Simultaneously, it ensures that the output bytecode conforms to the bytecode verification requirements of the Java Virtual Machine Specification.

[0047] Finally, the enhanced bytecode dynamically replaces the original class definitions loaded in the JVM using the `retransformClasses()` method provided by the Java Instrumentation API. The entire enhancement process is completed at runtime, without requiring physical modification to the target application's original class files or restarting the application service process.

[0048] In one embodiment, the bytecode enhancement step can be implemented using bytecode manipulation tools other than ASM, such as Javassist or CGLIB. Javassist generates bytecode by concatenating strings at the source code level, making it relatively intuitive to operate; CGLIB achieves enhancement by generating a subclass of the target class and overriding methods, which is suitable for scenarios where the target class allows inheritance.

[0049] In another embodiment, if the framework upon which the service under test is based provides a complete request interception extension mechanism, the parameter capture function can also be implemented using the framework's native interceptors without relying on bytecode enhancement. For example, registering a Filter component in a Servlet environment and actively calling the parameter retrieval method of HttpServletRequest within the doFilter method of the Filter can also achieve the purpose of server-side parameter discovery.

[0050] S4. Two-layer collaborative interception and analysis of parameter information This step performs parameter capture operations at two levels simultaneously during the normal operation of the target application. The first level operates at the HTTP protocol communication layer, responsible for completely recording the original request data submitted by the client when the request reaches the server entry point; the second level operates at the server-side business code execution layer, responsible for extracting parameter identifiers and data flow information when the enhanced function is actually called. The capture results of the two levels are interrelated and together constitute a complete parameter view.

[0051] The first layer involves collecting all parameters at the HTTP request level. The system sets interception points along the necessary path for the Servlet container to process the request, specifically the entry points of the `service()` method defined in the implementation class of the `javax.servlet.Servlet` interface and the `doFilter()` method defined in the implementation class of the `javax.servlet.Filter` interface. The interception logic extracts the following information items from the `HttpServletRequest` object in the current request context by calling the `RequestInfo.collectRequestInfo()` method: The request method is obtained by calling getMethod(), which can distinguish between operation types such as GET, POST, PUT, and DELETE.

[0052] The process of reconstructing the complete URL takes into account reverse proxy deployment scenarios. The system reads the X-Forwarded-Proto header value to determine the original request protocol, reads the X-Forwarded-Host header value to determine the original hostname, and combines the path part obtained by getRequestURI() to obtain the real request address actually accessed by the client.

[0053] The query parameters are obtained by parsing the string returned by getQueryString(). The parsing process splits the query string into a set of key-value pairs using the '&' character as the delimiter. Each key-value pair is separated from the parameter name and parameter value by the first '=" character.

[0054] The request header information is obtained by iterating through the enumeration object returned by getHeaderNames() to get all header names, and then calling getHeader() to get the corresponding header value for each name.

[0055] The request path can be obtained by using getServletPath() to retrieve the mapping path declared in web.xml or annotations for the current Servlet.

[0056] The request body content is retrieved using a non-intrusive approach. The system instrumentes the `read()` method of the `ServletInputStream` class separately, synchronously writing the read bytes into a `ByteArrayOutputStream` buffer for mirrored storage during each read operation. The buffer capacity is set to a maximum of 4096 bytes; any excess is not cached to control memory usage. Because the mirroring operation and the business read operation are executed concurrently and do not block each other, the normal reading of the request body input stream by the business code is unaffected, and the read position and the number of available bytes remain completely consistent with before instrumentation.

[0057] The second layer involves intercepting server-side function call parameters and fine-grained data stream tracing. This layer relies on the runtime callbacks of the Source, Propagator, and Sink functions, whose bytecode enhancements were completed in step S3.

[0058] When a Source type function is called, the instrumentation code will trigger tracing logic when the function returns normally, regardless of whether the client request actually contains a value corresponding to that parameter name. Taking the parameter retrieval function `request.getParameter("role")` as an example, even if the client's HTTP request does not carry a query parameter or form field named "role", the server-side code can still actively call this method and pass in the parameter string "role". The system captures the parameter name string "role" and the method return value object at the method's exit point and creates a new Taint object. The Taint object is stored in a global pool structure named `TAINT_POOL`, which uses Java object references as keys and the corresponding Taint objects as values ​​for mapping and management. Simultaneously, this Taint object establishes an association reference with the corresponding source's Payload object in the RequestInfo structure collected at the first level.

[0059] When a Propagator type function is called, typical scenarios include string manipulation methods such as String.substring(), StringBuilder.append(), and String.replace(). At the method's exit point, the system checks if the input parameter object has a corresponding Taint record in TAINT_POOL. If it does, it indicates that the input data carries an external input tag. The system creates a new Taint node for the function's return value object and links this new node to the source Taint node corresponding to the input object, forming a taint propagation chain from the source node through intermediate propagation nodes to the current propagation node.

[0060] When a Sink type function is called, typical scenarios include Runtime.exec(), Statement.executeQuery(), XPath.evaluate(), DirContext.search(), ExpressionParser.parseExpression(), VelocityEngine.evaluate(), HttpServletResponse.sendRedirect(), and InitialContext.lookup(). The system checks at the method's entry or exit point whether its input parameter object has a corresponding Taint record in TAINT_POOL. If a match is found, it indicates that data with an external input marker has flowed into the dangerous operation function. The system extracts the complete propagation chain information associated with this Taint record. This propagation chain information records the original parameter source, each intermediate function operation along the propagation path, and the final dangerous function reached. This complete information is stored in a separate security issue pool for subsequent security analysis report generation.

[0061] Furthermore, the system synchronously executes taint distance feedback when the Sink function is triggered. Specifically, the hash value of the Sink function type and the call depth of tainted data reaching the Sink are encoded and written into the parameter area of ​​the coverage map. This feedback signal enables the fuzzing engine to distinguish between two states: "tainted data has not reached any Sink" and "tainted data has reached the Sink but the vulnerability has not been fully triggered." This rewards test inputs that bring the data closer to the dangerous operation point, guiding the mutation direction.

[0062] During the data propagation phase, when tainted data participates in comparison operations (such as String.equals(), String.contains(), String.startsWith(), String.compareTo(), etc.), the system performs comparison operand extraction. The specific mechanism is as follows: it checks if the objects involved in the comparison operation exist in TAINT_POOL. If the tainted side participates in the comparison, the non-tainted operands of the other side (i.e., the expected values ​​hard-coded in the program) are extracted and stored in the comparison operand list of the coverage mapping for the current request. Each request context collects a maximum of 100 unique comparison operands, with each operand having a maximum length of 500 characters. This comparison operand list is sent back to the fuzzing engine along with the coverage mapping. The engine selects values ​​from this list with a certain probability as mutation candidate inputs to bypass logical branches in the server-side code, such as string equality verification and permission checks.

[0063] All parameter information captured through the above two levels is uniformly encapsulated using the Payload structure. The Payload structure contains four core attributes: the value field stores the actual value of the parameter; the isPayload field is a boolean type, indicating whether the parameter should be used as an injectable test point for the fuzzing engine to mutate; the type field describes the data type of the parameter, and its values ​​can include string, json, integer, boolean, etc.; the dictionary field is a collection type container that stores the mutated dictionary values ​​associated with the parameter. The dictionary values ​​are derived from the internal program constants and conditional branch feature values ​​extracted during the data flow analysis process.

[0064] The encapsulated Payload object is categorized into different fields of the RequestInfo object based on the source of its parameters. Specifically, parameters from the query string are stored in the mapping structure corresponding to the query field, with the parameter name string as the key; parameters from the request header are stored in the mapping structure corresponding to the header field, with the lowercase string of the header name as the key; and parameters from the request body are stored in the body field. This categorized storage method achieves a structured organization of parameter information, facilitating unified processing and output by the subsequent parameter list generation module.

[0065] S5. Structured generation and output of the complete parameter list The raw request parameters obtained from the first-level HTTP request collection and the parameter identifiers obtained from the second-level server-side function call interception are aggregated and processed. Through deduplication and structured encapsulation, a parameter list file is generated that can be directly used by the subsequent fuzzing module. This file is organized in a hierarchical JSON format and fully describes all the parameter metadata involved in a single request.

[0066] The deduplication of parameter names employs a corresponding key mapping strategy based on the parameter source type. For query parameters, the system uses the parameter name string as the key of the mapping structure. When the same parameter name is called multiple times or repeatedly discovered within a single request processing cycle, the later occurrence of the same name will overwrite or merge into the existing key-value pair, thus ensuring that only one entry for the same parameter name is retained in the output results. For request header parameters, the system uses the lowercase form of the header name as the key of the mapping structure. Since the HTTP protocol specifies that header names are case-insensitive, and client proxies or middleware may send the same header with different combinations of uppercase and lowercase, using lowercase key-value comparison can effectively eliminate duplicate entries caused by case differences.

[0067] The deduplicated parameter data is organized into a hierarchical JSON document, with its top-level object named RequestInfo. This RequestInfo object contains six core fields, the meanings of which are as follows: The `method` field records the method type of the current HTTP request, with values ​​including GET, POST, PUT, DELETE, etc. This value comes from the raw string obtained by calling the `getMethod()` method in step S4.

[0068] The url field records the reconstructed complete request address, which combines proxy header information such as X-Forwarded-Proto and X-Forwarded-Host with the request path.

[0069] The pathName field records the mapping path of the current Servlet, and this value is obtained by calling the getServletPath() method.

[0070] The `query` field is a key-value mapping structure, where the key is the query parameter name string and the corresponding value is a payload object. This payload object encapsulates the parameter values ​​parsed from the query string and the associated metadata.

[0071] The header field is also a key-value mapping structure, where the key is a lowercase header name string and the corresponding value is a payload object. This payload object encapsulates the header values ​​and associated metadata extracted from the request header.

[0072] The body field stores the content representation of the request body. When the request body is successfully mirrored and the content type is a parsable format, this field contains the corresponding structured data representation or a reference to the original payload.

[0073] Each parameter value in the query, header, and body fields is encapsulated into a payload structure. The payload structure consists of four fixed properties: The `value` property stores the specific value of the parameter, which can be either a string or a representation of the underlying type after type inference.

[0074] The isPayload property is a boolean flag. When the value is true, it indicates that the corresponding parameter position should be included in the mutation test scope by the fuzzing engine; when the value is false, it indicates that the parameter is only recorded as context information and does not participate in mutation.

[0075] The `type` attribute describes the inferred data type of the parameter. The system categorizes it into one of the following types based on the literal format of the parameter value: string, json, integer, boolean, etc. This type information allows the fuzzing engine to select the appropriate mutation strategy.

[0076] The `dictionary` attribute is a collection structure used to store specific string constants or conditional branch feature values ​​extracted from the data stream analysis process and associated with this parameter. The values ​​in this collection will serve as priority candidate inputs during the fuzzing mutation phase to improve test targeting.

[0077] In addition to the main content of RequestInfo mentioned above, the system also appends the security event information recorded during the data flow tracing process in step S4 to the extended fields of the output JSON in a structured manner. For each security event triggered by the Sink function and confirmed to involve tainted data inflow, the system records the following information: vulnerability type classification identifier, such as sql-injection, cmd-injection, reflected-xss, path-traversal, ldap-injection, crlf, expression-language-injection, ssrf, invalidated-redirect, header-injection, jndi-injection, xxe, xpath-injection, hql-injection, nosql-injection, untrusted-deserialization, format-string, etc.; the fully qualified name of the class to which the dangerous function that triggered the event belongs; the name of the dangerous function method that triggered the event; and a complete taint propagation chain description from the Source node through several Propagator nodes to the Sink node. This chain description clearly shows the entire process of processing and transmitting external input data in the server-side code.

[0078] The generated JSON files are written to the `queue` subdirectory within the system's working directory. The files are named using the request identifier as the main filename and the `.json` extension, such as `100000.json` or `200000.json`. The request identifier is generated by the system based on the order in which requests are received or a hash digest, ensuring the uniqueness and traceability of the filenames. During the startup phase, the fuzzing engine scans this `queue` subdirectory, reading all the JSON files within as initial test seeds, and then uses these as the basis for subsequent test case mutations and test execution.

[0079] In some embodiments, during fuzzing, the system also performs a closed-loop feedback optimization step. Each time the fuzzing engine sends a mutated request to the service under test, the instrumentation system carries three feedback datasets in the HTTP response body: First, code coverage mapping data, which uses context-sensitive encoding to generate edge coverage identifiers by performing an XOR hash operation between the previous branch identifier and the current branch identifier, thus distinguishing the execution status of the same code block under different call paths, improving the granularity of recording from the basic block level to the call context level; second, a list of comparison operands, which comes from instrumentation interception of string comparison methods such as String.equals(), String.compareTo(), String.startsWith(), String.endsWith(), and String.contains(). When the compared string carries a taint, the system extracts the constant operands on the other side of the comparison operation to form a set of comparison values ​​associated with specific parameters; third, newly discovered parameter dictionary data, which comes from internal program string constants and conditional branch feature values ​​identified during taint analysis that are related to the processing of this request.

[0080] After receiving the feedback data, the fuzzing engine performs three adjustment operations. First, if the current test input improves code coverage compared to existing corpus records, the input is retained in the corpus, and a FAST energy scheduling strategy is used to allocate mutation energy to each seed in the corpus—seeds executed less frequently receive higher mutation priority to accelerate coverage of insufficiently explored code paths. Second, constant values ​​extracted from the comparison operand list are injected into subsequent mutation processes, enabling the fuzzing engine to generate input values ​​that match the program's internal conditional judgments, thereby overcoming deep branch guard conditions such as magic numbers, password verification, and enumeration value matching. Third, newly discovered dictionary values ​​are appended to the dictionary collection within the corresponding parameter Payload object, and in subsequent mutation operations targeting this parameter, candidate values ​​are preferentially selected from the dictionary collection for replacement attempts.

[0081] Through the aforementioned cyclical mechanism of parameter discovery, parameter mutation, coverage feedback, and dictionary update, the system continuously expands and refines the list of valid parameters for the tested URL during fuzz testing, thereby continuously improving the test coverage and vulnerability discovery capabilities.

[0082] Example 1 This embodiment uses a user management system built with the Spring MVC framework as the test object.

[0083] 1. Runtime Environment Configuration The tested application is a user management system built on Spring MVC, deployed as a WAR file within an Apache Tomcat 9.0 application server container. The server runtime environment has JDK 11 installed. The core access interface of the target application is defined as ` / api / user`, which supports both HTTP GET and POST requests. In the server-side interface implementation code, a parameter named `role` is defined for subsequent role-based permission determination logic; however, this parameter is not explicitly passed in the front-end page or client-side request logic, and is a reserved parameter on the server side.

[0084] 2. Target Service Identification When the proxy program starts, it analyzes the dependency library list in the WEB-INF / lib directory and the bytecode structure in the WEB-INF / classes directory within the target application's WAR package to confirm that the application depends on the core library files of the Spring MVC framework. Furthermore, during the class loading interception phase, the proxy program detects the existence of a DispatcherServlet class definition in the target application that inherits from org.springframework.web.servlet.FrameworkServlet. This confirms that the service under test uses Spring MVC as its web layer processing framework, and its HTTP request parameter parsing mechanism is jointly completed by the Spring MVC parameter resolver chain and the underlying javax.servlet.http.HttpServletRequest interface.

[0085] 3. Selection of instrumentation function Based on the typical way of obtaining request parameters in the Controller method under the Spring MVC framework, this embodiment selects the getParameter(String name) method declared in the javax.servlet.http.HttpServletRequest interface as the core instrumentation target function.

[0086] 4. Bytecode Enhancement Bytecode enhancement operations are performed using the Javassist tool. The specific steps are as follows: First, the concrete implementation class of the javax.servlet.http.HttpServletRequest interface within the Tomcat container is obtained through the class loader location mechanism provided by Javassist. In this embodiment, the implementation class used by Tomcat 9.0 is org.apache.catalina.connector.Request.

[0087] Secondly, the bytecode of the Request class is modified using Javassist. At the entry point of the getParameter(String name) method, a code snippet is inserted: System.out.println("Interceptedparameter: " + name).

[0088] In actual production deployment, this code snippet can be replaced with logic that calls a custom parameter collector, including storing the intercepted parameter name string and call stack information into a memory data structure.

[0089] Finally, the Javassist class is called to regenerate the interface, and the modified bytecode is written back to the JVM to replace the loaded original Request class definition. The replacement process is completed at runtime, without requiring any physical modification to Tomcat's catalina.jar file.

[0090] 5. Parameter interception and analysis The tester initiated an HTTP GET request to the target application using a client tool. The request URL was: http: / / example.com / api / user?name=test. The query string of this request only contained a parameter named 'name' with the value "test", and did not include a 'role' parameter.

[0091] After Tomcat receives the request, it dispatches it to the Spring MVC DispatcherServlet for processing, according to the Servlet specification. After request mapping, the DispatcherServlet calls the corresponding Controller method. Within the internal business logic of this Controller method, the following two parameter retrieval operations are executed sequentially: The first call is "request.getParameter("name")", used to retrieve the username passed in by the client; The second call, "request.getParameter("role")", is used to determine the current user's role and permissions. Although the client did not pass the "role" parameter in the request, the server-side code still actively called the parameter retrieval method.

[0092] Because bytecode enhancement has been implemented on the HttpServletRequest.getParameter(String) method, the inserted code logic was triggered at the method entry point in both of the above calls. For the first call, the system intercepted the parameter name string "name"; for the second call, the system intercepted the parameter name string "role".

[0093] The system records the parameter names captured twice into the parameter temporary storage area associated with the current request context.

[0094] 6. Parameter list generation After the parameter acquisition phase, the system iterates through the parameter name storage area associated with the current request and uses a mapping deduplication mechanism with parameter name as the key to merge duplicate parameter names into a single record. In this embodiment, the captured parameter names are "name" and "role", which are different from each other, so two independent parameter entries are retained after deduplication.

[0095] The final generated parameter list is {name, role}.

[0096] The parameter list is output in structured JSON format to the corresponding request seed file in the queue subdirectory. The `name` parameter, because the client actually passed a value, has its `value` field in the `Payload` structure recorded as "test". Although the `role` parameter was not passed a value by the client, it is actively retrieved in the server-side code, and therefore is still recorded as a valid parameter name in the parameter list. The `value` field in the `Payload` structure can be empty or a default value, and `isPayload` is marked as true, indicating that this parameter's position should be included in the variation range of subsequent fuzzing tests.

[0097] Compared to existing technical solutions that can only obtain the name parameter through client request analysis, this embodiment intercepts function calls from the server's perspective, successfully discovering the role parameter reserved by the server but not passed by the client, achieving a more comprehensive parameter list discovery effect.

[0098] Example 2 This embodiment uses an order query system built with the traditional Servlet specification as the test object to further illustrate the specific process of server parameter discovery through bytecode enhancement in non-framework web applications.

[0099] 1. Runtime Environment Configuration The tested application is a native order query system implemented based on the javax.servlet.Servlet specification, deployed as a WAR file within a Jetty application server container. The core business logic is encapsulated in a Servlet implementation class named OrderServlet, which registers the URL mapping path / api / order in the web.xml deployment descriptor. Inside the request handling method of OrderServlet, the developers wrote logic to call the getParameterNames() method to iterate through all processable parameters. The tested system defines a reserved parameter named orderType, used for internal business branch judgments, but neither the front-end page nor the client request logic passes the actual value of this parameter to the server.

[0100] 2. Selection of instrumentation function Based on the implementation characteristic of the server-side code actively traversing the parameter name set in this embodiment, the system selects the getParameterNames() method declared in the javax.servlet.http.HttpServletRequest interface as the core instrumentation target function for this implementation. The function signature is: javax.servlet.http.HttpServletRequest.getParameterNames().

[0101] The getParameterNames() method returns a java.util.Enumeration <string>This is an enumeration object of type `<parameter>` that contains all parameter name strings in the current HTTP request that can be recognized by the server. Since the return value of this method covers both the parameter names actually passed by the client and the parameter names expected to be processed by the server code, using this function for instrumentation allows for the batch capture of all potential parameter names in the current request context in a single call. This is suitable for centralized parameter discovery based on the encoding pattern of the server traversing the parameter set.

[0102] 3. Bytecode Enhancement This embodiment uses the ASM bytecode manipulation framework to enhance the bytecode of the OrderServlet class.

[0103] First, the raw bytecode data stream of the OrderServlet class is read using ClassReader, and its constant pool, method table, and attribute information are parsed.

[0104] Secondly, a ClassVisitor accessor chain is constructed, and a custom MethodVisitor implementation is provided for the doGet method declared in the OrderServlet class. This MethodVisitor overrides the visitMethodInsn directive access logic to locate the call point to the getParameterNames() method.

[0105] When the target signature of a method invocation instruction is detected to be javax / servlet / http / HttpServletRequest.getParameterNames()Ljava / util / Enumeration, MethodVisitor inserts an additional bytecode sequence after the invocation instruction. This additional sequence temporarily stores the reference to the Enumeration object returned by the getParameterNames() call in the local variable table, then sequentially calls the Enumeration.nextElement() method through a loop to retrieve each parameter name string, and stores the retrieved strings in a predefined temporary collection data structure associated with the current request.

[0106] After the enhancement operation is complete, the modified bytecode is output using ClassWriter in COMPUTE_FRAMES and COMPUTE_MAXS modes, and the enhanced OrderServlet class definition is reloaded into the running Jetty server JVM instance via the redefineClasses mechanism of the Instrumentation API. The redefinition process takes effect at runtime, and subsequent HTTP requests will be handled by the enhanced OrderServlet instance.

[0107] 4. Parameter interception and analysis Testers sent an HTTP GET request to the order query system under test using a client tool. The request URL was: http: / / example.com / api / order?orderId=123. The query string of this request only contained a parameter named orderId with the value "123", and did not include the orderType parameter.

[0108] After receiving a request, the Jetty server dispatches it to the OrderServlet instance according to the URL mapping rules. The OrderServlet's doGet method is executed, and somewhere within the method body, the following statement is called to retrieve the parameter name enumeration: Enumeration <string>params = request.getParameterNames().

[0109] Because the call point to the `getParameterNames()` method had been previously enhanced with bytecode, the system immediately executed the parameter collection logic after obtaining the `Enumeration` object. This collection logic iterated through all parameter name strings contained in the enumeration object. During this iteration, the system retrieved two parameter names from the enumeration: one was "orderId," which was explicitly provided by the client in the query string; the other was "orderType," a parameter reserved by the server. Although not included in the client request, this parameter name still appears as a potential parameter in the enumeration's return value because the server-side code typically iterates through all expected parameters after obtaining the parameter enumeration.

[0110] The inserted collection code adds the strings "orderId" and "orderType" to the temporary storage area of ​​the parameter names bound to the current request, one after the other.

[0111] 5. Parameter list generation After the request is processed, the system iterates through the temporary storage area of ​​parameter names associated with the current request and uses a mapping deduplication mechanism with parameter names as keys to complete the deduplication and merging. In this embodiment, the temporary storage area contains two unique parameter name strings, "orderId" and "orderType", both of which are retained after the deduplication operation.

[0112] The final parameter list is: {orderId, orderType}.

[0113] The parameter list is output in structured JSON format to the corresponding request seed file in the queue subdirectory. The orderId parameter is recorded in the value field of the corresponding Payload structure because the client actually passed the value "123". Although the orderType parameter is not provided by the client, its name appears in the enumeration results of the server-side getParameterNames() call, so it is included in the parameter list. The value field of the Payload structure can be empty or filled later by the fuzzing engine, and the isPayload flag is set to true.

[0114] Compared to existing solutions that can only obtain the orderId parameter through client request analysis, this embodiment successfully discovered the orderType parameter reserved and actively traversed by the server by instrumenting the getParameterNames() method call point from the server's perspective, further expanding the coverage of parameter discovery.

[0115] Although the embodiments of this application have been described above in conjunction with the accompanying drawings, this application is not limited to the specific embodiments and application fields described above. The specific embodiments described above are merely illustrative and instructive, not restrictive. Those skilled in the art can make many other forms based on the guidance of this specification and without departing from the scope of protection of the claims of this application, and these are all within the scope of protection of this application.< / string> < / string>

Claims

1. An automated request discovery method based on dynamic proxies, characterized in that, Includes the following steps: S1. Utilize the Java Instrumentation API to load the agent program when the JVM starts, register a custom class file converter to intercept the class loading process of the target application; construct the inheritance relationship graph of the loaded classes, compare it with the predefined Java Web framework feature set, and determine the framework type and parameter processing entry component of the service under test. S2. Based on a predefined rule base containing signatures of parameter retrieval functions, match and mark target parameter retrieval functions that directly obtain external input data from the server. S3. Use a bytecode manipulation framework to dynamically enhance the target parameter acquisition function, insert parameter interception logic into the function execution path, and the enhanced code does not change the execution flow and exception propagation path of the original business logic. S4. During the operation of the target application, synchronously perform full parameter collection at the HTTP request level and parameter interception at the server function call level: first intercept the HTTP request entry point and collect the original request information sent by the client; Then, intercept all calls to the target parameter acquisition function in the server-side code, and extract the parameter name for each call, including the parameter name corresponding to the function call when the client does not pass the corresponding parameter to the server; S5. Merge and deduplicate the parameters collected from the HTTP request and the parameters intercepted from the server-side function call to generate a structured and complete list of request parameters and output it for use by the subsequent fuzzing module.

2. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, In step S1, during the interception of class loading, filtering rules are set to exclude CGLIB dynamically generated classes, Lambda expression classes, Javassist proxy classes, and system internal classes. The predefined Java Web framework feature set covers the core classes and interfaces of Servlet, Spring MVC, WebSocket, and SOAP. Based on the matched framework type, the corresponding general strategy dispatch plugin, Servlet dispatch plugin, WebSocket dispatch plugin, or SOAP dispatch plugin is automatically selected for subsequent processing.

3. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, In step S2, the rule base is configured in XML format and includes three priority functions divided according to security analysis semantics: the first level is the data source function that directly obtains external input, the second level is the data propagation function that transmits transformed data, and the third level is the danger aggregation function that triggers security risks. When the system starts, the XML rule base is parsed through the JAXB framework, and each function signature is converted into a method matcher for subsequent matching.

4. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, In step S3, the bytecode enhancement is as follows: the original bytecode of the target class is read by a class reader, a class accessor chain containing a custom policy notification adapter is constructed, and enhanced bytecode is generated by a class writer in a mode that automatically calculates stack frames and local variable tables. Insert scheduling logic at the entry point of the target function, insert parameter tracking logic at the normal return point of the function, and wrap the exception handling block in the outer layer of the enhanced code. After catching the exception, clean up the thread context stack and then re-throw the original exception.

5. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, In step S4, the HTTP request-level full parameter collection involves intercepting the Servlet container's service() method and the Filter chain's doFilter() method to extract the request method, real URL, query parameters, request headers, request path, and request body information; wherein the request body is non-intrusively image-cached by instrumenting the ServletInputStream.read() method.

6. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, In step S4, while intercepting parameters at the server-side function call level, fine-grained data stream tracing is performed: when the data source function is called, a tainted object is created, stored in the global taint pool, and associated with the payload object of the corresponding request; when the data propagation function is called, if the input parameters have taint markings, a taint propagation chain is constructed, and if the propagation function is a comparison method, the non-tainted side operands are extracted as a comparison value dictionary and fed back to the fuzzing engine; when the dangerous convergence function is called, if the input parameters have taint markings, the complete propagation chain is extracted and stored in the security issue pool, and the depth information of the tainted data reaching the convergence function is encoded into the coverage map as a distance feedback signal.

7. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, The merging and deduplication process in step S5 includes: deduplicating query parameters by parameter name as the key, and deduplicating request headers by lowercase header name as the key; the generated parameter list adopts a hierarchical JSON structure, with the top layer being the request information object, and each parameter field being encapsulated as a payload structure containing parameter value, injectable tag, data type, and associated mutation dictionary.

8. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, Step S5 is followed by a closed-loop optimization step: during the fuzz test, the code coverage mapping, comparison operand list, and newly discovered parameter dictionary for each request are sent back to the fuzz test engine in real time; the coverage mapping uses context-sensitive coding and records the combined hash value of the current branch identifier and the previous branch identifier to distinguish different control flow paths that reach the same code location. The list of comparison operands contains the expected values ​​of the other side when tainted data participates in the comparison operation, which are injected by the fuzz testing engine to bypass input verification. The engine retains test inputs that improve coverage in the corpus and adds new dictionary values ​​and comparison operands to the corresponding parameter variant dictionary for priority use.

9. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, In step S3, the bytecode enhancement step can be replaced by using the interceptor mechanism of the server-side framework to call the parameter acquisition function to intercept parameters during the interception phase of request processing.

10. The automated request discovery method based on dynamic proxies according to claim 1, characterized in that, In step S3, the bytecode manipulation framework is any one of ASM, Javassist, or CGLIB.

Images