Dynamically updated byte code security protection method, system and program product

Abstract

The invention provides a dynamically updated byte code security protection method, which comprises the following steps of: loading an agent program when an application program is started, acquiring and caching an instrumentation object, receiving security detection logic and instrumentation configuration information issued by a management end by the agent program through a communication mechanism with the management end, and storing the security detection logic and the instrumentation configuration information in the application program; and the agent program translates the instrumentation logic issued by the management end into byte codes by using the byte code operation library, generates a class file conversion object containing the instrumentation logic, registers the class file conversion object into an instrumentation object, and calls a class re-conversion method of the instrumentation object to perform byte code updating on a target class, thereby realizing dynamic insertion of the instrumentation logic. And the updated byte code takes effect immediately, and security vulnerabilities in the target method are detected and protected in real time. According to the method, the capability of quickly responding to the 0Day vulnerability and blocking the 0Day vulnerability in real time is realized, and the time for updating the protection logic is greatly shortened.

Description

Technical Field

[0001] The present invention relates to the field of computer security technology, and in particular to a dynamically updated bytecode security protection method, system and program product. Background Art

[0002] At present, with the frequent occurrence of network attacks and the increasingly severe network security situation, the security of Web applications faces huge challenges. 0Day vulnerabilities are a high-risk security vulnerability that is favored by attackers because there are no protective measures before the vulnerability is exposed. Traditional vulnerability repair methods require a long process of analysis, development, testing, and release, and it is difficult to provide effective protection immediately after the vulnerability is publicly exploited. This limitation makes 0Day vulnerabilities a very threatening means of network attacks.

[0003] In the prior art, RASP (Runtime Application Self-Protection) technology is a runtime code self-protection solution that can monitor and protect against potential threats when the application is running. RASP technology can dynamically monitor the behavior of the application in real time by inserting detection and protection logic into the application, thereby preventing malicious operations from occurring. However, the plug-in logic of traditional RASP technology is often statically specified when the application starts. Although this static insertion mechanism can cover the known vulnerability field, it seems powerless in the face of unknown 0Day vulnerability fields. When an unknown vulnerability breaks out, the existing RASP products cannot respond quickly and block in real time, and need to go through a long protection logic update cycle. The usual steps are to complete the development of new detection logic, first integrate it into the basic image, and then notify each access party to re-run the pipeline and re-release the system. After the system is re-released, effective protection against the vulnerability can be achieved, which is difficult to deal with hacker attack threats in a short period of time. This traditional vulnerability repair process often lasts for weeks or even months. In the race against time with hackers, the long repair cycle greatly reduces the protection effect of RASP. Attackers often successfully exploit vulnerabilities before they are fixed, obtaining sensitive data or causing other damage.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0005] In response to the problems in the prior art, the purpose of the present invention is to provide a dynamically updated bytecode security protection method, system and program product to achieve rapid response and emergency blocking capabilities for unknown vulnerability areas, ensure that the protection logic can be dynamically updated at the first time, and prevent the occurrence of attack behaviors in real time.

[0006] The embodiment of the present invention provides a dynamically updated bytecode security protection method, comprising the following steps:

[0007] The agent program is loaded when the security application is started, the agent program obtains and caches the instrumentation object, and saves the instrumentation object to a global variable;

[0008] The agent receives the security detection logic and instrumentation configuration information sent by the management end through the communication mechanism with the management end, including the target class, target method and corresponding instrumentation logic;

[0009] The agent uses the bytecode operation library to translate the instrumentation logic sent by the management end into bytecode and generate a class file conversion object containing the instrumentation logic;

[0010] Register the class file conversion object to the instrumentation object, and call the reconversion class method of the instrumentation object to update the bytecode of the target class to achieve dynamic insertion of the instrumentation logic;

[0011] The updated bytecode takes effect immediately, detecting and protecting against security vulnerabilities in target methods in real time.

[0012] In some embodiments, the implementation of the communication mechanism between the agent program and the management end includes the following steps:

[0013] After the agent program establishes a communication connection with the management end, the agent program sends initial registration information to the management end, including the unique identification of the agent program, version information and current running status;

[0014] The agent program periodically sends heartbeat detection requests to the management end to maintain the communication connection and report its own status;

[0015] During each heartbeat detection, the agent actively requests the management end to pull the latest security detection logic and instrumentation configuration information;

[0016] After receiving the instrumentation configuration information, the agent parses it, maps the configuration information to the target class, target method and corresponding instrumentation logic that need to be instrumented, and maintains the instrumentation configuration information list.

[0017] In some embodiments, the reconversion class method of the instrumented object performs bytecode update on the target class and is configured to perform incremental modification on the existing bytecode of the target class by the reconversion class method, thereby avoiding the performance overhead and instability that may be caused by full replacement of the bytecode.

