Method and device for detecting deserialization vulnerabilities, equipment and medium

By analyzing the data in the request package to detect deserialization vulnerabilities, the problem of long periods of defense against deserialization vulnerabilities in the existing technology is solved, real-time detection is achieved and the protection capabilities of information security and network security are improved.

CN119788315APending Publication Date: 2025-04-08CHINA TELECOM CLOUD TECH CO LTD
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
CN202411716303.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-27
Publication Date
2025-04-08

AI Technical Summary

Technical Problem

The existing technology has a long period of defense against deserialization vulnerabilities through black and white listings, which cannot meet the needs of information security and network security.

Method used

By parsing the data in the request packet, detecting whether it is deserialized data. If it is deserialized data, infer whether the request packet carries serialized data, thereby determining whether there is a deserialization vulnerability.

Benefits of technology

Real-time detection of deserialization vulnerabilities is realized, avoiding the problem of long black and white list update cycles, and improving the protection reliability and stability of information security and network security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119788315A_ABST
    Figure CN119788315A_ABST
Patent Text Reader

Abstract

The embodiment of the invention discloses a method and device for detecting deserialization vulnerabilities, equipment and a medium, and aims to solve the technical problems that the period of defending the deserialization vulnerabilities in a black and white list mode is long and the requirements of information security and network security cannot be met in the prior art. The method comprises the following steps: under the condition that a request packet is received, analyzing the request packet to obtain analysis data; detecting whether the analysis data is deserialized data or not, and obtaining a detection result; and obtaining a first deserialization vulnerability detection result according to the detection result.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present application relate to the field of communications, and in particular to a method, apparatus, device, and medium for detecting a deserialization vulnerability. Background Art

[0002] Serialization and deserialization are common concepts in computer programming, and they are closely related to data storage and network communication. Serialization refers to the process of converting the state information of an object into a form that can be stored or transmitted. This form is usually in binary format, or it can be a text format such as JavaScript Object Notation (JSON) or eXtensible Markup Language (XML). Serialization allows complex objects to be converted into a format so that they can be persisted in files, databases, or transmitted to other computer systems over the network. Deserialization is the reverse process of serialization, which is the process of converting serialized data (usually a byte stream) back into an object.

[0003] Deserialization vulnerability is a common security vulnerability. Attackers can use specific code snippets or functions (Gadgets) to construct malicious serialized data and execute arbitrary code or commands when the application deserializes this data.

[0004] The existing methods for defending against deserialization vulnerabilities mainly include setting blacklists and whitelists to intercept and filter dangerous functions to shield gadgets. However, the release and update cycle of blacklists and whitelists is long, which cannot meet the needs of information security and network security. Summary of the invention

[0005] The embodiments of the present application provide a method, apparatus, device and medium for detecting deserialization vulnerabilities to solve the technical problem that the prior art uses a blacklist and whitelist method to defend against deserialization vulnerabilities for a long period of time and cannot meet the needs of information security and network security.

[0006] In a first aspect, an embodiment of the present application provides a method for detecting a deserialization vulnerability, the method comprising:

[0007] When receiving a request packet, parsing the request packet to obtain parsed data;

[0008] Detect whether the parsed data is deserialized data, and obtain a detection result;

[0009] A first deserialization vulnerability detection result is obtained according to the detection result.

[0010] In a second aspect, an embodiment of the present application provides a device for detecting a deserialization vulnerability, the device comprising:

[0011] A parsing module, used for parsing the request packet and obtaining parsed data when receiving the request packet;

[0012] A detection module, used to detect whether the parsed data is deserialized data and obtain a detection result;

[0013] The first deserialization vulnerability detection module is used to obtain a first deserialization vulnerability detection result according to the detection result.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; a storage device on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any embodiment of the first aspect.

[0015] In a fourth aspect, an embodiment of the present application provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any embodiment of the first aspect.

