Method for identifying and defending against attack behavior of Java web application and device thereof

Abstract

The disclosure provides a method and device for identifying and defending against attack behavior of a Java Web application, and relates to the technical field of computers and the technical field of network security. The method acts on a Web container and comprises the following steps: modifying bytecode of a key underlying class to enhance a key underlying method; obtaining all class references to screen out risk classes; modifying bytecode of an HTTP container class in the Web container to register a request listener when the HTTP container is instantiated; recording request information and a request object when an HTTP request is received, and monitoring key underlying method call conditions; analyzing hit results of the risk classes in a stack and attackiveness of input parameters of the key underlying method calls to determine whether attack behavior exists; and executing a defense strategy and giving an alarm prompt when the Java Web application has attack behavior. The application can identify Trojan virus attack behavior characteristics during use of the Java Web application, determine attack behavior according to the Trojan virus attack behavior characteristics, take defense measures, and improve security and stability of the Java Web application.

Description

Technical Field

[0001] This disclosure relates to the fields of computer technology and network security technology, and in particular to a method and apparatus for identifying and defending against attacks on Java Web applications. Background Technology

[0002] JavaWeb technology is widely used across various important business lines, occupying a crucial position. Among related technologies, malicious control scripts (pages) and Trojan viruses, also known as WebShells, pose numerous security risks to JavaWeb websites and server-side applications, including malicious manipulation, data tampering, and information leakage. Trojan injection methods generally take two forms: file-based WebShells that upload files through vulnerabilities, and fileless WebShells (memory-based Trojans) that utilize web components or applications to register access routes and execute control code. A WebShell is a malicious script (Trojan) targeting web programs, aiming to gain execution privileges on the server. A memory-based Trojan, on the other hand, runs only in memory, leaving no file on disk or deleting itself after execution. File-based WebShells are easy to exploit and have a wide attack range, but are easily detected by scanning. Fileless WebShells are characterized by no file being written to disk, and their attack principles combine numerous complex vulnerabilities, making detection extremely difficult.

[0003] Trojan viruses pose a significant threat to Java Web applications. Accurately identifying and defending against Trojan virus injection and attack behaviors has become an important research direction. Summary of the Invention

[0004] This disclosure aims to at least partially address one of the technical problems in the related art.

[0005] The first aspect of this disclosure proposes a method for identifying and defending against attacks on Java Web applications, the method comprising:

[0006] Modify the bytecode of key underlying classes and enhance the specified key underlying methods so that when the key underlying methods are called, they can be detected and their execution can be controlled.

[0007] Identify the set of risk classes for the Java Web application and register a request listener for the HTTP container object. The request listener is used to monitor the creation and destruction of HTTP request objects.

[0008] If the HTTP container receives an HTTP request, the request listener detects the creation of the HTTP request object and identifies the key underlying method call. It then uses the hit results of the risk class collection in the stack trace and the aggressiveness of the key underlying method call parameters to determine whether the Java Web application is engaging in attack behavior.

[0009] If an attack occurs in a Java Web application, execute the defense strategy of interrupting calls to critical underlying methods and setting error messages for request responses, and issue an alert to the attack.

[0010] The second aspect of this disclosure provides a device for identifying and defending against attacks on Java Web applications, comprising:

[0011] The critical underlying method enhancement module is used to modify the bytecode of critical underlying classes and enhance specified critical underlying methods, so that the critical underlying methods can be detected and executed in a controllable manner when they are called.

[0012] The risk analysis module is used to determine the set of risk classes for Java Web applications and register request listeners for HTTP container objects. The request listeners are used to monitor the creation and destruction of HTTP request objects.

[0013] The attack identification module is used to detect the creation of the HTTP request object when the HTTP container receives an HTTP request, and to identify the key underlying method calls. It determines whether the Java Web application has any attack behavior by analyzing the hit results of the risk class collection in the stack and the attack nature of the key underlying method call parameters.

[0014] The attack defense module is used to execute defense strategies that interrupt the call to underlying critical methods and set error messages in the request and response if the Java Web application is attacked, and to provide alarm prompts for the attack.

[0015] A third aspect of this disclosure provides an electronic device, comprising:

[0016] At least one processor; and

[0017] A memory that is communicatively connected to at least one processor; wherein,

[0018] The memory stores instructions that can be executed by at least one processor, which enables the at least one processor to perform the method for identifying and defending against attacks on Java Web applications provided in the first aspect of this disclosure.

[0019] A fourth aspect of this disclosure provides a computer-readable storage medium having computer instructions stored thereon, wherein the computer instructions are used to cause a computer to execute a method for identifying and defending against attacks on a Java Web application provided in a first aspect of this disclosure.

[0020] The fifth aspect of this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the method for identifying and defending against attacks on Java Web applications provided in the first aspect of this disclosure.

[0021] This application can accurately identify and defend against Trojan virus injection and attack behaviors, enhance the universality of identifying attack behaviors in Java web applications, and improve the security and stability of Java web applications. Attached Figure Description

[0022] Figure 1 This is a flowchart of a method for identifying attack behaviors of Java page applications according to the first embodiment of this disclosure;

[0023] Figure 2 This is a flowchart of a method for identifying attack behaviors of Java page applications according to a second embodiment of this disclosure;

[0024] Figure 3 This is a schematic diagram of a method for identifying attack behaviors of Java page applications according to the third embodiment of this disclosure;

[0025] Figure 4 This is a flowchart of a method for identifying attack behaviors of Java page applications according to the first embodiment of this disclosure;

[0026] Figure 5 This is a flowchart of a method for identifying attack behaviors of Java page applications according to a second embodiment of this disclosure;

[0027] Figure 6 This is a flowchart of a method for identifying attack behaviors of Java page applications according to a second embodiment of this disclosure;

[0028] Figure 7 This is a schematic diagram of a method for identifying attack behaviors of Java page applications according to the fifth embodiment of this disclosure;

[0029] Figure 8 This is a schematic diagram of a method for identifying attack behaviors of Java page applications according to the fifth embodiment of this disclosure;

[0030] Figure 9 This is a flowchart of a method for identifying attack behaviors of Java page applications according to the fourth embodiment of this disclosure;

[0031] Figure 10 This is a flowchart of a method for identifying attack behaviors of Java page applications according to the fourth embodiment of this disclosure;

[0032] Figure 11 This is a schematic diagram of a method for identifying attack behaviors of Java page applications according to the fifth embodiment of this disclosure;

[0033] Figure 12 This is a structural block diagram of a device for identifying attack behaviors of Java page applications according to the first embodiment of this disclosure;

[0034] Figure 13 This is a schematic diagram of the structure of an electronic device according to the first embodiment of this disclosure. Detailed Implementation