[0018] In some embodiments, the class file conversion object is configured to perform code insertion, logic modification, or instruction deletion on the target method to meet the needs of different security detection scenarios.

[0019] In some embodiments, the bytecode manipulation library is configured as JavaAssist or ASM for dynamically generating and modifying Java bytecodes.

[0020] In some embodiments, the security detection logic includes at least one of the following detection rules: SQL injection detection, command execution detection, deserialization vulnerability detection, cross-site scripting attack (XSS) detection, and file inclusion attack detection.

[0021] In some embodiments, when the agent program uses the bytecode operation library to translate the custom instrumentation logic sent by the management end into bytecode, the input parameters of the target method are checked, including parameter type checking, length restriction, regular expression matching and illegal character filtering to prevent malicious requests.

[0022] In some embodiments, the agent saves a snapshot of the current bytecode state before each bytecode update so that it can be quickly rolled back and restored when the instrumentation fails.

[0023] In some embodiments, the reconverted class method of the instrumented object supports batch bytecode updates of multiple methods of the target class to improve the efficiency of operations on a large number of classes.

[0024] In some embodiments, the management end dynamically adjusts the instrumentation configuration information based on the real-time status and detection results of the application program, and sends it to the agent program through a communication mechanism.

[0025] In some embodiments, when the agent program pulls the latest instrumentation configuration information, it sorts multiple security detection logics based on the policy priority of the management end and inserts them into the target method in sequence.

[0026] In some embodiments, after obtaining the instrumentation configuration information sent by the management end, the agent program performs signature verification and integrity verification on the configuration information to ensure the security and credibility of the instrumentation logic.

[0027] In some embodiments, the agent supports the management and compatibility of multiple versions of instrumentation configuration information to ensure that security protection capabilities are maintained during system version iterations.

[0028] Another aspect of the present invention further provides a dynamically updated bytecode security protection system for implementing the above-mentioned dynamically updated bytecode security protection method, the system comprising:

[0029] The management end is used to generate and apply protection strategies;

[0030] The agent side, deployed in the security application, receives the security detection logic and instrumentation configuration information issued by the management side through the instrumentation object, and dynamically updates the bytecode of the target class.

[0031] Another aspect of the present invention also provides a dynamically updated bytecode security protection program product, which includes computer instructions, which implement the steps of the above-mentioned dynamically updated bytecode security protection method when executed by a processor.

[0032] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure.

[0033] The dynamically updated bytecode security protection method, system and program product of the present invention have the following features:

[0034] Beneficial effects:

[0035] The present invention introduces a dynamic bytecode update mechanism, and the present invention realizes dynamic adjustment of security detection logic and plug-in configuration information, so as to be able to quickly respond to new attack scenarios and provide more flexible and real-time security protection capabilities. The present invention adopts a dynamic plug-in logic insertion and bytecode update mechanism to achieve rapid response and real-time blocking capabilities for 0Day vulnerabilities. After the agent program sends new plug-in configuration information from the management end, it can modify the bytecode of the target class in real time and take effect immediately, greatly shortening the time for updating the protection logic, so that the security policy can be quickly iterated and applied to actual protection. Through the method of re-converting the class, the present invention can incrementally modify the loaded target class bytecode without replacing all the bytecodes, and dynamically insert new detection and protection logic. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Other features, objectives and advantages of the present invention will become more apparent from a reading of the detailed description of non-limiting embodiments made with reference to the following accompanying drawings.

[0037] Figure 1 is a flow chart of a dynamically updated bytecode security protection method according to an embodiment of the present invention;

[0038] Figure 2 It is a schematic diagram of the structure of a dynamically updated bytecode security protection system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0039] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that the disclosure will be more comprehensive and complete and to fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0040] In addition, the accompanying drawings are only schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor devices and / or microcontroller devices.

[0041] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the steps. For example, some steps may be decomposed, while some steps may be combined or partially combined. Therefore, the actual execution order may be changed according to the actual situation.