[0016] The method, device, equipment and medium for detecting deserialization vulnerabilities provided in the embodiments of the present application can detect request packets, and determine whether there is a deserialization vulnerability based on the detection result of whether the parsed data obtained after parsing the request packet is deserialized data, that is: based on whether the parsed data is deserialized data, it can be inferred whether the request packet carries serialized data, thereby determining whether there is a deserialization vulnerability. Since the request packet is sent in real time, the technical solution provided by this embodiment can detect deserialization vulnerabilities in real time, avoiding the technical problem that the prior art uses a black and white list method to defend against deserialization vulnerabilities for a long period of time and cannot meet the needs of information security and network security. In addition, by detecting whether the parsed data is deserialized data to detect deserialization vulnerabilities, the implementation is simple, the detection process and detection time are shortened, the deserialization detection and protection efficiency are improved, and the protection reliability and stability of information security and network security are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0018] Figure 1 It is one of the flow charts of an embodiment of the method for detecting deserialization vulnerabilities of the present application;

[0019] Figure 2 yes Figure 1 The flowchart of step 102 in the method for detecting deserialization vulnerabilities of the present application is shown;

[0020] Figure 3 This is the second flowchart of an embodiment of the method for detecting deserialization vulnerabilities of the present application;

[0021] Figure 4 yes Figure 3 The flowchart of step 105 in the method for detecting deserialization vulnerabilities of the present application is shown;

[0022] Figure 5 This is one of the structural schematic diagrams of an embodiment of the device for detecting deserialization vulnerabilities of the present application;

[0023] Figure 6 This is the second structural diagram of an embodiment of the device for detecting deserialization vulnerabilities of the present application;

[0024] Figure 7 It is a schematic diagram of the structure of an electronic device used to implement an embodiment of the present application. DETAILED DESCRIPTION

[0025] All actions to obtain signals, information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where they are located, and with the authorization given by the owner of the corresponding device.

[0026] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It should also be noted that, for ease of description, only the parts related to the relevant invention are shown in the accompanying drawings.

[0027] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0028] Please refer to Figure 1 , which shows a process 100 of an embodiment of a method for detecting a deserialization vulnerability according to the present application. The method for detecting a deserialization vulnerability can be applied to various electronic devices with data processing functions. For example, the above electronic devices may include but are not limited to cloud servers, physical servers, etc. The execution subject of the automatic discovery method of the topological relationship may be a processor in the above electronic device.

[0029] like Figure 1 As shown, the method for detecting a deserialization vulnerability includes the following steps:

[0030] Step 101: When a request packet is received, the request packet is parsed to obtain parsed data.

[0031] In this embodiment, the request packet is used as a carrier of data transmission, and can transmit data from the sending end to the receiving end. The data may include a serialized object, which is usually a byte stream, and the byte stream contains all or part of the state information of the original object.

[0032] During the deserialization attack, the attacker can serialize the malicious code to generate a data stream, and send the data stream to the receiving end in the request packet, thereby realizing a remote deserialization attack.

[0033] Step 102: Detect whether the parsed data is deserialized data, and obtain the detection result.

[0034] In this embodiment, if Figure 2 As shown, step 102 may include:

[0035] Step 201: Detect the flag bit of the parsed data and obtain the flag bit data.

[0036] In this embodiment, the flag bit is specifically a bit that can uniquely identify the deserialized data. This embodiment takes the flag bit as the first two bytes of the parsed data as an example for explanation. In actual use, the flag bit can also be other bits that can uniquely identify the deserialized data. Each case will not be described one by one here.

[0037] Step 202: Determine whether the parsed data is deserialized data according to the flag data, and obtain the detection result.

[0038] In this embodiment, step 202 can be implemented by the following steps:

[0039] When the flag data is a magic method number, the detection result is that the parsed data is deserialized data, wherein the magic method number is ACED in hexadecimal.

[0040] Otherwise, the detection result is that the parsed data is not deserialized data.

[0041] In this embodiment, the deserialized data format mainly includes four parts:

[0042] 1. Magic Number

[0043] The deserialized data begins with a two-byte magic number, which is always hexadecimal "ACED". The magic number is used to identify whether the data stream is valid serialized data and to help the parser determine how to parse subsequent data.

[0044] 2. Version number

[0045] Following the magic number is a two-byte version number. The version number is used to indicate the version of the serialized data. Different versions may have different data structures and parsing methods. During the deserialization process, the version number helps ensure the compatibility and correctness of the data.

[0046] 3. Class name and member variable type and number

[0047] After the version number, the class name, the type and number of member variables are usually included. This information is used to reconstruct the original object during the deserialization process. The class name is used to determine the class to be instantiated, and the type and number of member variables are used to initialize the properties of the object.

[0048] 4. Actual Data

[0049] Finally, the actual data content is parsed and assigned according to the class name and the type and number of member variables. The data content can be basic data types, object references, arrays, etc., depending on the structure and content of the serialized object.