[0035] Embodiments of this disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0036] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims. The acquisition, storage, use, and processing of data in the technical solutions of this application all comply with the relevant provisions of national laws and regulations.

[0037] The following describes, with reference to the accompanying drawings, a method and apparatus for identifying and defending against attacks on Java Web applications according to embodiments of the present disclosure.

[0038] Java is an object-oriented programming language, characterized by its powerful functionality and ease of use. As a representative of statically typed object-oriented programming languages, Java excellently implements object-oriented theory, allowing for complex programming with a simple mindset. In this embodiment, the method for identifying and defending against attacks on Java Web applications targets the Web container. It uses JavaAgent technology to encapsulate a JavaAgent package, which is integrated into the Web container. The functionalities within the JavaAgent package are activated upon startup of the Web container. Here, the Java Web application is a web application developed using the Java language.

[0039] Figure 1 This is a flowchart of a method for identifying and defending against attacks on Java Web applications according to the first embodiment of this disclosure, as shown below. Figure 1 As shown, the method includes the following steps:

[0040] In step S101, the bytecode of the key underlying class is modified, and the specified key underlying methods are enhanced so that the key underlying methods can be perceived and executed in a controllable manner when they are called.

[0041] Among them, the key low-level classes are the most critical Java classes that are frequently used in attack behaviors. These are Java classes that can execute operating system commands or file input / output I / O operations. They are the lowest-level classes that Java code can call. The functionality of these classes is implemented by native methods, which are implemented by the C library of the Java Virtual Machine (JVM).

[0042] Among them, the key underlying methods are specific methods of the key underlying class that are called when the attack executes operation commands or file I / O operations.

[0043] Modifying the bytecode of a class allows for changes to class information, including adding or deleting attributes and methods. By using JavaAgent technology to modify and reload the bytecode of a class at runtime, the functionality of classes and methods is enhanced seamlessly, without the knowledge of Java program developers or users, offering flexibility without code intrusion.

[0044] Bytecode files refer to the .class files that the JVM can execute after compiling .java files, containing all the information about Java classes. Java Agents, also known as Java proxies or Java probes, are a set of backdoors provided by the Java Virtual Machine (JVM) to monitor and assist programs running on the JVM, and can even dynamically replace and modify the definitions of certain classes. This feature effectively provides a virtual machine-level AOP implementation.

[0045] In step S102, the risk class set of the Java Web application is determined, and a request listener is registered for the HTTP container object. The request listener is used to monitor the creation and destruction of HTTP request objects.

[0046] Among them, "risk classes" are those frequently used as containers or springboards in attack activities. Suspected risk classes are identified through matching rules, which include preset configurations of the class name, parent class name, implemented interface class name, class annotation name, and class loader name. Whether a suspected risk class is indeed risky is determined through bytecode file decompilation and code security scanning.

[0047] Each Java Web application has an HTTP container, and a Web container contains multiple HTTP containers. After receiving an external HTTP request message, the HTTP container parses it and creates a Request object. This Request object is then passed to the Java Web application for processing. The Java Web application returns a Response object, which the HTTP container receives, assembles, and sends an HTTP response message to the external application. Listeners can be registered on the HTTP containers to monitor the creation and destruction of Request objects.

[0048] In step S103, if the HTTP container receives an HTTP request, the request listener detects the creation of the HTTP request object and determines the key underlying method call. It then uses the hit results of the risk class set in the stack and the attack nature of the key underlying method call parameters to determine whether the Java Web application has any attack behavior.

[0049] In this embodiment of the application, the request listener listens for the creation of the HTTP request object, records the request information and the request object, so as to facilitate further analysis of whether there is an attack on the Java Web application, and to execute the defense strategy in step S104 when there is an attack on the Java Web application.

[0050] In this embodiment of the application, if a key underlying method is called, it indicates that the Java Web application may be subject to attack. Therefore, it is necessary to monitor whether the key underlying method is called during the HTTP request business processing so that the Java Web application can be further analyzed in step S105 to determine whether there is any attack behavior.

[0051] In some implementations, if a critical underlying method is called, it indicates that the Java Web application may be subject to attack. Further analysis of the hit results of the risk class collection in the stack trace and the aggressiveness of the input parameters of the critical underlying method call is needed to determine whether the Java Web application is subject to attack.

[0052] In step S104, if the JavaWeb application exhibits an attack, the defense strategy of interrupting the underlying critical method calls and setting error messages for request responses is executed, and an alarm is triggered to indicate the attack.

[0053] In some implementations, Java Web applications are susceptible to attacks. The program determines to interrupt the call of a critical underlying method. Before the enhanced functionality of the critical underlying method throws an exception or returns a preset value, the program sets the request response at this time. The enhanced functionality of the critical underlying method throws an exception or returns a preset value. The business logic receives the error or preset value thrown by the underlying method and then continues the business process according to the original logic.

[0054] Since the output stream of a Response object can only be set once, if the enhanced functionality of a critical underlying method throws an exception or returns a preset value first, the business logic will immediately set the output stream of the Response object upon recognizing the exception. This may result in poor implementation of some Java Web applications, exposure of program stack information in the external response, and failure to receive the preset error message or redirection page. To avoid this situation, the request and response need to be set at the aforementioned time to improve the security and business continuity of Java Web applications.

[0055] Java web containers such as Tomcat and WebLogic are themselves Java applications. Their container startup configuration files allow you to set Java command startup parameters. By adding the path to the JavaAgent package and its parameters to the container's Java command startup parameters, the functionalities within the JavaAgent package can start along with the container when it starts.

[0056] In the application of JavaAgent functionality, it is necessary to encapsulate the JavaAgent package, set up a proxy class, and implement the `premain()` method within the class (premain contains the logic executed at runtime, where bytecode modifications can be performed). The web container integrates the JavaAgent package. The `premain()` method is executed when the web container starts. The input parameters of the `premain()` method can be obtained as parameter settings and an Instrumentation object. The `premain()` method implements the functionality of this embodiment. The web container is middleware for deploying Java web applications.

[0057] A Trojan virus is a malicious program used to remotely control a computer. It parasitizes the controlled computer system and performs operations on the infected computer. This application can identify the characteristics of Trojan virus attack behavior, determine the attack behavior based on these characteristics, and take defensive measures.

[0058] In this embodiment, the bytecode of key underlying classes is modified, and specified key underlying methods are enhanced, making their invocation perceptible and controllable. A set of risk classes in the Java Web application is determined, and a request listener is registered with the HTTP container object to monitor the creation and destruction of HTTP request objects. If the HTTP container receives an HTTP request, the request listener detects the creation of the HTTP request object and identifies the key underlying method call. The presence of an attack in the Java Web application is determined by analyzing the hit results of the risk class set in the stack trace and the aggressiveness of the key underlying method call parameters. If an attack is detected, a defense strategy is implemented that interrupts the underlying key method call and sets the error messages in the request response, along with an alert indicating the attack. This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on these characteristics, and take defensive measures, thereby improving the security and stability of Java Web applications.