[0042] The present invention provides a dynamically updated bytecode security protection method, which dynamically enhances the target class in the application by realizing the "hot plug" function of the plug logic, and makes up for the shortcomings of the existing RASP (Runtime Application Self-Protection) technology. Traditional RASP solutions, such as CRASP, are built based on the open source OpenRASP framework, and their detection plug points are statically injected when the application starts, fixed and unchanged, and cannot be flexibly adjusted at runtime. This static injection method is difficult to respond quickly and block new threats in real time when facing unknown vulnerability fields, and there are certain security risks. The "hot plug" mechanism refers to the dynamic insertion, update or removal of detection logic during program operation without downtime, so as to achieve real-time adjustment of security policies. The present invention overcomes the limitations of the existing RASP framework by introducing the "hot plug" mechanism. When the agent program (such as Java Agent) is started, the premain method transfers and caches the plug object for the management and operation of bytecode conversion. At runtime, the plug object can dynamically insert, modify or delete the bytecode of the target class, realize the dynamic update and application of the security detection logic, and flexibly respond to the changing security threats. This design is different from the traditional RASP static detection, so that the detection logic can be loaded or unloaded at any time, which improves the adaptability and security protection capabilities of the system. The agent communicates with the management end, receives the customized security detection logic and plug-in configuration information issued, and uses the bytecode operation library (such as JavaAssist or ASM) to convert these logics into bytecodes and assemble them into a customized class file conversion object. This object inserts the new detection logic into the target class, and the plug-in object is responsible for dynamically modifying the loaded class file to ensure that the new logic takes effect in real time. Through the re-conversion class method of the plug-in object, the bytecode update of the target class is triggered to achieve flexible management of the detection logic. Compared with the static plug-in method of traditional RASP, the "hot plug" technology of the present invention significantly improves the system's response speed to unknown threats, allows dynamic adjustment of security policies, and enhances the real-time protection capabilities of vulnerabilities. Through the method of dynamically updating bytecodes, the present invention realizes the instant deployment of plug-in logic under the RASP framework, ensuring that security detection can be adjusted and effective at any time as needed, greatly improving the protection flexibility and real-time performance of the system.

[0043] like Figure 1 As shown, an embodiment of the present invention provides a dynamically updated bytecode security protection method, comprising the following steps:

[0044] S100, loading the agent program when the security application is started, the agent program obtains and caches the instrumentation object, and saves the instrumentation object to a global variable;

[0045] When the security application is started, the agent program is first loaded. In this embodiment, the agent program selects JavaAgent and is specified by the Java virtual machine (JVM) startup parameters. In the startup phase, the Java Agent will be loaded and its premain method will be started. In this embodiment, the premain method is responsible for initializing the entire security protection process. As a pre-step for the application startup, it ensures that the Java Agent can complete all necessary preparations before the main program code is executed. The Java Agent is closely integrated with the security application environment through the premain method, laying the foundation for subsequent dynamic bytecode operations. After the Java Agent is loaded, a plug-in object is created. In this embodiment, the plug-in object is Instrumentation, which is a component responsible for storing and managing all custom plug-in logic Hooks. During the construction of the Instrumentation object, the relevant bytecode conversion configuration, detection rules, target class and target method information are encapsulated therein. After the Instrumentation object is obtained by the Java Agent, it is cached and saved in a global variable. Through this global cache mechanism, the Instrumentation object can remain valid throughout the life cycle of the security application, avoiding repeated construction and initialization of the plug-in logic each time the bytecode is updated, thereby improving operational efficiency.

[0046] The design of saving the Instrumentation object to a global variable ensures efficient collaboration between the security detection logic of the JavaAgent and the management end, so that the globally cached Instrumentation object can quickly call the corresponding method after receiving a new bytecode conversion configuration to incrementally update the target class and target method.

[0047] In actual implementation, the preservation of the Instrumentation object to a global variable ensures that the Instrumentation object is always available during the application program's execution, and all components in the Java Agent can easily access and call these instrumentation logics. This design allows the Instrumentation object to be safely shared and operated by multiple threads, providing technical support for real-time and bytecode updates in a multi-threaded environment. The above design of the present invention is not limited to a specific Instrumentation object or cache implementation method, and the specific implementation details can be adjusted according to actual needs under different system environments and security requirements.

[0048] S200, the agent receives the security detection logic and plugging configuration information issued by the management end through the communication mechanism with the management end, including the target class, target method and corresponding plugging logic;

[0049] In this embodiment, the communication mechanism between the Java Agent and the management end is implemented through a preset protocol and interface. After the security application is started, the Java Agent will first establish a communication connection with the management end. This connection can ensure the security and integrity of data transmission through a secure transport layer protocol (such as TLS / SSL).