[0050] According to the above deserialized data format, step 102 can accurately detect whether the parsed data is deserialized data by detecting whether the identification bit data of the parsed data is a magic method number (specifically, hexadecimal ACED) to obtain the detection result.

[0051] Of course, the above is only a specific example. In the actual application process, with the continuous development and progress of technology, the position of the identification bit used to uniquely identify the deserialized data may also change, and the specific value of the magic method number corresponding to the identification bit data may also change. However, those skilled in the art should understand that no matter how the changes occur, step 102 can accurately detect whether the parsed data is the deserialized data by detecting whether the identification bit data of the parsed data is the magic method number to obtain the detection result.

[0052] Step 103: Obtain a first deserialization vulnerability detection result according to the detection result.

[0053] In this embodiment, when the detection result is that the parsed data is deserialized data, the first deserialization vulnerability detection result is: there is a deserialization vulnerability; otherwise, the first deserialization vulnerability detection result is: there is no deserialization vulnerability.

[0054] The method for detecting deserialization vulnerabilities provided in the embodiment of the present application can detect the request packet, and determine whether there is a deserialization vulnerability based on the detection result of whether the parsed data obtained after parsing the request packet is deserialized data, that is: based on whether the parsed data is deserialized data, it can be inferred whether the request packet carries serialized data, thereby determining whether there is a deserialization vulnerability. Since the request packet is sent in real time, the technical solution provided by this embodiment can detect deserialization vulnerabilities in real time, avoiding the technical problem that the prior art uses a black and white list method to defend against deserialization vulnerabilities for a long period of time and cannot meet the needs of information security and network security. In addition, by detecting whether the parsed data is deserialized data to detect deserialization vulnerabilities, the implementation is simple, the detection process and detection time are shortened, the deserialization detection and protection efficiency are improved, and the protection reliability and stability of information security and network security are improved.

[0055] like Figure 3 As shown, an embodiment of the present invention also provides a method 100 for detecting a deserialization vulnerability. Figure 1 The method is basically the same as shown, except that, when the first deserialization vulnerability detection result is that a deserialization vulnerability exists, the method may further include:

[0056] Step 104: Detect the response packet to obtain class definition information of the data stream.

[0057] In this embodiment, the response packet corresponds to the request packet received in step 101 .

[0058] Step 105: Obtain a second deserialization vulnerability detection result according to the class definition information.

[0059] In this embodiment, if Figure 4 As shown, step 105 may specifically include:

[0060] Step 401: Use a deserialization method to obtain the name and serialization version number of the class in the class definition information.

[0061] In this embodiment, the response packet may carry a deserialization method, wherein the deserialization method may be a readObject method of the ObjectInputStream class in a Java program.

[0062] In this embodiment, step 401 may use the readObject method to read the class object (class definition information) of the data stream in the response packet, then its ObjectStreamClass descriptor will be read, and the name and serialized version number (serialVersionUID) of the corresponding class will be returned.

[0063] Step 402: Obtain a second deserialization vulnerability detection result according to the class name and the serialization version number.

[0064] In this embodiment, the name of the class is mainly used to identify the class of the serialized object (data stream). When deserializing, the Java virtual machine (JVM) uses this name to determine which class of object the data stream should be converted back to.

[0065] In this embodiment, serialVersionUID is a unique identifier used to verify whether the class versions of the sender and the receiver are consistent during the deserialization process.

[0066] The class name and serialVersionUID together ensure the accuracy and consistency of serialization and deserialization, and prevent data inconsistency caused by changes in class definitions.

[0067] According to the above content, it can be seen that the technical solution provided by this embodiment achieves Figure 1 Based on the beneficial effects brought by the technical solution shown, the response packet can be further tested to accurately determine whether the serialized data (i.e., data stream) contained in the response packet has a deserialization vulnerability based on the class name and serialization version number, thereby further improving the accuracy and reliability of deserialization vulnerability detection.

[0068] In this embodiment, Figure 1-4 The method for detecting deserialization vulnerabilities provided in the embodiment shown can be deployed on a Web Application Firewall (WAF) in a bypass deployment or a main deployment mode. The WAF performs deserialization vulnerability protection operations according to pre-set defense rules.