[0059] Figure 2 This is a flowchart of a method for identifying and defending against attacks on Java Web applications according to the first embodiment of this disclosure, as shown below. Figure 2 As shown, if the HTTP request business processing involves critical low-level method calls, the analysis of the hit results of the risk class collection in the stack trace and the attack nature of the critical low-level method call input parameters, and the determination of whether the Java Web application has attack behavior based on the hit results and attack nature, includes the following steps:

[0060] In step S201, if the HTTP request processing involves critical underlying method calls, it is determined whether one or more risk classes in the risk class set are hit in the thread stack.

[0061] In some implementations, within the current thread, a reference to the current thread object can be obtained using the `Thread.currentThread()` method. Calling and processing the thread object's `getallstacktraces()` method allows access to the thread's call stack information, which includes the fully qualified class name and method name. String searches can then be used to count the occurrences of the fully qualified class name of risky classes within the stack information.

[0062] In step S202, if one or more risk classes from the risk class set are hit in the stack trace, it is determined that the Java Web application has suspected attack behavior. If one or more risk classes from the risk class set do not appear in the stack trace, it is further determined whether the input parameters of the key underlying method are malicious.

[0063] In some implementations, the method parameters are recorded and retrieved through enhanced functionality of key underlying methods.

[0064] In step S203, if the input parameters of the key underlying method are malicious, it is determined that the Java Web application has suspected attack behavior; if the input parameters of the key underlying method are not malicious, it is determined that the Java Web application has no attack behavior.

[0065] In some implementations, determining whether the input parameters of a critical underlying method are malicious is based on the attack detection rules preset in the critical underlying method's configuration. For example, in the `exec()` method of the `Runtime` class, if the input parameters begin with strings such as "sh", "ls", "pwd", or "hostname" in a Linux environment, or "cmd" or "hostname" in a Windows environment, the method parameters can be considered malicious.

[0066] To gain control of a host, a Trojan virus utilizes system commands. These commands can be further categorized into: acquiring information, such as operating system information, directory file information, and reading file information; performing operations on files or directories (adding, deleting, or modifying); and performing system operations and network transmission operations, among others.

[0067] In step S204, if it is determined that the Java Web application has suspected attack behavior, the suspected attack behavior is determined to be a false alarm by the preset rules of the false alarm filtering component.

[0068] In some implementations, the false positive filtering component provides configuration options that can be exposed to the user, allowing configuration of the component to handle false positive attacks. Configurable parameters include the request URL, the fully qualified class name used in the business logic execution, and the method name used in the business logic execution.

[0069] In step S205, if the suspected attack is a false alarm, it is determined that the Java Web application does not have an attack behavior; if the suspected attack is not a false alarm, it is determined that the Java Web application has an attack behavior.

[0070] In some implementations, if the HTTP request business processing involves calls to critical underlying methods, and attack analysis determines that the current request does not involve any attack behavior, the continued calling of the critical underlying methods is allowed, and the subsequent business processing of the HTTP request will be executed normally.

[0071] like Figure 3As shown in this embodiment, if the HTTP request processing involves calls to critical underlying methods, it is determined whether a risky class appears in the thread stack. If a risky class appears in the stack, it is considered a suspected attack. If no risky class appears in the stack, it is further determined whether the input parameters of the critical underlying method are malicious. If the input parameters of the critical underlying method are malicious, it is considered a suspected attack. If the input parameters of the critical underlying method are not malicious, it is considered that there is no attack behavior. Further, if it is determined that the JavaWeb application exhibits suspected attack behavior, the preset rules of the false positive filtering component are used to determine whether the suspected attack behavior is a false positive. If the suspected attack behavior is a false positive, it is determined that the JavaWeb application does not exhibit attack behavior. If the suspected attack behavior is not a false positive, it is determined that the JavaWeb application exhibits attack behavior.

[0072] This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on the characteristics of Trojan virus attacks, and take defensive measures to improve the security and stability of Java Web applications.

[0073] Figure 4 This is a flowchart of a method for identifying and defending against attacks on Java Web applications according to the first embodiment of this disclosure, as shown below. Figure 4 As shown, if an attack occurs in a Java Web application, the defense strategy of interrupting calls to critical underlying methods and setting error messages for request and response will be implemented, and an alert will be issued for the attack, including:

[0074] In step S401, if the HTTP request analysis of the Java Web application determines that there is an attack, based on the enhanced functionality of the key underlying method, the method call of the class is terminated before the native code of the key underlying method is executed, and an exception is thrown or a preset value is returned in the key underlying method, and the business is terminated.

[0075] In some implementations, the call to a class method is terminated before the execution of the native code of the critical underlying method. The preset value thrown is determined by the error setting in the preset configuration of the critical underlying method that the method is terminated. By default, a runtime exception is thrown, but a specific preset value can also be returned.

[0076] In step S402, the response object for the HTTP request is set to return a specified error message or redirect page.

[0077] In some implementations, after obtaining a reference to the request object, a reference to the response object is obtained from the request object, and the response headers and response body of the response object are set to return an error. The response settings are user-defined, allowing users to return fixed-format JSON messages, XML messages, or redirect to existing error pages, depending on the system's specific requirements.

[0078] In step S403, the attack behavior is recorded, including the request address, request information, stack information, risk class information, the name of the key underlying method triggered, and the method input parameters, and an alarm is triggered.

[0079] In some implementations, once an attack is detected, the attack log is recorded in a local log file. An HTTP protocol attack log push interface is provided, allowing users to implement the interface according to the agreed-upon interface definition and receive real-time attack log pushes.

[0080] In this embodiment, if the HTTP request analysis of a Java Web application determines that an attack has occurred, based on the enhanced functionality of key underlying methods, the method call to the class is terminated before the native code of the key underlying method is executed. An exception is thrown or a preset value is returned in the key underlying method, terminating the business logic. The response object of the HTTP request is set to return a specified error message or redirect a page. The attack behavior is recorded, including the request address, request information, stack trace, risk class information, the name of the triggered key underlying method, and its input parameters, and an alarm is triggered. This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on the characteristics of Trojan virus attacks, and take defensive measures, thereby improving the security and stability of Java Web applications.

[0081] Figure 5 This is a flowchart of a method for identifying and defending against attacks on Java Web applications according to the first embodiment of this disclosure, as shown below. Figure 5 As shown, the bytecode of the key underlying class is modified, and the specified key underlying methods are enhanced so that their execution is perceptible and controllable when they are called, including:

[0082] In step S501, a class file converter that enhances the key underlying methods is constructed and registered. The class file converter can be applied to one or more key underlying classes that contain key underlying methods.

[0083] In some implementations, the `premain()` method of the proxy obtains an `Instrumentation` object, and calls the `addTransformer()` method of the `Instrumentation` object to register a class file converter. The class file converter implements the `ClassFileTransformer` interface and implements the `transform()` method. `transform()` can record important information, obtain class objects for inspection, and modify and replace the class's bytecode when the class is instantiated.

[0084] In step S502, a reference to a loaded class is obtained through a proxy to determine whether the key underlying class has been instantiated.

[0085] In some implementations, the `getAllLoadedClasses()` method of the `Instrumentation` object is called to retrieve all loaded classes. If a class object appears in the array returned by `getAllLoadedClasses()`, it is determined that the class has been instantiated.

[0086] In step S503, if a critical underlying class has been instantiated, the proxy triggers a reload of the critical underlying class to trigger a class file converter that enhances the critical underlying methods.

[0087] In some implementations, calling the Instrumentation object's retransformClasses() method can trigger the reloading and instantiation of already instantiated classes.

[0088] In step S504, if the critical underlying class is not instantiated, the class file converter for enhancing the critical underlying method is triggered while waiting for its instantiation.

[0089] In step S505, the class file converter of the key underlying method is enhanced by modifying the bytecode of the key underlying class through bytecode modification technology, thereby enhancing the key underlying method so that it can detect and block the execution of the method when the key underlying method is called, and control the execution result of the key underlying method.

[0090] Among them, the execution result of the key underlying method is controlled by whether the key underlying method has been executed or not.

[0091] In some implementations, the class file converter for key underlying methods is enhanced by modifying the bytecode of key underlying classes through bytecode modification techniques. These techniques include: obtaining the class operation object of the bytecode through the fully qualified class name; obtaining the operation object of the bytecode method through the method name and input parameter types; and inserting method call notification, execution blocking code, and execution result control code into the method header. The purpose of these methods is to provide the class name, method name, and call parameters of the key underlying methods for attack analysis, and to block the continued invocation of the key underlying methods until the attack analysis is completed, waiting for the result of the attack analysis to allow the code to continue execution or terminate the code execution.

[0092] In step S506, the modified bytecode is loaded into the JVM, causing the critical underlying class to be instantiated for the first time or again.

[0093] like Figure 6As shown in this embodiment, a class file converter for enhancing critical underlying methods is constructed and registered. If a critical underlying class has been instantiated, the proxy triggers a reloading of the critical underlying class to activate the class file converter for enhancing the critical underlying methods. If the critical underlying class has not been instantiated, the class file converter is activated when it is instantiated. The class file converter for enhancing critical underlying methods modifies the bytecode of the critical underlying class using bytecode modification technology, thereby enhancing the critical underlying methods. This allows the converter to detect and block method execution when the critical underlying method is called, and to control the execution result of the critical underlying method. The modified bytecode is loaded into the JVM, causing the critical underlying class to be instantiated for the first time or again.

[0094] This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on the characteristics of Trojan virus attacks, and take defensive measures to improve the security and stability of Java Web applications.

[0095] Figure 7 This is a flowchart of a method for identifying and defending against attacks on Java Web applications according to the first embodiment of this disclosure, as shown below. Figure 7 As shown, all class object references of the Java Web application are obtained, and risky classes are filtered out from all classes through rule matching and code scanning to obtain a set of risky classes, including:

[0096] In step S701, references to all class objects are obtained through a proxy. All class objects include instantiated classes and classes that will be instantiated.

[0097] The acquisition methods are divided into two types: obtaining references to all currently instantiated classes, and obtaining references to classes after uninstantiated classes are instantiated through a registered class file converter.

[0098] In some implementations, the addTransformer() method of the Instrumentation object is called to register a class file converter for risk class filtering.

[0099] In step S702, for any type of object reference, it is determined whether the bytecode class file of the class object has been written to disk.

[0100] Among them, "file to disk" means that the file has an actual file and is saved to the disk, and the file has a disk path.

[0101] The class loader is responsible for dynamically loading Java classes (bytecode files) into the memory space of the Java Virtual Machine.

[0102] In this embodiment, the class file name of the fully qualified class name referenced by the assembled class object is used. The class loader object referenced by the class object is obtained, and a resource retrieval method is obtained through the class loader object, passing the fully qualified class file name as the method parameter to obtain the resource location URL object. If the resource file location obtained from the URL object contains an entity file, it is determined that the bytecode class file has been written to disk; otherwise, it is determined that the bytecode class file has not been written to disk.

[0103] In step S703, if the bytecode class file of the class object is not written to disk, it is marked as the first type; if the bytecode class file of the class object is written to disk, it is marked as the second type.

[0104] In step S704, the first category is added to the risk category set, and it is determined whether the second category matches the risk category rule.

[0105] In this embodiment, the class name and class loader of the second type are obtained. If the class name of the second type matches a class name in a preset risk class list, the second type is determined to have hit the risk class rule. If the class loader of the second type matches a class name in a preset risk class loader list, the second type is determined to have hit the risk class rule. If the second type is a subclass, implementation class, or annotation class related to a JavaWeb component, the second type is determined to have hit the risk class rule.

[0106] In some implementations, the rules define high-risk parent classes for Java Web components as javax.servlet.http.HttpServlet, org.apache.jasper.runtime.HttpJspBase, etc. The rules also define high-risk interfaces for Java Web components as javax.servlet.Filter, javax.servlet.Servlet, javax.servlet.ServletRequestListener, javax.servlet.ServletContextListener, com.netflix.zuul.ZuulFilter, etc. Finally, the rules define high-risk annotations for Java Web components as org.springframework.stereotype.Controller, javax.servlet.annotation.WebFilter, javax.servlet.annotation.WebListener, javax.servlet.annotation.WebServlet, etc.

[0107] Among them, Java Web components include at least the following three types:

[0108] Servlet: Short for Java Servlet, it's a component of Java Web. A Servlet is a program that runs on a web server or application server, acting as an intermediary layer between requests from web browsers or other HTTP clients and the database or application on the HTTP server.

[0109] A filter is a component in Java Web. In the web, filters intercept and process requests, performing appropriate actions to implement specific functionalities, such as login control, access control, and filtering of sensitive keywords.

[0110] A Listener is a component in Java Web. It is used to listen for creation and destruction events of domain objects such as ServletContext, HttpSession, and HttpServletRequest in a web application, as well as events that modify properties of these domain objects, triggering predefined code execution in response to the listened events.

[0111] In step S705, if the second category matches the risk category rule, the second category is marked as the third category.

[0112] In step S706, code detection is performed on the third category. If code anomalies are detected, the third category is added to the risk category set.