[0050] In some optional embodiments, after the agent program establishes a connection with the management end, the Java Agent will send initial registration information to the management end, and the initial registration information includes the unique identifier, version information, current running status, etc. of the Java Agent. This information is used to identify the instance of the Java Agent, so that the management end can monitor and manage the status of the Java Agent. Through the unique identifier, the management end can push personalized plug-in configuration information and security detection logic for different Java Agent instances, thereby realizing customized security protection for different application environments. The security detection logic includes detection rules for a variety of common vulnerabilities, such as SQL injection detection, command execution detection, deserialization vulnerability detection, cross-site scripting attack (XSS) detection, and file inclusion attack detection. The management end dynamically adjusts the plug-in configuration information based on the real-time status and detection results of the application program, and sends it to the Java Agent through the communication mechanism. The communication mechanism between the Java Agent and the management end uses a periodic heartbeat detection method to maintain the communication connection. The Java Agent will periodically send a heartbeat detection request to the management end to report its current status, including operating parameters such as memory usage and CPU load. The management end can grasp the running status of the Java Agent in real time through the heartbeat information to ensure its stability. When the heartbeat detection request is abnormal or timed out, the management end can recover by restarting, reconnecting, etc. to ensure the continuous operation of the system. During each heartbeat detection, JavaAgent actively requests the management end to pull the latest security detection logic and instrumentation configuration information. When pulling the latest instrumentation configuration information, Java Agent sorts multiple security detection logics based on the policy priority of the management end and inserts them into the target method in order. This "active pull" mechanism ensures that Java Agent can obtain the latest security policies in real time, rather than passively waiting for the push from the management end. Java Agent can update security detection rules and instrumentation logic Hooks in time through the response content of the management end to adapt to new security threats. When Java Agent receives the instrumentation configuration information, it will parse it. The parsing process includes decomposing and identifying the target class, target method, corresponding instrumentation logic Hook and detection rules in the configuration information, and mapping them to the specific location where instrumentation is currently required. Java Agent maintains the parsed information in the instrumentation configuration information list. The instrumentation configuration information list is a dynamic data structure that can be added, deleted, and modified according to actual security requirements. By maintaining the instrumentation configuration information list, Java Agent can effectively manage the application and update of various security detection logics. After obtaining the instrumentation configuration information sent by the management end, Java Agent performs signature verification and integrity verification on the configuration information to ensure the security and credibility of the instrumentation logic Hook.

[0051] The present invention is not limited to the communication mechanism and specific implementation described above. According to different application scenarios and system architectures, the communication mechanism can adopt other transmission protocols, heartbeat detection frequencies and configuration information parsing methods.

[0052] In some optional embodiments, the agent supports the management and compatibility of multi-version plug-in configuration information to ensure that the security protection capability is maintained continuously during the system version iteration process. When the management end sends the plug-in configuration information, the information usually includes the version number, target class, target method, corresponding plug-in logic Hook and corresponding detection rules. After receiving these plug-in configuration information, JavaAgent will classify and store them according to the version number, and maintain the configurations of different versions in a multi-version plug-in configuration information list. This classification storage mechanism ensures that Java Agent can identify and adapt to the configuration requirements of different versions without affecting the existing protection mechanism due to system version updates or changes in detection logic. In order to achieve compatibility with multi-version plug-in configuration information, Java Agent will perform version comparison and verification on the existing plug-in configuration information at startup to ensure compatibility with the current system and application. In the specific implementation, Java Agent can adopt version control strategies, such as timestamps, version number comparisons, and compatibility tags, to ensure compatibility with old versions and adaptation to new versions. Through multi-version management, dynamic adaptation and compatibility control of plug-in configuration information, the present invention ensures that Java Agent can continue to support security protection during system version updates or iterations. This mechanism reduces the security risks caused by system upgrades to a certain extent and ensures the long-term stability and protection capabilities of the system.

[0053] S300, the agent program uses the bytecode operation library to translate the plugging logic sent by the management end into bytecode, and generates a class file conversion object containing the plugging logic;

[0054] In this embodiment, the Java Agent translates the custom plug-in logic Hook issued by the management end into bytecode by using the bytecode operation library, and generates a class file conversion object containing the plug-in logic Hook. In this embodiment, the class file conversion object is ClassFileTransformer. The bytecode operation library is a tool library for dynamically generating and modifying Java bytecode. By modifying the bytecode of the loaded class, the code change at runtime is achieved. This operation does not require modification of the source code, but directly acts on the bytecode level, which has high flexibility and efficiency.

[0055] After receiving the custom instrumentation logic Hook sent by the management end, the Java Agent first parses these instrumentation logic Hooks into an operable form. During this process, the bytecode operation library is called to translate the instrumentation logic Hooks into bytecode instructions that comply with the JVM specification. The result of the translation is a ClassFileTransformer that contains the instrumentation logic Hook. ClassFileTransformer is a structure that describes and controls bytecode changes, encapsulating the instrumentation logic Hook and its application rules.

[0056] In some optional embodiments, the bytecode operation library is JavaAssist or ASM, which is used to dynamically generate and modify Java bytecode. JavaAssist provides an object-oriented API, making the bytecode generation and modification process more intuitive and easy to maintain, and is suitable for high-level operations on bytecodes, such as adding methods, modifying method bodies, etc. ASM is a low-level bytecode operation library that can achieve fine-grained modifications to bytecodes with higher performance, including instruction-level addition, deletion, and modification operations. According to different usage scenarios, Java Agent can select a suitable bytecode operation library to complete the translation and bytecode modification of the plug-in logic Hook.