[0069] In this embodiment, when the deployment mode is bypass deployment, even if a deserialization vulnerability is detected, the normal network communication can be guaranteed. This solution can be used in an environment with less threat of network attacks, and while detecting deserialization vulnerabilities, the normal network communication is prioritized.

[0070] In this embodiment, when the deployment mode is main deployment, once a deserialization vulnerability is detected, WAF can perform deserialization vulnerability protection operations according to the pre-set defense rules, such as intercepting request packets or not returning response packets, etc. This solution can be used in environments with high network attack threats, to ensure the security of network communications to a limited extent, and to avoid attacks such as remote code execution and data tampering caused by deserialization vulnerabilities.

[0071] Please refer to Figure 5As an implementation of the methods shown in the above figures, the present application provides an embodiment of a device for detecting a deserialization vulnerability. Figure 1 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0072] like Figure 5 As shown, the device 500 for detecting a deserialization vulnerability in this embodiment includes:

[0073] The parsing module 501 is used to parse the request packet and obtain parsed data when receiving the request packet.

[0074] In this embodiment, the request packet is used as a carrier of data transmission, and can transmit data from the sending end to the receiving end. The data may include a serialized object, which is usually a byte stream, and the byte stream contains all or part of the state information of the original object.

[0075] During the deserialization attack, the attacker can serialize the malicious code to generate a data stream, and send the data stream to the receiving end in the request packet, thereby realizing a remote deserialization attack.

[0076] The detection module 502 is used to detect whether the parsed data is deserialized data and obtain a detection result.

[0077] The first deserialization vulnerability detection module 503 is used to obtain a first deserialization vulnerability detection result according to the detection result.

[0078] Optionally, the detection module 502 is specifically used to detect a flag bit of the parsed data and obtain the flag bit data; determine whether the parsed data is deserialized data according to the flag bit data, and obtain a detection result.

[0079] In this embodiment, the flag bit is specifically a bit that can uniquely identify the deserialized data. This embodiment takes the flag bit as the first two bytes of the parsed data as an example for explanation. In actual use, the flag bit can also be other bits that can uniquely identify the deserialized data. Each case will not be described one by one here.

[0080] Optionally, the flag bit is the first two bytes of the parsed data, and the detection module 502 is specifically used to, when the flag bit data is a magic method number, the detection result is that the parsed data is deserialized data, wherein the magic method number is hexadecimal ACED; otherwise, the detection result is that the parsed data is not deserialized data.

[0081] In this embodiment, the deserialized data format mainly includes four parts:

[0082] 1. Magic Number

[0083] The deserialized data begins with a two-byte magic number, which is always hexadecimal "ACED". The magic number is used to identify whether the data stream is valid serialized data and to help the parser determine how to parse subsequent data.

[0084] 2. Version number

[0085] Following the magic number is a two-byte version number. The version number is used to indicate the version of the serialized data. Different versions may have different data structures and parsing methods. During the deserialization process, the version number helps ensure the compatibility and correctness of the data.

[0086] 3. Class name and member variable type and number

[0087] After the version number, the class name, the type and number of member variables are usually included. This information is used to reconstruct the original object during the deserialization process. The class name is used to determine the class to be instantiated, and the type and number of member variables are used to initialize the properties of the object.

[0088] 4. Actual Data

[0089] Finally, the actual data content is parsed and assigned according to the class name and the type and number of member variables. The data content can be basic data types, object references, arrays, etc., depending on the structure and content of the serialized object.

[0090] According to the above deserialized data format, the detection module 502 can accurately detect whether the parsed data is deserialized data by detecting whether the identification bit data of the parsed data is a magic method number (specifically, ACED in hexadecimal) to obtain the detection result.

[0091] Of course, the above are only specific examples. In actual application, with the continuous development and advancement of technology, the position of the identification bit used to uniquely identify the deserialized data may also change, and the specific value of the magic method number corresponding to the identification bit data may also change. However, those skilled in the art should understand that no matter how the changes occur, the detection module 502 can accurately detect whether the parsed data is deserialized data and obtain the detection result by detecting whether the identification bit data of the parsed data is the magic method number.