[0113] Classes that are not included in the risk class set are all classified as risk-free.

[0114] In this embodiment, the bytecode already loaded in memory for the third category is read. The bytecode file content of the third category is translated into readable Java code text using decompilation technology. Code detection is performed on the Java code text to obtain the number of times the Java code text matches preset risk keywords. If the number of times the Java code text matches the risk keywords is greater than a preset threshold, it is determined that a code anomaly has been detected, and the third category is added to the risk class set.

[0115] In some implementations, risky keywords include "shell", "$$BCEL$$", "javax.crypto.", "ProcessBuilder", "getRuntime", ".exec", " / bin / bash", etc.

[0116] like Figure 8As shown in this embodiment, references to all class objects are obtained through a proxy, and each class is analyzed. That is, for any class object reference, it is determined whether the class object's bytecode (class file) has been written to disk. If the class object's bytecode (class file) has not been written to disk, the class is added to the risk class set. If the class object's bytecode (class file) has been written to disk, it is further determined whether the class matches the risk class rule. If it does not match the risk class rule, the class is determined to be a risk-free class. If it matches the risk class rule, code detection is further performed. If code anomalies are detected, the class is added to the risk class set; otherwise, the class is determined to be a risk-free class.

[0117] This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on the characteristics of Trojan virus attacks, and take defensive measures to improve the security and stability of Java Web applications.

[0118] Figure 9 This is a flowchart of a method for identifying and defending against attacks on Java Web applications according to the first embodiment of this disclosure, as shown below. Figure 9 As shown, the bytecode of the HTTP container class in the Web container is modified to obtain a reference to the HTTP container object during HTTP container instantiation. A request listener is registered for the HTTP container object. The request listener is used to monitor the creation and destruction of HTTP request objects, including:

[0119] In step S901, a class file converter is constructed and registered to enhance the HTTP container class constructor in the Web container. The class file converter operates on the HTTP container class in the Web container.

[0120] In some implementations, the addTransformer() method of the Instrumentation object is called to register a class file converter that enhances the HTTP container class constructor in the web container.

[0121] In step S902, when the HTTP container class is instantiated, the class file converter of the enhanced HTTP container class constructor is triggered.

[0122] The HTTP container class is instantiated later than the premain() execution time, so there is no need to reload the HTTP container class.

[0123] In step S903, the class file converter that enhances the HTTP container class constructor modifies the bytecode of the HTTP container class through bytecode modification technology to enhance the HTTP container class constructor. The enhancement is used to detect when an HTTP container class object is created and to obtain a reference to the HTTP container class object.

[0124] In some implementations, the class operation object of the HTTP container class bytecode is obtained by using the fully qualified class name; the operation objects of all constructors of the HTTP container class are obtained; and code is inserted at the end of the constructor method to notify the request listener's registered class method of the reference to the object itself.

[0125] In step S904, the modified bytecode is loaded into the JVM, causing the HTTP container class to be instantiated.

[0126] In step S905, when the HTTP container class object is created, a request listener is constructed to monitor the creation and destruction of the HTTP request object using reflection and dynamic proxy techniques, and the request listener is registered with the HTTP container class object.

[0127] Dynamic proxy, specifically Java dynamic proxy, refers to the dynamic creation of a proxy object at runtime. Java's reflection mechanism allows, during program execution, the construction of objects of any class, the understanding of the class to which any object belongs, the access to the member variables and methods of any class, and the invocation of the attributes and methods of any object.

[0128] In some implementations, after obtaining the HTTP container class object, reflection is used to retrieve the state information query method object and the method object for registering listeners. If the HTTP container class object is confirmed to be in a normal state, a request listener implementation class is created using dynamic proxy technology. The aforementioned request listener, in its `requestInitialized` method implementation, notifies the specific class method of request object creation, and in its `requestDestroyed` method implementation, notifies the specific class method of request object destruction.

[0129] In this embodiment, a class file converter for enhancing the HTTP container class constructor in the Web container is constructed and registered. This class file converter operates on the HTTP container class within the Web container. When the HTTP container class is instantiated, the class file converter of the enhanced HTTP container class constructor is triggered. The class file converter modifies the bytecode of the HTTP container class using bytecode modification technology and loads the modified bytecode into the JVM, causing the HTTP container class to be instantiated. When the HTTP container class object is created, a request listener is constructed using reflection and dynamic proxy technologies to monitor the creation and destruction of HTTP request objects, and this request listener is registered with the HTTP container class object. This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on the characteristics of Trojan virus attacks, and take defensive measures, thereby improving the security and stability of Java Web applications.

[0130] Figure 10 This is a flowchart of a method for identifying and defending against attacks on Java Web applications according to the first embodiment of this disclosure, as shown below. Figure 10 As shown, if the HTTP container receives an HTTP request, and the request listener detects the creation of the HTTP request object, records the request information and the request object, and monitors whether key underlying methods are called during the HTTP request business processing, it also includes:

[0131] In step S1001, if the HTTP request business processing involves the call of a critical underlying method, the enhanced function of the critical underlying method is used to detect the call of the critical underlying method and the blocking of method execution. The business processing is suspended, and the current method execution information and stack information are transferred to the attack analysis.

[0132] In a web container, each HTTP request object has its own independent thread to process its request content. Each thread is independent of the others, and stack information can be obtained by getting the current thread object.

[0133] In step S1002, if the HTTP request business processing does not involve the invocation of critical underlying methods, the subsequent HTTP request business processing will be executed normally.

[0134] In step S1003, if a notification is received that the HTTP request object of the request listener has been destroyed, the reference to the request object is released.

[0135] like Figure 11 As shown in this embodiment, the Web container integrates the JavaAgent package. Upon startup, the `premain()` method of the proxy implementation class is executed. This initiates the enhancement of key underlying methods, risk analysis, and request listener registration. Once these three functions are successfully started, the request monitoring function functions normally. When a risky request is detected, the attack analysis function determines whether there is an attack, and the attack defense function provides measures to handle such attacks.

[0136] This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on the characteristics of Trojan virus attacks, and take defensive measures to improve the security and stability of Java Web applications.

[0137] Figure 12 This is a block diagram of a device for identifying and defending against attacks on a Java Web application according to a first embodiment of this disclosure. Figure 12 As shown, the Java Web application attack identification and defense device 1200 of this disclosure embodiment includes:

[0138] The critical underlying method enhancement module 1210 is used to modify the bytecode of critical underlying classes and enhance the specified critical underlying methods so that the critical underlying methods can be perceived and executed in a controllable manner when they are called.

[0139] The risk analysis module 1220 is used to determine the set of risk classes of a Java Web application and register request listeners for the HTTP container object. The request listeners are used to monitor the creation and destruction of HTTP request objects.