[0057] The generated bytecode instruction set is encapsulated into a ClassFileTransformer, which is used to describe the data structure of the class structure and bytecode logic changes. In JavaAssist, ClassFileTransformer can be a CtClass object, and in ASM, it is a ClassVisitor or MethodVisitor object. ClassFileTransformer not only contains the original target class information, but also integrates the newly generated instrumentation logic bytecode. Java Agent can modify or enhance the target class by operating ClassFileTransformer.

[0058] The above bytecode operation process is not only applicable to the insertion of detection rules, but also supports more complex operations, such as modifying existing method logic, adding new class members, or deleting unsafe instructions. The present invention uses the bytecode operation library to achieve fine control of the target class, ensuring that the plug-in logic Hook can be quickly and flexibly applied to the running security application.

[0059] In some optional embodiments, the class file conversion object is not limited to simple bytecode insertion operations, but can also perform more complex processing on the target method, such as code insertion, logic modification or instruction deletion. Through code insertion, detection logic can be embedded in any position of the target method to dynamically perform security checks during method execution. Logic modification allows the execution path of existing code to be adjusted, such as redirecting potentially dangerous operations to a safe processing flow. Instruction deletion can remove bytecode instructions that may cause security risks and reduce the risk of vulnerability exploitation. These operations are uniformly managed through class file conversion objects such as ClassFileTransformer and are applied to the runtime environment when the target class is loaded or reloaded.

[0060] It should be noted that the specific implementation of the present invention is not limited to the use of JavaAssist or ASM, and other libraries or frameworks that can implement dynamic bytecode operations are also applicable. The present invention dynamically applies a custom plugging logic Hook to a loaded target class through a bytecode operation library, providing a flexible and efficient bytecode security protection method.

[0061] In some optional embodiments, when the agent uses the bytecode operation library to translate the custom plug-in logic issued by the management end into bytecode, the detection logic is inserted into the bytecode of the target method, so that the input parameter security check is performed in real time when the method is called. Specifically, the translation and insertion process of the plug-in logic Hook includes the following aspects: parameter type check, which is implemented by adding detection logic at the method entrance to ensure that the parameter type passed in is consistent with the expected type, and can prevent the exception or vulnerability caused by type mismatch from being exploited. Length restriction, used to ensure that the length of the input parameter is within a safe range, is embedded in the method entrance through a simple conditional statement to detect whether the length of the input parameter exceeds the preset threshold, thereby blocking potential overflow attacks at the first time. Regular expression matching, used to screen and filter input data that does not conform to the expected format, through the dynamic insertion of bytecode, the regular expression verification logic is attached to the context of the method call, and the input parameters are matched and checked in real time to prevent malicious strings or parameters in illegal formats from passing the detection. Illegal character filtering, by detecting and processing special characters or sensitive symbols in the input parameters, this filtering logic can prevent common attack vectors such as SQL injection, XSS attacks, etc. The implementation of these detection and verification logics relies on the bytecode operation library to translate the plug-in logic Hook sent by the management end into executable bytecode and dynamically insert it into the target method. Each detection mechanism can be configured and optimized according to actual security requirements to deal with different types of security risks. These plug-in logic Hooks take effect in real time during program operation without restarting the application or redeploying it, which greatly improves the flexibility and response speed of security protection.

[0062] S400, registering the class file conversion object into the plug-in object, and calling the re-conversion class method of the plug-in object to update the bytecode of the target class, so as to realize the dynamic insertion of the plug-in logic;

[0063] In the present invention, ClassFileTransformer is registered in the Instrumentation object, and the retransformation class method of the Instrumentation object is called to update the bytecode of the loaded target class. In this embodiment, the retransformation class method is set to the retransformClasses method of the Instrumentation object, which makes full use of the bytecode conversion capability provided by the Java Instrumentation API, so that the runtime class can be dynamically modified without stopping the application to insert new security detection logic.

[0064] Specifically, ClassFileTransformer is generated by a bytecode manipulation library (such as JavaAssist or ASM) and contains custom bytecode instrumentation logic. When the ClassFileTransformer is registered with the Instrumentation object, the instrumentation logic Hook is bound to the bytecode transformation process of the target class. The role of the Instrumentation object is to manage and maintain these ClassFileTransformers and trigger bytecode updates at the appropriate time. When the loaded target class needs to be updated, the Java Agent calls the retransformClasses method of the Instrumentation object. This method uses the retransformClasses function in the Java Instrumentation API to retransform the loaded classes without restarting the application or reloading all classes. This process allows dynamic modification of existing bytecodes so that new detection logic can take effect immediately. The retransformation class method of the instrumentation API of the instrumentation object, namely the retransformClasses method, supports batch bytecode updates for multiple methods of the target class, allowing multiple loaded classes to be retransformed at one time instead of operating class by class. By merging the update tasks of multiple target classes into a single call, the overhead caused by frequent calls to the conversion method is reduced, thereby greatly improving the operation efficiency.