[0092] The device for detecting deserialization vulnerabilities provided in the embodiment of the present application can detect request packets, and determine whether there is a deserialization vulnerability based on the detection result of whether the parsed data obtained after parsing the request packet is deserialized data, that is: based on whether the parsed data is deserialized data, it can be inferred whether the request packet carries serialized data, thereby determining whether there is a deserialization vulnerability. Since the request packet is sent in real time, the technical solution provided by this embodiment can detect deserialization vulnerabilities in real time, avoiding the technical problem that the prior art uses a black and white list method to defend against deserialization vulnerabilities for a long period of time and cannot meet the needs of information security and network security. In addition, by detecting whether the parsed data is deserialized data to detect deserialization vulnerabilities, the implementation is simple, the detection process and detection time are shortened, the deserialization detection and protection efficiency are improved, and the protection reliability and stability of information security and network security are improved.

[0093] like Figure 6 As shown, an embodiment of the present invention further provides a device 500 for detecting a deserialization vulnerability. Figure 5 The device is substantially the same as shown, except that the device further comprises:

[0094] The acquisition module 504 is used to detect the response packet and acquire the class definition information of the data stream when the first deserialization vulnerability detection result is that a deserialization vulnerability exists, wherein the response packet corresponds to the request packet.

[0095] The second deserialization vulnerability detection module 505 is used to obtain a second deserialization vulnerability detection result according to the class definition information.

[0096] In this embodiment, the second deserialization vulnerability detection module 505 is specifically used to obtain the name and serialization version number of the class in the class definition information by using a deserialization method; and obtain a second deserialization vulnerability detection result according to the name of the class and the serialization version number.

[0097] In this embodiment, the response packet may carry a deserialization method, wherein the deserialization method may be a readObject method of the ObjectInputStream class in a Java program.

[0098] In this embodiment, the second deserialization vulnerability detection module 505 can use the readObject method to read the class object (class definition information) of the data stream in the response packet, then its ObjectStreamClass descriptor will be read and the corresponding class name and serialization version number (serialVersionUID) will be returned.

[0099] In this embodiment, the name of the class is mainly used to identify the class of the serialized object (data stream). When deserializing, the Java virtual machine (JVM) uses this name to determine which class of object the data stream should be converted back to.

[0100] In this embodiment, serialVersionUID is a unique identifier used to verify whether the class versions of the sender and the receiver are consistent during the deserialization process.

[0101] The class name and serialVersionUID together ensure the accuracy and consistency of serialization and deserialization, and prevent data inconsistency caused by changes in class definitions.

[0102] According to the above content, it can be seen that the technical solution provided by this embodiment achieves Figure 5 Based on the beneficial effects brought by the technical solution shown, the response packet can be further tested to accurately determine whether the serialized data (i.e., data stream) contained in the response packet has a deserialization vulnerability based on the class name and serialization version number, thereby further improving the accuracy and reliability of deserialization vulnerability detection.

[0103] In this embodiment, Figure 5 and 6 The device for detecting deserialization vulnerabilities provided in the embodiment shown can be deployed on a network application firewall (WAF) in a bypass deployment or a main deployment mode. The WAF performs deserialization vulnerability protection operations according to pre-set defense rules.

[0104] In this embodiment, when the deployment mode is bypass deployment, even if a deserialization vulnerability is detected, the normal network communication can be guaranteed. This solution can be used in an environment with less threat of network attacks, and while detecting deserialization vulnerabilities, the normal network communication is prioritized.

[0105] In this embodiment, when the deployment mode is main deployment, once a deserialization vulnerability is detected, WAF can perform deserialization vulnerability protection operations according to the pre-set defense rules, such as intercepting request packets or not returning response packets, etc. This solution can be used in environments with high network attack threats, to ensure the security of network communications to a limited extent, and to avoid attacks such as remote code execution and data tampering caused by deserialization vulnerabilities.

[0106] Reference below Figure 7 , which shows a schematic structural diagram of an electronic device for implementing some embodiments of the present application. Figure 7The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0107] like Figure 7 As shown, the electronic device 700 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the electronic device 700 are also stored. The processing device 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0108] Typically, the following devices may be connected to the I / O interface 705: an input device 706 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 707 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 708 including, for example, a disk, a hard disk, etc.; and a communication device 709. The communication device 709 may allow the electronic device 700 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 7 The electronic device 700 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead. Figure 4 Each block shown in the figure may represent one device, or may represent multiple devices as required.

[0109] In particular, according to some embodiments of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, some embodiments of the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In some such embodiments, the computer program can be downloaded and installed from the network through the communication device 709, or installed from the storage device 708, or installed from the ROM 702. When the computer program is executed by the processing device 701, the above-mentioned functions defined in the method of some embodiments of the present application are executed.