[0140] The attack identification module 1230 is used to determine whether the Java Web application has an attack behavior by listening to the creation of the HTTP request object when the HTTP container receives an HTTP request and the request listener detects the creation of the HTTP request object and determines the key underlying method call. The attack identification module 1230 is used to determine whether the Java Web application has an attack behavior by listening to the hit results of the risk class collection in the stack and the attack of the key underlying method call parameters.

[0141] The attack defense module 1240 is used to execute defense strategies that interrupt the call of underlying critical methods and set error messages in the request and response if there is an attack in the Java Web application, and to provide alarm prompts for the attack.

[0142] In some implementations, the attack identification module 1230 further includes:

[0143] The request monitoring unit 1231 is used to record request information and request object if the HTTP container receives an HTTP request and the request listener detects the creation of the HTTP request object, and to monitor whether key underlying methods are called during the HTTP request business processing.

[0144] The attack identification unit 1232 is used to analyze the hit results of the risk class collection in the stack and the attack nature of the input parameters of the key underlying method calls if the HTTP request business processing involves critical underlying method calls. The hit results and attack nature are used to determine whether the Java Web application has attack behavior.

[0145] In some implementations, requesting the monitoring unit 1231 is further configured to:

[0146] If the HTTP request business processing involves the call of critical underlying methods, the enhanced function of critical underlying methods can be used to detect the call of critical underlying methods and the blocking of method execution. The business processing will be suspended, and the current method execution information and stack information will be transferred to attack analysis.

[0147] If the HTTP request business processing does not involve the call of critical underlying methods, the subsequent HTTP request business processing will be executed normally;

[0148] If you receive a notification from the request listener that the HTTP request object has been destroyed, release the reference to the request object.

[0149] In some embodiments, the attack identification unit 1232 is further configured to:

[0150] If the HTTP request processing involves critical low-level method calls, determine whether the thread stack hits one or more risk classes in the risk class collection;

[0151] If one or more risk classes from the risk class set are hit in the stack trace, it is determined that the Java Web application has suspected attack behavior. If one or more risk classes from the risk class set are not found in the stack trace, it is further determined whether the input parameters of the key underlying method are malicious.

[0152] If the input parameters of the key underlying methods are offensive, it is determined that the Java Web application has suspected attack behavior; if the input parameters of the key underlying methods are not offensive, it is determined that the Java Web application has no attack behavior.

[0153] If a Java Web application is suspected of being attacked, the default rules of the false alarm filtering component are used to determine whether the suspected attack is a false alarm.

[0154] If the suspected attack is a false alarm, it is determined that the Java Web application is not under attack. If the suspected attack is not a false alarm, it is determined that the Java Web application is under attack.

[0155] In some implementations, the attack defense module 1240 is also used for:

[0156] If the HTTP request analysis of a Java Web application determines that there is an attack, based on the enhanced functionality of the key underlying methods, the method call of the class will be terminated before the native code of the key underlying methods is executed, and an exception will be thrown or a preset value will be returned in the key underlying methods, and the business will be terminated.

[0157] Set the response object of an HTTP request to return a specified error message or redirect page;

[0158] The system records the request address, request information, stack trace, risk type information, name of the key underlying method that was triggered, and method parameters for any attack behavior, and issues an alert.

[0159] In some embodiments, the attack identification unit 1232 is further configured to:

[0160] If the HTTP request business processing involves calls to critical underlying methods, and attack analysis determines that the current request does not involve any attack behavior, the continued calling of critical underlying methods is allowed, and subsequent HTTP request business processing will execute normally.

[0161] In some implementations, the key underlying method enhancement module 1210 is further configured to:

[0162] Build and register a class file converter that enhances key underlying methods. The class file converter can be applied to one or more key underlying classes that contain key underlying methods.

[0163] Obtain references to loaded classes through a proxy to determine whether key underlying classes have been instantiated.

[0164] If a critical underlying class has been instantiated, the proxy triggers a reload of the critical underlying class to trigger a class file converter that enhances the critical underlying methods;

[0165] If the critical underlying class is not instantiated, the class file converter that enhances the critical underlying method will be triggered when it is instantiated.

[0166] The class file converter enhances critical underlying methods by modifying the bytecode of critical underlying classes through bytecode modification technology, thereby enhancing critical underlying methods. This enables the converter to detect and block method execution when critical underlying methods are called, and to control the execution result of critical underlying methods.

[0167] The modified bytecode is loaded into the JVM, causing critical underlying classes to be instantiated for the first time or again.

[0168] In some implementations, the risk analysis module 1220 further includes:

[0169] Risk class analysis unit 1221 is used to obtain all class object references of the Java Web application, and filter out risk classes from all classes through rule matching and code scanning to obtain a risk class set;

[0170] The request listener registration unit 1222 is used to modify the bytecode of the HTTP container class in the Web container, obtain a reference to the HTTP container object when the HTTP container is instantiated, and register a request listener for the HTTP container object. The request listener is used to monitor the creation and destruction of HTTP request objects.

[0171] In some implementations, the risk analysis unit 1221 is also used for:

[0172] All class objects are referenced through a proxy, including both instantiated and soon-to-be-instantiated classes.

[0173] For any type of object, determine whether the bytecode (class file) of the object has been written to disk;

[0174] If the bytecode class file of a class object is not written to disk, it is marked as Class 1; if the bytecode class file of a class object is written to disk, it is marked as Class 2.

[0175] Add the first category to the risk category set, and determine whether the second category matches the risk category rule;

[0176] If the second category matches the risk category rule, then the second category will be marked as the third category;

[0177] Code inspection is performed on the third category. If code anomalies are detected, the third category is added to the risk category set.

[0178] In some implementations, the risk analysis unit 1221 is also used for:

[0179] The filename of the fully qualified class name of the assembled class object;

[0180] Obtain the class loader object of the class object, obtain the resource method through the class loader object, and pass the class file name with the fully qualified class name as the method parameter to obtain the resource location URL object;

[0181] If the resource file location obtained from the URL object contains an entity file, it is determined that the bytecode class file has been written to disk; otherwise, it is determined that the bytecode class file has not been written to disk.

[0182] In some implementations, the risk analysis unit 1221 is also used for:

[0183] Get the class name and class loader of the second type;

[0184] If the class name of the second category matches the class name in the preset risk class list, the second category is determined to be a hit risk class rule;

[0185] If the class loader of the second type matches the class name in the preset list of risky class loaders, the second type is determined to be a hit risky class rule;

[0186] If the second category is a subclass, implementation class, or annotation class related to JavaWeb components, then the second category is determined to be a risk class.

[0187] In some implementations, the risk analysis unit 1221 is also used for:

[0188] Read the bytecode already loaded in memory for the third type;