[0065] In some optional embodiments, the retransformation class method of the instrumentation object updates the bytecode of the target class in an incremental modification manner. That is, the functions supported by the retransformClasses function are used, and the existing bytecode of the target class is not completely replaced, but a partial modification is made on the existing basis. The incremental modification method helps to maintain the structure and logic of the original code and avoid performance problems or system instability that may be caused by full replacement. The specific incremental modification process includes analyzing and locating the original bytecode of the target class, and determining the bytecode position that needs to be modified or inserted according to the instrumentation logic Hook. Then, the new bytecode instructions in the ClassFileTransformer are inserted into the corresponding position. This method not only reduces the impact on system performance, but also can accurately control the scope of modification to ensure that other unrelated code logic is not affected. In order to achieve this process, the Instrumentation object usually maintains a bytecode transformation chain, and each chain node represents a ClassFileTransformer to be applied. When the retransformClasses method is called, the Instrumentation object traverses the bytecode transformation chain in order and makes incremental modifications to the target class step by step. This chain conversion mechanism ensures that different instrumentation logic Hooks can be executed in order, and specific instrumentation logic Hooks can be easily added or removed when needed.

[0066] In this embodiment, the combination of the Instrumentation object and the ClassFileTransformer can be adjusted according to the specific application scenario and is not limited to a specific implementation form. For example, the Instrumentation object can use other bytecode modification tools or mechanisms, and the calling conditions and timing of the retransformClasses method can also be optimized according to the needs of the system to adapt to different types of security detection and protection logic.

[0067] S500, the updated bytecode takes effect immediately, detecting and protecting security vulnerabilities in the target method in real time.

[0068] In this embodiment, based on the bytecode dynamic instrumentation technology, the security detection logic is directly embedded into the execution path of the target method by modifying the bytecode of the target class in real time when the program is running. This embodiment enables the application to dynamically insert or update the security protection logic without restarting or reloading all classes, effectively responding to rapidly changing security threats. Specifically, when the Java Agent completes the bytecode update through the retransformClasses method of the Instrumentation object, the execution behavior of the target class will be immediately controlled by the updated bytecode. The bytecode update uses the bytecode conversion function provided by the Java Instrumentation API, combined with the custom ClassFileTransformer, to embed the security detection logic issued by the management end into the target class. This embedding method allows the new logic to be intercepted, verified and recorded at the entrance, key logic node, or exit of the target method, thereby realizing real-time detection and protection of potential vulnerabilities. In the specific implementation, the updated bytecode will be directly loaded into the running instance of the target class, which means that the latest logic will be executed immediately when the target method is called next time. This immediacy relies on the dynamic modification mechanism of the Java virtual machine for loaded classes, allowing the bytecode of the class to be redefined while the application is running. This mechanism does not require reloading the application and can retain the current application state and context information, so that the impact of bytecode updates is limited to the modified classes and methods. The incremental modification of the target class through the retransformClasses method is implemented in real time, making the new plug-in logic Hook almost instantaneous. The newly inserted logic can be a code snippet for detecting security vulnerabilities, such as validating the legitimacy of input parameters, capturing abnormal behavior, or recording logs of suspicious operations. The implementation of these logics is usually to generate the corresponding bytecode instructions through the bytecode operation library, and insert these instructions into the appropriate position of the target method through ClassFileTransformer.

[0069] In some optional embodiments, the updated bytecode can adjust the update frequency or content according to the management end policy. For example, for high-risk target methods, a higher frequency bytecode update strategy can be set to achieve more sensitive real-time protection; for scenarios with different security detection requirements, the content of ClassFileTransformer can also be dynamically adjusted to load the corresponding detection rules and processing logic.

[0070] The real-time and flexibility in the above process are derived from the dynamic plugging architecture and its implementation of the present invention. The update, registration, and validation of the plugging logic Hook are all completed in real time when the program is running. This mechanism enables the system to respond quickly to new security threats without downtime or large-scale system upgrades.