[0110] It should be noted that the computer-readable medium described in some embodiments of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In some embodiments of the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In some embodiments of the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0111] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0112] The computer-readable medium may be included in the electronic device; or it may exist independently without being installed in the electronic device. The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: upon receiving a message sending request, obtains the message to be tested in the message sending request; extracts the text content in the message to be tested; detects the text content based on the keywords of historical spam messages, the hash values ​​of historical spam messages, and the large language model to determine whether the message to be tested is a spam message; and intercepts the message to be tested in response to the message to be tested being a spam message.

[0113] Computer program code for performing the operations of some embodiments of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++; and also conventional procedural programming languages ​​such as "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, or may be connected to an external computer (e.g., through the Internet using an Internet service provider), including a local area network (LAN) or a wide area network (WAN).

[0114] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0115] The units described in some embodiments of the present application may be implemented by software or hardware. The units described may also be set in a processor, for example, it may be described as: a processor includes a first determination unit, a second determination unit, a selection unit, and a third determination unit. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0116] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0117] The above description is only some preferred embodiments of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present application is not limited to the technical solutions formed by the specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above invention concept. For example, the above features are replaced with (but not limited to) the technical features with similar functions disclosed in the embodiments of the present application to form a technical solution.

Claims

1. A method for detecting a deserialization vulnerability, characterized in that: The method comprises: When receiving a request packet, parsing the request packet to obtain parsed data; Detect whether the parsed data is deserialized data, and obtain a detection result; A first deserialization vulnerability detection result is obtained according to the detection result.

2. The method according to claim 1, characterized in that The detecting whether the parsed data is deserialized data and obtaining the detection result comprises: Detecting the flag bit of the parsed data and obtaining flag bit data; Determine whether the parsed data is deserialized data according to the flag data, and obtain a detection result.

3. The method according to claim 2, characterized in that The flag bit is the first two bytes of the parsed data; The determination of whether the parsed data is deserialized data according to the flag data is performed to obtain the detection result: In the case where the flag data is a magic method number, the detection result is that the parsed data is deserialized data, wherein the magic method number is ACED in hexadecimal; Otherwise, the detection result is that the parsed data is not deserialized data.

4. The method according to claim 1, characterized in that: When the first deserialization vulnerability detection result is that a deserialization vulnerability exists, the method further includes: Detecting a response packet to obtain class definition information of a data stream, wherein the response packet corresponds to the request packet; A second deserialization vulnerability detection result is obtained according to the class definition information.

5. The method according to claim 4, characterized in that The obtaining of the second deserialization vulnerability detection result according to the class definition information comprises: Using a deserialization method to obtain the class name and serialization version number in the class definition information; A second deserialization vulnerability detection result is obtained according to the class name and the serialization version number.

6. The method according to any one of claims 1 to 5, characterized in that: It is deployed on the network application firewall WAF, and the deployment mode is bypass deployment or main deployment. The WAF performs deserialization vulnerability protection operations according to the pre-set defense rules.

7. A device for detecting deserialization vulnerabilities, characterized in that: The device comprises: A parsing module, used for parsing the request packet and obtaining parsed data when receiving the request packet; A detection module, used to detect whether the parsed data is deserialized data and obtain a detection result; The first deserialization vulnerability detection module is used to obtain a first deserialization vulnerability detection result according to the detection result.

8. The device according to claim 7, characterized in that The device also includes: an acquisition module, configured to detect a response packet and acquire class definition information of a data stream when the first deserialization vulnerability detection result indicates that a deserialization vulnerability exists, wherein the response packet corresponds to the request packet; The second deserialization vulnerability detection module is used to obtain a second deserialization vulnerability detection result according to the class definition information.

9. An electronic device, characterized in that: include: one or more processors; a storage device having one or more programs stored thereon, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

10. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Citation Information

Patent Citations

  • De-serialization attack detection method and device, electronic equipment, medium and program

    CN114070580A

  • Method and device for detecting deserialization attack and readable storage medium

    CN114547609A

  • Malicious request detection method and device, processor and electronic equipment

    CN116132126A

  • Detection method and detection system for deserialization vulnerabilities

    CN118779887A

  • Vulnerability detection method and apparatus, electronic device, and computer-readable storage medium

    WO2022068742A1