[0189] The bytecode content of the third type is translated into readable Java code text using decompilation technology;

[0190] Perform code analysis on Java code text to obtain the number of times the Java code text matches preset risk keywords;

[0191] If the number of times the Java code text matches the risk keywords exceeds a preset threshold, an anomaly is detected in the code, and the third category is added to the risk category set.

[0192] In some implementations, the request listener registration unit 1222 is further configured to:

[0193] Build and register a class file converter that enhances the HTTP container class constructor in the Web container. The class file converter operates on the HTTP container class in the Web container.

[0194] When the HTTP container class is instantiated, the class file converter of the enhanced HTTP container class constructor is triggered;

[0195] The class file converter enhances the HTTP container class constructor by modifying the bytecode of the HTTP container class through bytecode modification technology. This enhances the HTTP container class constructor so that the creation of HTTP container class objects is detected and references to HTTP container class objects are obtained.

[0196] The modified bytecode is loaded into the JVM, causing the HTTP container class to be instantiated.

[0197] When an HTTP container class object is created, a request listener is constructed to monitor the creation and destruction of HTTP request objects using reflection and dynamic proxy techniques, and the request listener is registered with the HTTP container class object.

[0198] This application can identify the characteristics of Trojan virus attacks during the use of Java Web applications, determine the attack behavior based on the characteristics of Trojan virus attacks, and take defensive measures to improve the security and stability of Java Web applications.

[0199] Figure 13 This is a block diagram illustrating an electronic device according to an exemplary embodiment. It should be noted that the electronic device can be any type of electronic device, including client devices, banking systems, and card organization systems.

[0200] like Figure 13 As shown, the aforementioned electronic device 1300 includes:

[0201] The memory 1310 and processor 1320 are connected by a bus 1330, which connects different components (including the memory 1310 and the processor 1320). The memory 1310 stores a computer program, and when the processor 1320 executes the program, it implements the method for identifying and defending against attacks on Java Web applications as described in this embodiment of the disclosure.

[0202] Bus 1330 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0203] Electronic device 1300 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 1300, including volatile and non-volatile media, removable and non-removable media.

[0204] Memory 1310 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1340 and / or cache memory 1350. Electronic device 1300 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 1360 may be used to read and write non-removable, non-volatile magnetic media (… Figure 13 Not shown; usually referred to as a "hard drive"). Although Figure 13 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 1330 via one or more data media interfaces. Memory 1310 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0205] A program / utility 1380 having a set (at least one) of program modules 1370 may be stored, for example, in memory 1310. Such program modules 1370 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 1370 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0206] Electronic device 1300 can also communicate with one or more external devices 1390 (e.g., keyboard, pointing device, display 1391, etc.), and with one or more devices that enable a user to interact with the electronic device 1300, and / or with any device that enables the electronic device 1300 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 1392. Furthermore, electronic device 1300 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1393. Figure 13 As shown, network adapter 1393 communicates with other modules of electronic device 1300 via bus 1330. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with electronic device 1300, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0207] The processor 1320 performs various functional applications and data processing by running programs stored in the memory 1310.

[0208] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the method for identifying and defending against attacks on Java Web applications in this disclosure embodiment, and will not be repeated here.

[0209] To implement the above embodiments, this disclosure also proposes a computer-readable storage medium.

[0210] When the instructions in the computer-readable storage medium are executed by the processor of the business server, the business server is able to perform the methods for identifying and defending against attacks on Java Web applications as described above. Optionally, the computer-readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0211] To implement the above embodiments, this disclosure also provides a computer program product, including a computer program, characterized in that, when the computer program is executed by a processor, it implements the method for identifying and defending against attacks on Java Web applications as described above.

[0212] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims. It should be understood that this disclosure is not limited to the precise structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for identifying and defending against attacks on Java Web applications, characterized in that, include: Modify the bytecode of the key underlying class and enhance the specified key underlying methods so that the key underlying methods can be perceived and executed in a controllable manner when they are called; Determine the set of risk classes for the Java Web application and register a request listener for the HTTP container object, the request listener being used to monitor the creation and destruction of HTTP request objects; If the HTTP container receives an HTTP request, the request listener detects the creation of the HTTP request object and determines the critical underlying method call. It then uses the hit results of the risk class set in the stack and the attack nature of the critical underlying method call input parameters to determine whether the Java Web application has any attack behavior. If the Java Web application is attacked, execute the defense strategy of interrupting the call to the underlying critical method and setting the error message for the request response, and issue an alarm for the attack. Wherein, if the HTTP container receives an HTTP request, the request listener detects the creation of the HTTP request object and determines the critical underlying method call. It then determines whether the Java Web application exhibits attack behavior by analyzing the hit results of the risk class set in the stack trace and the attackivity of the critical underlying method call input parameters. This includes: If the HTTP container receives an HTTP request, and the request listener detects the creation of the HTTP request object, it records the request information and the request object, and monitors whether the key underlying methods are called during the HTTP request business processing. If the HTTP request business processing involves the critical underlying method call, analyze the hit results of the risk class set in the stack and the attack nature of the critical underlying method call input parameters, and determine whether the Java Web application has an attack behavior based on the hit results and the attack nature. Wherein, if the HTTP request business processing involves the critical underlying method call, the analysis of the hit results of the risk class set in the stack trace and the attack nature of the critical underlying method call input parameters, and the determination of whether the Java Web application has an attack behavior based on the hit results and the attack nature, includes: If the HTTP request processing involves critical low-level method calls, determine whether the thread stack hits one or more risk classes in the risk class set; If one or more risk classes from the risk class set are hit in the stack trace, it is determined that the Java Web application has suspected attack behavior. If one or more risk classes from the risk class set are not found in the stack trace, it is further determined whether the input parameters of the key underlying method are malicious. If the input parameters of the key underlying method are offensive, it is determined that the Java Web application has suspected attack behavior; if the input parameters of the key underlying method are not offensive, it is determined that the Java Web application has no attack behavior. If it is determined that the Java Web application has suspected attack behavior, the preset rules of the false alarm filtering component are used to determine whether the suspected attack behavior is a false alarm. If the suspected attack is a false alarm, it is determined that the Java Web application does not exhibit any attack behavior; if the suspected attack is not a false alarm, it is determined that the Java Web application exhibits attack behavior.

2. The method according to claim 1, characterized in that, The method of "if the HTTP container receives an HTTP request, and the request listener detects the creation of an HTTP request object, records the request information and the request object, and monitors whether the key underlying method is called during the HTTP request business processing" also includes: If the HTTP request business processing involves the call of a critical underlying method, the enhanced function of the critical underlying method can be used to detect the call of the critical underlying method and the blocking of method execution. The business processing will be suspended, and the current method execution information and stack information will be transferred to the attack analysis. If the HTTP request business processing does not involve the invocation of critical underlying methods, the subsequent business processing of the HTTP request will be executed normally; If a notification is received that the HTTP request object of the request listener has been destroyed, the reference to the request object is released.