[0071] In some optional embodiments, the security detection logic is designed for different vulnerability features and embedded in the key methods or logic of the target application in the form of bytecode to achieve protection against different attack scenarios. Specifically, in SQL injection detection, the security detection logic monitors the execution of SQL queries by inserting code. Java Agent inserts detection code into the target method to verify the legitimacy of the input parameters of the SQL statement, such as checking whether it contains illegal SQL keywords or special symbols, to avoid unfiltered user input being directly embedded in the SQL query. For command execution detection, the plug-in logic Hook monitors the behavior of external command calls in the application, such as where the system command line or script is called. The detection rules are dynamically inserted into the method for executing commands, and malicious commands are prevented from being executed by detecting the format, content or keywords of the incoming commands. Java Agent inserts the bytecode of the detection logic into these methods, intercepts and checks before the command is executed, and determines whether there is a security risk. This security detection logic can be implemented in the database access layer of the target class, and the security check code is embedded in the key method through the bytecode operation library to achieve effective detection of SQL injection. Deserialization vulnerability detection logic acts on the deserialization method to prevent malicious use when the application processes untrusted data. The instrumentation logic Hook adds check code at the deserialization entry to ensure that the source of the data is credible or the format is legal. The detection code can restrict the type of input objects or intercept untrusted data streams to avoid dangerous deserialization operations. Cross-site scripting attack detection logic is usually inserted into methods related to user input and output to detect and filter inputs that may contain malicious scripts. Detection rules can filter or encode input content to prevent unfiltered scripts from being injected into web pages or application interfaces. Through dynamic bytecode insertion, the detection code can monitor and modify input and output content in real time to prevent cross-site scripting attacks from occurring. File inclusion attack detection logic targets the file loading and access operations of the application, and prevents malicious files from being introduced or executed by detecting the loaded file path or content. The instrumentation logic Hook adds path legitimacy checks to the file operation method to prevent users from including or executing arbitrary files by entering malicious paths. This security detection logic is embedded through dynamic instrumentation technology to verify the path and file content before file operations. The detection rules issued by the management end are translated into bytecode through the bytecode operation library and dynamically inserted into the runtime environment of the application. Java Agent binds different detection logics with corresponding target classes and methods according to the plug-in configuration information, thereby achieving coverage and response of multiple security detection scenarios. The security detection logic and rules in the present invention are not limited by specific vulnerability types, detection algorithms or application structures, and can be dynamically adjusted or expanded according to security requirements and risk assessments.The way the detection logic is inserted can also be optimized according to the target environment to meet different performance and security requirements.

[0072] In some optional embodiments, the agent saves a snapshot of the current bytecode state before each bytecode update to ensure that it can be quickly rolled back to the original state when an error or failure occurs during the instrumentation process. The implementation of this mechanism relies on the comprehensive capture and storage of the bytecode of the target class, and combines the control of the bytecode update operation by the Java Agent to ensure the security and stability of the instrumentation operation. Specifically, when the Java Agent is ready to execute the bytecode update, it will first call the corresponding snapshot saving logic to back up the bytecode state of the currently running target class. The backup usually includes all existing bytecode instructions of the target class, class structure information (such as method signatures, field declarations, etc.) and context data that the current instrumentation logic Hook depends on. The snapshot data can be stored in memory or persisted in an external storage device so that it can be quickly retrieved and restored when a rollback is required. The snapshot saving of the bytecode state is implemented by combining the Instrumentation API with the bytecode operation library. During the snapshot saving process, the Java Agent will dynamically read the bytecode content of the target class and translate it into a format that is easy to store and process, such as a byte array or a serialized object. When the instrumentation update is executed, the Java Agent will detect the execution status of the instrumentation logic Hook; if an exception is detected or the instrumentation fails, the Java Agent will use the previously saved snapshot data to call the bytecode recovery mechanism of Instrumentation to roll back the target class to the state before the update, thereby avoiding program crashes or functional abnormalities caused by instrumentation errors. In addition, the snapshot mechanism not only saves the bytecode of the class, but also may involve saving the current instrumentation configuration state of the Java Agent, including the applied instrumentation logic Hook, the location information of the instrumentation point, and related detection rules. This information is restored together in the rollback operation to ensure that the overall state of the system returns to a safe and stable operating state. The snapshot and rollback mechanism can provide an efficient error repair path with extremely low performance overhead. The Java Agent can quickly recover to a safe operating environment after the bytecode update fails, without affecting the normal function of the application. This "safety guarantee" layer design of dynamic instrumentation makes the instrumentation operation more controllable and reliable in various complex operating environments. The snapshot saving and rollback mechanism of the present invention is not limited to a specific implementation method, and the snapshot saving format, storage location and rollback logic can be adjusted and optimized according to actual application requirements. The flexibility and configurability of this mechanism enable the present invention to adapt to a variety of bytecode update scenarios and enhance the robustness of dynamic updates of security detection logic.

[0073] In the dynamically updated bytecode security protection method of this embodiment, the serial number of each step is only used to distinguish the steps, and is not used as a limitation on the specific execution order of the steps. The execution order between the above steps can be adjusted and changed as needed.

[0074] like Figure 2 As shown, an embodiment of the present invention further provides a dynamically updated bytecode security protection system, which is used to implement the dynamically updated bytecode security protection method as described above, and the system includes:

[0075] The management terminal M100 is used to generate protection strategies and issue them in the form of bytecode. Specifically, the management terminal M100 supports the formulation of corresponding protection strategies by analyzing vulnerability information and system operation status. These protection strategies usually include detection rules for specific vulnerability types, plug-in logic hooks and their configuration information. The management terminal M100 sends the bytecode to the agent terminal through the communication channel with the agent terminal. This design of the management terminal allows security protection strategies to be quickly iterated and issued according to security requirements, achieving rapid response and protection against new vulnerabilities.

[0076] The agent terminal M200 is deployed in the security application as the execution carrier of the security protection strategy. It includes an instrumentation object, which receives the security detection logic and instrumentation configuration information issued by the management end through the instrumentation object, and can dynamically modify the bytecode of the target class when the application is running. The agent terminal converts the security detection logic issued by the management end into bytecode operation instructions, and dynamically updates the bytecode of the target class through the re-conversion class method of the instrumentation object. Such dynamic updates can realize operations such as inserting, modifying or deleting the security detection logic of the target method, so that the system can respond to and protect against various security threats in real time. The functions of each module of the dynamically updated bytecode security protection system can be implemented using the specific implementation method of the dynamically updated bytecode security protection method as described above, which will not be repeated here.

[0077] The functions of each module of the dynamically updated bytecode security protection program product of the present invention can be implemented by using the specific implementation method of the dynamically updated bytecode security protection method as described above, which will not be described in detail here.

[0078] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A dynamically updated bytecode security protection method, characterized in that: The steps include: The agent program is loaded when the security application is started, the agent program obtains and caches the instrumentation object, and saves the instrumentation object to a global variable; The agent receives the security detection logic and instrumentation configuration information sent by the management end through the communication mechanism with the management end, including the target class, target method and corresponding instrumentation logic; The agent uses the bytecode operation library to translate the instrumentation logic sent by the management end into bytecode and generate a class file conversion object containing the instrumentation logic; Register the class file conversion object to the instrumentation object, and call the reconversion class method of the instrumentation object to update the bytecode of the target class to achieve dynamic insertion of the instrumentation logic; The updated bytecode takes effect immediately, detecting and protecting against security vulnerabilities in target methods in real time.

2. The dynamically updated bytecode security protection method according to claim 1, characterized in that: The implementation of the communication mechanism between the agent program and the management end includes the following steps: After the agent program establishes a communication connection with the management end, the agent program sends initial registration information to the management end, including the unique identification of the agent program, version information and current running status; The agent program periodically sends heartbeat detection requests to the management end to maintain the communication connection and report its own status; During each heartbeat detection, the agent actively requests the management end to pull the latest security detection logic and instrumentation configuration information; After receiving the instrumentation configuration information, the agent parses it, maps the configuration information to the target class, target method and corresponding instrumentation logic that need to be instrumented, and maintains the instrumentation configuration information list.

3. The dynamically updated bytecode security protection method according to claim 1, characterized in that: The re-conversion class method of the instrumented object performs bytecode update on the target class and is configured as the re-conversion class method performs incremental modification on the existing bytecode of the target class.

4. The dynamically updated bytecode security protection method according to claim 1, characterized in that: The class file conversion object is configured to perform code insertion, logic modification or instruction deletion on the target method.

5. The dynamically updated bytecode security protection method according to claim 1, characterized in that: The bytecode operation library is configured as JavaAssist or ASM, which is used to dynamically generate and modify Java bytecodes.

6. The dynamically updated bytecode security protection method according to claim 1, characterized in that: The security detection logic includes at least one of the following detection rules: SQL injection detection, command execution detection, deserialization vulnerability detection, cross-site scripting attack (XSS) detection, and file inclusion attack detection.

7. The dynamically updated bytecode security protection method according to claim 1, characterized in that: When the agent program uses the bytecode operation library to translate the custom plug-in logic sent by the management end into bytecode, the input parameters of the target method are verified, including parameter type checking, length restriction, regular expression matching and illegal character filtering.

8. The dynamically updated bytecode security protection method according to claim 1, characterized in that: The agent program saves a snapshot of the current bytecode state before each bytecode update.

9. A dynamically updated bytecode security protection system, characterized in that: A bytecode security protection method for implementing dynamic updates according to any one of claims 1 to 8, the system comprising: The management end is used to generate and apply protection strategies; The agent side, deployed in the security application, receives the security detection logic and instrumentation configuration information issued by the management side through the instrumentation object, and dynamically updates the bytecode of the target class.

10. A dynamically updated bytecode security protection program product, characterized in that: The program product includes computer instructions, which, when executed by a processor, implement the steps of the dynamically updated bytecode security protection method described in any one of claims 1 to 8.

Images