3. The method according to claim 1, characterized in that, If the Java Web application exhibits an attack, the defense strategy of interrupting calls to critical underlying methods and setting error messages in request responses will be implemented, and an alarm will be triggered for the attack, including: If the HTTP request analysis of the Java Web application determines that there is an attack, based on the enhanced functionality of the key underlying method, the call to the class's method is terminated before the native code of the key underlying method is executed, and an exception is thrown or a preset value is returned in the key underlying method, and the business is terminated. Set the response object of the HTTP request to return a specified error message or redirect page; The system records the request address, request information, stack information, risk class information, name of the key underlying method that was triggered, and method input parameters for the attack behavior, and issues an alarm.

4. The method according to claim 2, characterized in that, Also includes: If the HTTP request business processing involves the call to the critical underlying method, and the attack analysis determines that the current request does not involve any attack behavior, the continued call to the critical underlying method is allowed, and the subsequent business processing of the HTTP request will be executed normally.

5. The method according to claim 1, characterized in that, Modifying the bytecode of the key underlying class and enhancing the specified key underlying methods so that their invocation is perceptible and controllable includes: Construct and register a class file converter that enhances key underlying methods, wherein the class file converter can operate on one or more key underlying classes that contain the key underlying methods; By obtaining references to loaded classes through a proxy, it can be determined whether the key underlying class has been instantiated. If any of the aforementioned critical underlying classes have been instantiated, the proxy triggers a reload of the critical underlying classes to trigger a class file converter that enhances the critical underlying methods. If the key underlying class is not instantiated, the class file converter for enhancing the key underlying method will be triggered when it is instantiated. The class file converter that enhances the key underlying methods modifies the bytecode of the key underlying classes through bytecode modification technology, thereby enhancing the key underlying methods so that it can detect and block the execution of the key underlying methods when they are called, and control the execution result of the key underlying methods. The modified bytecode is loaded into the JVM, causing the critical underlying class to be instantiated for the first time or again.

6. The method according to claim 1, characterized in that, The step of determining the risk class set of the Java Web application and registering a request listener for the HTTP container object includes: Obtain all class object references of the JavaWeb application, and filter out risk classes from all classes through rule matching and code scanning to obtain a set of risk classes; Modify the bytecode of the HTTP container class in the web container to obtain a reference to the HTTP container object when the HTTP container is instantiated, and register a request listener for the HTTP container object.

7. The method according to claim 6, characterized in that, The process involves obtaining references to all class objects of the Java Web application, and then filtering out risky classes through rule matching and code scanning to obtain a set of risky classes, including: References to all class objects are obtained through a proxy, including both instantiated classes and classes to be instantiated. For any type of object, determine whether the bytecode class file of the object has been written to disk; If the bytecode class file of the class object is not written to disk, it is marked as the first type; if the bytecode class file of the class object is written to disk, it is marked as the second type. Add the first category to the risk category set, and determine whether the second category matches the risk category rule; If the second category matches the aforementioned risk category rule, the second category will be marked as the third category; Code detection is performed on the third category. If code anomalies are detected, the third category is added to the risk category set.

8. The method according to claim 7, characterized in that, The step of determining whether the bytecode class file of any type of object has been written to disk includes: The filename that assembles the fully qualified class name of the object of the class; Obtain the class loader object of the class object, obtain the resource method through the class loader object, and pass the class file name of the fully qualified class name as the method parameter to obtain the resource location URL object; If the resource file location obtained from the URL object contains an entity file, it is determined that the bytecode class file has been written to disk; otherwise, it is determined that the bytecode class file has not been written to disk.

9. The method according to claim 7, characterized in that, The process of determining whether the second category matches a risk-based rule includes: Obtain the class name and class loader of the second type; If the class name of the second category matches the class name in the preset risk class list, it is determined that the second category hits the risk class rule; If the class loader of the second type matches the class name in the preset risk class loader list, it is determined that the second type hits the risk class rule; If the second category is a subclass, implementation class, or annotation class related to JavaWeb components, then the second category is determined to be a risk class rule.

10. The method according to claim 7, characterized in that, The step of performing code detection on the third category, and adding the third category to the risk category set if code anomalies are detected, includes: Read the bytecode already loaded in memory for the third type; The bytecode content of the third type is translated into readable Java code text using decompilation technology; The Java code text is subjected to code detection to obtain the number of times the Java code text matches preset risk keywords; If the number of times the Java code text matches the risk keyword is greater than a preset threshold, it is determined that a code anomaly has been detected, and the third category is added to the risk category set.

11. The method according to claim 6, characterized in that, The modification of the bytecode of the HTTP container class in the Web container, obtaining a reference to the HTTP container object during HTTP container instantiation, and registering a request listener for the HTTP container object include: Construct and register a class file converter that enhances the constructor of the HTTP container class in the Web container, the class file converter operating on the HTTP container class in the Web container; When the HTTP container class is instantiated, a class file converter that enhances the HTTP container class constructor is triggered; A class file converter that enhances the HTTP container class constructor modifies the bytecode of the HTTP container class using bytecode modification technology to enhance the constructor of the HTTP container class. The enhanced functionality is used to detect when an object of the HTTP container class is created and to obtain a reference to the object of the HTTP container class. The modified bytecode is loaded into the JVM, causing the HTTP container class to be instantiated. When the HTTP container class object is created, a request listener is constructed to monitor the creation and destruction of HTTP request objects using reflection and dynamic proxy techniques, and the request listener is registered with the HTTP container class object.

12. A device for identifying and defending against attack behaviors in Java Web applications, characterized in that, include: The critical underlying method enhancement module is used to modify the bytecode of critical underlying classes and enhance specified critical underlying methods, so that the critical underlying methods can be perceived and executed in a controllable manner when they are called. The risk analysis module is used to determine the set of risk classes of the Java Web application and register a request listener for the HTTP container object. The request listener is used to monitor the creation and destruction of HTTP request objects. An attack identification module is used to determine whether the Java Web application has an attack behavior if the HTTP container receives an HTTP request, the request listener listens to the creation of the HTTP request object, and determines the key underlying method call. The module is used to determine whether the Java Web application has an attack behavior by using the hit result of the risk class set in the stack and the attack nature of the input parameters of the key underlying method call. The attack defense module is used to execute defense strategies that interrupt the call to underlying critical methods and set the error information for the request response if the JavaWeb application is attacked, and to provide an alarm for the attack. The device for identifying and defending against attacks on Java Web applications is also used to implement the method as described in any one of claims 1-11.

13. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-11.

15. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-11.

Images