Deserialization vulnerability protection method, device, equipment and medium

By using a whitelist defense method to filter out classes from trusted sources and construct a second deserialization class, the problem of deserialization vulnerability attacks is solved, and the security of deserialization operations and normal business operations are achieved.

CN119312333BActive Publication Date: 2025-11-07INDUSTRIAL AND COMMERCIAL BANK OF CHINA
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410508980.X
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-04-25
Publication Date
2025-11-07
Estimated Expiration
2044-04-25

AI Technical Summary

Technical Problem

Deserialization vulnerabilities are primarily triggered by untrusted third-party classes. Insecure deserialization operations can lead to attacks such as remote code execution and denial-of-service attacks, which are difficult to prevent effectively with existing technologies.

Method used

The whitelist defense method is adopted. By obtaining the application code, classes with trustworthy sources are filtered out, a second deserialization class is constructed, and the target class is verified to be in the whitelist. If the deserialization operation is allowed, an exception is thrown and the first deserialization class in the application is completely replaced.

Benefits of technology

It improves the security of deserialization operations, reduces the risk of attacks from deserialization vulnerabilities, minimizes the impact on normal business operations, and the automated protection process has virtually no impact on developers' coding.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119312333B_ABST
    Figure CN119312333B_ABST
Patent Text Reader

Abstract

The present disclosure provides a deserialization vulnerability protection method, device, equipment and medium, relating to the technical field of information security. The method comprises: obtaining the code of an application program; extracting all classes in the code of the application program to obtain a first class set; filtering at least classes meeting the trusted source condition from the first class set to obtain a second class set; adding the class names in the second class set to a whitelist; constructing a second deserialization class based on the whitelist; wherein when the deserialization operation method of the second deserialization class is called by a target class, the target class is first verified using the whitelist, and when it is determined that the target class belongs to the whitelist, the target class is allowed to perform the deserialization operation, otherwise an exception is thrown; the deserialization operation method of the first deserialization class originally referenced in the code of the application program is replaced in full by the deserialization operation method of the second deserialization class to update the code of the application program; and the updated code of the application program is output.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of information security, which can be used in the financial field or other fields, and more particularly to a deserialization vulnerability protection method, device, equipment, medium and program product. BACKGROUND

[0002] Serialization is the process of converting an object into a sequence of bytes, while deserialization is the process of restoring an object from a sequence of bytes. These two processes are commonly used for object transmission in a network or storage in a file system. Deserialization vulnerability refers to an attack in which an attacker successfully causes an application system to deserialize malicious byte sequences by constructing malicious byte sequences during the deserialization process, resulting in remote code execution, denial of service, and other attacks.

[0003] Deserialization vulnerability attacks are mainly caused by untrusted third-party classes (such as classes in open source code) triggering unsafe deserialization operations. For example, open source code is open source, and attackers can easily arrange, organize and process open source code to form a deserialization attack chain and implement a deserialization attack. Therefore, avoiding untrusted third-party classes from triggering deserialization operations is a key to preventing deserialization vulnerabilities. SUMMARY

[0004] In view of the above problems, the present disclosure provides a deserialization vulnerability protection method, device, equipment, medium and program product using a whitelist defense method, which can improve the comprehensive coverage and effectiveness of the whitelist defense.

[0005] In a first aspect of the embodiments of the present disclosure, a deserialization vulnerability protection method is provided. The method comprises: obtaining the code of an application program; extracting all classes in the code of the application program to obtain a first class set; selecting at least classes that meet a trusted source condition from the first class set to obtain a second class set, wherein the trusted source condition is used to select classes of trusted sources; extracting class names in the second class set and adding them to a whitelist; constructing a second deserialization class based on the whitelist and a first deserialization class; wherein the second deserialization class is configured to: when a target class calls a deserialization operation method of the second deserialization class, first verify the target class using the whitelist, and when it is determined that the target class belongs to the whitelist, allow the target class to perform a deserialization operation, otherwise throw an exception; using the deserialization operation method of the second deserialization class to replace the deserialization operation method of the first deserialization class referenced in the code of the application program in full to update the code of the application program; wherein the first deserialization class is a class originally in the code of the application program for implementing deserialization functions; and outputting the updated code of the application program.

[0006] According to an embodiment of the present disclosure, the filtering, from the first set of classes, classes meeting a trusted source condition to obtain a second set of classes comprises: filtering, from the first set of classes, classes meeting a trusted source condition to obtain a third set of classes; filtering, from the third set of classes, classes implementing a serializable interface to obtain a fourth set of classes; searching, from the third set of classes, classes inheriting each class in the fourth set of classes to obtain a fifth set of classes; and merging the fourth set of classes and the fifth set of classes to obtain the second set of classes.

[0007] According to an embodiment of the present disclosure, the filtering, from the first set of classes, classes meeting a trusted source condition to obtain a second set of classes comprises: filtering, from the first set of classes, classes with class names meeting a preset format.

[0008] According to an embodiment of the present disclosure, when the application program statically integrates trusted third-party code, after the filtering, from the first set of classes, classes with class names meeting a preset format, the filtering, from the first set of classes, classes meeting a trusted source condition to obtain a second set of classes further comprises: filtering, from classes in the first set of classes with class names not meeting the preset format, inherited classes and attribute classes of the classes with class names meeting the preset format; and filtering, from the filtered inherited classes and attribute classes, classes implementing a serializable interface.

[0009] According to an embodiment of the present disclosure, the application program loads and invokes trusted third-party code at runtime, and the filtering, from the first set of classes, classes meeting a trusted source condition to obtain a second set of classes comprises: obtaining the third-party code; and filtering, from the first set of classes and the third-party code, classes meeting a trusted source condition to obtain the second set of classes, wherein the trusted source condition comprises at least one of the following: a class name meeting a preset format; or a class having an attribute relationship or an inheritance relationship with a class with a class name meeting a preset format and implementing a serializable interface.

[0010] According to an embodiment of the present disclosure, before the filtering, from the first set of classes, classes meeting a trusted source condition, the method further comprises: performing a full scan on code of the application program to determine whether a deserialization operation is used in the application program; and in a case where it is determined that the deserialization operation is used in the application program, filtering, from the first set of classes, classes meeting a trusted source condition.

[0011] According to an embodiment of the present disclosure, the full-scan of the code of the application program to determine whether the application program uses the deserialization operation includes: screening out classes referring to the first deserialization class from a bytecode constant pool to obtain a sixth class set; searching for a class using a deserialization operation method of the first deserialization class from the sixth class set to obtain a search result; when the search result is not empty, determining that the application program uses the deserialization operation, otherwise, determining that the application program does not use the deserialization operation.

[0012] According to an embodiment of the present disclosure, the full-replacement of the deserialization operation method of the first deserialization class referenced in the code of the application program by the deserialization operation method of the second deserialization class to update the code of the application program includes: adding definition code of the second deserialization class to the code of the application program; and full-replacing the deserialization operation method of the first deserialization class in the code of the application program by the deserialization operation method of the second deserialization class through bytecode replacement.

[0013] In a second aspect, the present disclosure provides a deserialization vulnerability protection device. The device includes a first acquisition module, a first extraction module, a whitelist scanning module, a whitelist setting module, a class construction module, a replacement module, and an output module. The first acquisition module is configured to acquire the code of an application program. The first extraction module is configured to extract all classes in the code of the application program to obtain a first class set. The whitelist scanning module is configured to at least screen out classes meeting a trusted source condition from the first class set to obtain a second class set, wherein the trusted source condition is used to screen out classes from a trusted source. The whitelist setting module is configured to extract class names in the second class set and add them to a whitelist. The class construction module is configured to construct a second deserialization class based on the whitelist and a first deserialization class, wherein the second deserialization class is configured to, when a target class calls a deserialization operation method of the second deserialization class, first check the target class using the whitelist, and when the check determines that the target class belongs to the whitelist, allow the target class to perform a deserialization operation, otherwise, throw an exception. The replacement module is configured to full-replace a deserialization operation method of a first deserialization class referenced in the code of the application program by a deserialization operation method of the second deserialization class to update the code of the application program, wherein the first deserialization class is a class originally in the code of the application program for implementing a deserialization function.

[0014] The output module is configured to output the updated code of the application program.

[0015] In a third aspect, an electronic device is provided. The electronic device includes one or more processors and a storage device. The storage device is configured to store one or more computer programs. The one or more processors are configured to execute the one or more computer programs to implement the steps of the deserialization vulnerability protection method according to the first aspect.

[0016] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program. The computer program, when executed by a processor, implements the steps of the deserialization vulnerability protection method according to the first aspect.

[0017] In a fifth aspect, a program product is provided. The program product includes a computer program. The computer program, when executed by a processor, implements the steps of the deserialization vulnerability protection method according to the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0018] The above and other objects, features and advantages of the present disclosure will become more apparent from the following description when taken in conjunction with the accompanying drawings, in which:

[0019] Figure 1 An application scenario diagram of the deserialization vulnerability protection method, device, equipment, medium and program product according to an embodiment of the present disclosure is schematically shown;

[0020] Figure 2 A flowchart of the deserialization vulnerability protection method according to an embodiment of the present disclosure is schematically shown;

[0021] Figure 3 A flowchart of obtaining the second type of set in the deserialization vulnerability protection method according to an embodiment of the present disclosure is schematically shown;

[0022] Figure 4 A structure diagram of a device that can implement the deserialization vulnerability protection method according to an embodiment of the present disclosure is schematically shown;

[0023] Figure 5 A structure diagram of the deserialization vulnerability protection device according to an embodiment of the present disclosure is schematically shown; Figure 4 A structure diagram of the serialization whitelist scanning module in the device shown is schematically shown;

[0024] Figure 6 A working flowchart of the device shown is schematically shown; Figure 4 A working flowchart of the device shown is schematically shown;

[0025] Figure 7 A block diagram of the deserialization vulnerability protection device according to an embodiment of the present disclosure is schematically shown; and

[0026] Figure 8A block diagram of an electronic device suitable for implementing a deserialization vulnerability protection method according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0027] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It is to be understood, however, that the description is merely exemplary of the present disclosure, and is not intended to limit the scope of the present disclosure. In the following detailed description of the embodiments of the present disclosure, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to one skilled in the art that the present disclosure can be practiced without these specific details. In other instances, well-known structures and functions have not been described in detail in order to avoid obscuring aspects of the present disclosure.

[0028] The terms used herein are merely used to describe specific embodiments, and are not intended to limit the present disclosure. The terms "include", "comprise" and the like used herein indicate the presence of the described features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0029] All terms used herein, including technical and scientific terms, have the meanings commonly understood by one of ordinary skill in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having meanings consistent with the context of the specification, and should not be interpreted in an idealized or overly formal manner.

[0030] Embodiments of the present disclosure provide a deserialization vulnerability protection method, apparatus, device, medium, and program product. According to embodiments of the present disclosure, a class with a trusted source (such as a class written by a business staff, etc.) can be filtered out from the code of an application program, a white list can be generated according to the class with a trusted source, and then a secure and trusted deserialization class (hereinafter referred to as a "second deserialization class") can be constructed according to the white list, wherein the deserialization operation method of the second deserialization class first checks whether the target class that calls the second deserialization class belongs to the white list when the deserialization operation method of the second deserialization class is called, and if it belongs to the white list, the target class is allowed to perform a deserialization operation, otherwise an exception is thrown. After the second deserialization class is constructed, the deserialization operation method of the first deserialization class originally referenced in the code of the application program can be replaced in full by the deserialization operation method of the second deserialization class, and then the code of the application program is output. The application program obtained in this way will call the deserialization operation method of the second deserialization class when performing a deserialization operation, so that the white list check will be performed first, and only the class with a trusted source will be allowed to perform a deserialization operation, thereby improving the security of the deserialization operation. Moreover, the developer's code writing can be effectively helped to avoid attacks of deserialization vulnerabilities without affecting the developer's code writing.

[0031] It should be noted that the deserialization vulnerability protection method, apparatus, device, medium and program product determined by the embodiments of the present disclosure can be used in the financial field, and can also be used in any field other than the financial field. The present disclosure does not limit the application field.

[0032] Figure 1 An application scenario diagram of the deserialization vulnerability protection method, apparatus, device, medium and program product according to the embodiments of the present disclosure is schematically shown.

[0033] As shown in Figure 1 The application scenario 100 according to the embodiments can include at least one terminal device (three are shown in the figure, terminal devices 101, 102 and 103), a network 104 and a server 105. The network 104 is a medium for providing a communication link between the terminal devices 101, 102 and 103 and the server 105. The network 104 can include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0034] A user can use the terminal devices 101, 102 and 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications can be installed on the terminal devices 101, 102 and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0035] The terminal devices 101, 102 and 103 can be various electronic devices with display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers and desktop computers, etc.

[0036] The server 105 can be a server providing various services, such as a background management server providing background services to clients in the terminal devices 101, 102 and 103. The background management server can analyze and process received user requests and other data, and feed back the processing results to the terminal devices.

[0037] It should be noted that the deserialization vulnerability protection method provided by the embodiments of the present disclosure can be generally executed by the server 105. Accordingly, the deserialization vulnerability protection apparatus, device, medium and program product provided by the embodiments of the present disclosure can be generally arranged in the server 105. The deserialization vulnerability protection method provided by the embodiments of the present disclosure can also be executed by a server or a server cluster different from the server 105 and capable of communicating with the terminal device 101, 102, 103 and / or the server 105. Accordingly, the deserialization vulnerability protection apparatus, device, medium and program product provided by the embodiments of the present disclosure can also be arranged in a server or a server cluster different from the server 105 and capable of communicating with the terminal device 101, 102, 103 and / or the server 105.

[0038] It should be understood that Figure 1 The number of terminal devices, networks and servers in the system is only illustrative. According to the needs of implementation, there can be any number of terminal devices, networks and servers.

[0039] Figure 2 A flowchart of the deserialization vulnerability protection method according to the embodiments of the present disclosure is schematically shown.

[0040] As Figure 2 The deserialization vulnerability protection method of this embodiment can include operations S210-S270.

[0041] In operation S210, the code of the application program is obtained. For example, the user can upload the code of the application program to the server 105 through the terminal device 101, 102, 103. Or for example, the user terminal device 101, 102, 103 sends an instruction to the server 105, indicating the name and code storage path of the application program, and the server 105 reads the code of the application program according to the instruction.

[0042] In operation S220, all classes in the code of the application program are extracted to obtain a first class set. The classes can be extracted according to the declaration of the classes in the code by full scanning the code of the application program, or all classes can also be extracted by viewing the bytecode constant pool.

[0043] In operation S230, at least the classes meeting the trusted source condition are filtered out from the first class set to obtain a second class set, wherein the trusted source condition is used to filter out classes with trusted sources. In this way, the classes in the second class set are all classes with trusted sources.

[0044] Next in operation S240, the class names in the second class set are extracted and added to the white list.

[0045] In one embodiment, the trusted source condition can include that the class name conforms to a preset format. For example, when the business personnel write the code, the class has a standard naming format (e.g., contains a specific string), the class with the standard naming format can be screened, and these classes are the classes written by the business personnel themselves, which are the classes of the trusted source.

[0046] In other embodiments, the trusted source condition can also include that the class with the class name conforming to the preset format has an attribute relationship or an inheritance relationship. For example, the classes written by the business personnel are screened through the preset format, and the inherited classes and / or attribute classes of the classes written by the business personnel are considered to be part of the classes written by the business personnel themselves, so the inherited classes and / or attribute classes (if any) of the classes with the class name conforming to the preset format can also be included in the classes of the trusted source.

[0047] In still other embodiments, the trusted source condition can also include that the class with the class name conforming to the preset format has an attribute relationship or an inheritance relationship and implements a serializable interface. In this way, the inherited classes or attribute classes of the classes with the class name conforming to the preset format are screened, and the inherited classes or attribute classes implementing the serializable interface can avoid adding the inherited classes or attribute classes that do not need the deserialization operation to the whitelist, thereby reducing the redundancy of the whitelist.

[0048] When the trusted third-party code is statically integrated into the code of the application, in some embodiments, the classes with the class name conforming to the preset format can be first screened from the first class set and added to the whitelist, and then the inherited classes and attribute classes of the classes with the class name conforming to the preset format are screened from the classes with the class name not conforming to the preset format in the first class set, and the classes implementing the serializable interface are further screened from these inherited classes and attribute classes and added to the whitelist. In this way, the range of the classes of the trusted source can be increased, and the coverage of the whitelist can be improved.

[0049] When the trusted third-party code is loaded and called at runtime, the classes conforming to the trusted source condition can be screened from the first class set and the third-party code respectively and added to the whitelist.

[0050] Next, in operation S250, a second deserialization class is constructed based on the whitelist; wherein the second deserialization class is configured to: when the target class calls the deserialization operation method of the second deserialization class, first verify the target class using the whitelist, when the verification determines that the target class belongs to the whitelist, allow the target class to perform the deserialization operation, otherwise throw an exception.

[0051] Then, in operation S260, the deserialization operation method of the second deserialization class is used to replace the deserialization operation method of the first deserialization class in the code of the application in full, so as to update the code of the application. The first deserialization class is a class originally used to implement the deserialization function in the code of the application. For example, when the language used in the code of the application is java, the first deserialization class may be a class provided by the java language itself to implement the deserialization function, such as objectInputStream, or may be a class customized by a user to implement the deserialization function.

[0052] Specifically, when replacing, the definition code of the second deserialization class can be added to the code of the application first, and then the deserialization operation method of the second deserialization class is used to replace the deserialization operation method of the first deserialization class in the code of the application in full through bytecode replacement.

[0053] Finally, in operation S270, the updated code of the application is output.

[0054] In this way, after the application output in operation S270 is installed, when the deserialization operation is performed at runtime, the deserialization operation method of the second deserialization class is called, so that the whitelist verification mechanism is triggered, and only classes from a trusted source are allowed to perform the deserialization operation, and classes that do not pass the whitelist verification will throw an exception, thereby improving the security of the deserialization operation.

[0055] In some embodiments, when an exception is thrown, a business staff can be prompted to check. If the target class of the second deserialization class is considered safe and trusted by manual checking, the class name of the target class can be added to the whitelist, and then the whitelist is updated, so that the next time the target class calls the second deserialization class for deserialization operation, the operation can be performed smoothly, which is helpful for the normal operation of the business.

[0056] The generation and updating method of the whitelist in the embodiments of the present disclosure can ensure that the whitelist covers comprehensively to a large extent and effectively reduces the impact on normal business transactions.

[0057] Figure 3 A flowchart of obtaining a second class set in a deserialization vulnerability protection method according to an embodiment of the present disclosure is schematically shown.

[0058] As shown in Figure 3 According to the embodiment, operation S230 can include operation S301 to operation S304.

[0059] First, in operation S301, classes meeting the trusted source condition are filtered from the first class set to obtain a third class set.

[0060] Next, in operation S302, classes implementing a serializable interface (e.g., the Serializable interface in the Java language) are filtered from the third set of classes to obtain a fourth set of classes. Only a class that implements a serializable interface can be subjected to a deserialization operation.

[0061] Then, in operation S303, classes that inherit each class in the fourth set of classes are searched from the third set of classes to obtain a fifth set of classes.

[0062] Finally, in operation S304, the fourth set of classes and the fifth set of classes are merged to obtain the second set of classes.

[0063] In this embodiment, when the classes from a trusted source are filtered according to the trusted source condition, classes that can be subjected to a deserialization operation can be further filtered, so that the classes in the second set of classes are not only from a trusted source, but also classes that can be subjected to a deserialization operation in the application program. Thus, the white list formed based on the class names in the second set of classes is more concise and has low redundancy. When the second deserialization class is called, the white list used for checking is more concise and the checking efficiency is higher in the process of white list checking.

[0064] Figure 4 An apparatus 400 that can implement the deserialization vulnerability protection method of the embodiments of the present disclosure is schematically shown in a structural diagram. The apparatus 400 can be disposed in the server 105.

[0065] As shown in FIG. 4, the apparatus 400 can include a serialization function scanning module 401, a serialization white list scanning module 402, and a vulnerability protection module 403. Figure 4

[0066] The apparatus 400 can process the code of the application program indicated by the user through the terminal device 101, 102, or 103 to implement the deserialization vulnerability protection method of the embodiments of the present disclosure.

[0067] In one embodiment, at least before operation S230, the code of the application program can be subjected to a full scan to determine whether a deserialization operation method is used in the application program. Then, only in the case where it is determined that the deserialization operation method is used in the application program, operations S230-S270 are performed to replace and update the code of the application program by the deserialization protection method of the embodiments of the present disclosure. Thus, for the case where it is determined that the deserialization operation method is not used in the application program, the server 105 can return a problem that there is no deserialization vulnerability to the user. In the apparatus 400, the serialization function scanning module 401 can be used to check whether the deserialization operation method is used in the application program.

[0068] ​Specifically, the serialization function scanning module 401 can perform a full scan on the code of the application program. For example, the serialization function scanning module 401 can first quickly filter the classes that reference the first deserialization class (for example, objectInputStream in java) by viewing the Bytecode Constant Pool, to obtain a sixth class set. Then, the serialization function scanning module 401 can search the classes that use the deserialization operation method (for example, readObject() in java) in the first deserialization class from the sixth class set. For example, the serialization function scanning module 401 can check the function call relationship of each class by string matching, to determine whether the deserialization operation method is used in the class, and then obtain the search result. If the search result is empty, it indicates that the application program does not use the deserialization operation method, and thus it is considered that the deserialization vulnerability protection is not needed, and the process can be ended. If the search result is not empty, it indicates that the application program uses the deserialization operation, and thus the deserialization vulnerability protection of the present embodiment needs to be performed. In this way, the application program code that does not use the deserialization operation can be avoided from being processed, and the computing resources can be saved.

[0069] When the application program needs to perform the deserialization vulnerability protection, the apparatus 400 can perform operations S230 to S240 by using the serialization whitelist scanning module 402 to generate a whitelist. In one embodiment, the structure and working process of the serialization whitelist scanning module 402 can refer to the schematic diagram of FIG. 2. Figure 5

[0070] When the whitelist is obtained, the vulnerability protection module 403 can perform operations S260 and S270. Specifically, the vulnerability protection module 403 constructs a second deserialization class by using a custom method. In one embodiment, the second deserialization class is a class (for example, objectInputStream) provided by the programming language used by the application program to implement the deserialization function, which is rewritten to add a whitelist control method, and only allows the classes belonging to the whitelist to perform the deserialization operation method, so that the second deserialization class is a safe deserialization class.

[0071] Further, after the second deserialization class is constructed, the vulnerability protection module 403 can use the method of bytecode rewriting to replace the deserialization operation method in the classes that use the deserialization operation method scanned by the serialization function scanning module 401 with the deserialization operation method of the second deserialization class, and add the definition code of the second deserialization class in the code of the application program, to complete the deserialization vulnerability protection of the application program.

[0072] Figure 5 The structure diagram of the serialization whitelist scanning module 402 of the system shown in FIG. 2 is schematically shown. Figure 4 The structure diagram of the serialization whitelist scanning module 402 of the system shown in FIG. 2 is schematically shown.​

[0073] As Figure 5 shown, in this embodiment, the serialization whitelist scanning module 402 can include a business code scanning unit 412 and a third-party class scanning unit 422. The serialization whitelist scanning module 402 can be applied to the case where the third-party code is statically integrated in the code of the application program, where the business code scanning unit 412 can extract classes of trusted origin from the business code of the application program, and the third-party class scanning unit 422 can extract classes of trusted origin from the third-party code.

[0074] Deserialization vulnerabilities are mainly caused by triggering unsafe deserialization operations by untrusted third-party classes (such as classes in open source code). Therefore, when setting the whitelist, the embodiments of the present disclosure can consider adding classes in the business code of trusted origin and classes in the trusted third-party code relied on by the business code to the whitelist to ensure deserialization vulnerability protection on the premise of normal operation of the business function of the application program. Further, since a class can only be deserialized if it implements a serializable interface (such as the Serializable interface), to improve the judgment efficiency, only classes implementing the serializable interface can be searched when generating the whitelist.

[0075] In one embodiment, the business code scanning unit 412 first analyzes the classes folder in the deployment package of the application program. The folder stores the business code, and the first package name of the business code can be extracted. When the naming of the classes of the business code is set to have a preset format in the writing rules of the business code, such as the package name of the business class A being com.company, yewu1.A and the package name of the business class B being com.company, yewu2.B, it can be known that the preset format of the naming of all business classes has the com.company string, so that the classes having the com.company string can be filtered out from the classes folder. Correspondingly, in the third-party jar package relied on by the project, classes having the com.company package name can also be batch scanned, so that all business classes can be obtained. Then, the business code scanning unit 412 can recursively extract the inheritance relationship of the business classes, query whether the inheritance chain of the business classes contains a serializable interface, and if so, add the class to the second class set, and if not, it means that the business class will not perform a deserialization operation, and the processing is discarded, so as to obtain all business classes that meet the trusted source condition and can perform a deserialization operation.

[0076] The third-party class scanning unit 422 can analyze the dependency relationship of the classes added by the business code scanning unit 412 to the second-class set, extract the inheritance classes and attribute classes dependent on these classes, determine whether the inheritance classes and attribute classes also inherit the serializable interface, and if so, add these classes to the second-class set to ensure that the deserialization function normally operating in the application program normally operates.

[0077] In the case where the third-party code is statically integrated in the code of the application program, through the processing of the business code scanning unit 412 and the third-party class scanning unit 422, all classes of trusted origin and capable of deserialization operation can be automatically extracted.

[0078] Figure 6 The working flow of the device 400 is schematically shown. Figure 4 The working flow of the device 400 is schematically shown.

[0079] As shown in the working flow of the device 400. Figure 6 The working flow of the device 400 can include steps S1-S5.

[0080] Step S1: The deployment package of the application program as a whole is scanned to determine whether the deserialization operation is used in the code of the application program. If not, it is proved that no protection is needed, and the process is directly ended. Otherwise, it is jumped to step S2.

[0081] Step S2: The classes of trusted origin and capable of deserialization operation are extracted from the code of the application program to obtain a second-class set, and then the class names in the second-class set are extracted to generate a white list.

[0082] Step S3: A second deserialization class with a white list checking mechanism is added to the code of the application program. When the deserialization operation method of the second deserialization class is called by a target class, it is first determined whether the class name of the target class belongs to the white list. If yes, the deserialization operation is allowed. Otherwise, an exception is thrown to end the deserialization operation, so as to achieve the purpose of white list control.

[0083] Step S4: The deserialization operation method of the second deserialization class is used to replace the deserialization operation method of the first deserialization class originally referenced in the application code. For example, for the classes identified in step S1 using the deserialization operation method, byte code replacement is performed to replace the referenced deserialization operation method in these classes with the deserialization operation method of the second deserialization class added in step S3.

[0084] Step S5: If the replacement in step S4 is completed, the process is ended.

[0085] It can be seen that the device 400 can determine whether to perform deserialization vulnerability protection by judging whether the code of the application program uses a deserialization operation, and for the protection that is definitely needed, the business class and the third-party class depended by the business class can be automatically scanned, the class name of the class that meets the trusted source condition and can perform the deserialization operation is taken as a white list, and is matched into the second deserialization class, and then the second deserialization class is used to replace the original first deserialization class in the code of the application program in batches, so as to realize the white list protection of the deserialization vulnerability.

[0086] According to the embodiments of the present disclosure, the deserialization operation can be effectively protected by the automatically set white list without affecting the business, which can help the developer to defend against the deserialization attack. In some cases, the developer may not know about security, resulting in that the security control link is missing in the deserialization operation method used when coding, and does not know how to intercept malicious deserialization behavior. Through the method of the embodiments of the present disclosure, the code of the application program can be rewritten without affecting the code writing of the developer, and the originally referenced deserialization operation method in the application program is rewritten into the deserialization operation method of the second deserialization class, which effectively helps the developer to evade the attack of the deserialization vulnerability.

[0087] Figure 7 A block diagram of a deserialization vulnerability protection device 700 according to an embodiment of the present disclosure is schematically shown.

[0088] As Figure 7 shown, the device 700 can include a first acquisition module 710, a first extraction module 720, a white list scanning module 730, a white list setting module 740, a class construction module 750, a replacement module 760, and an output module 770. The device 700 can be used to implement the deserialization vulnerability protection method introduced in reference Figures 2-3 to the foregoing.

[0089] The first acquisition module 710 is configured to acquire the code of the application program. In one embodiment, the first acquisition module 710 can perform the operation S210 introduced in the foregoing.

[0090] The first extraction module 720 is configured to extract all classes in the code of the application program to obtain a first class set. In one embodiment, the first extraction module 720 can perform the operation S220 introduced in the foregoing.

[0091] The white list scanning module 730 is configured to filter out classes that meet a trusted source condition from the first class set to obtain a second class set, wherein the trusted source condition is used to filter out classes with a trusted source. In one embodiment, the white list scanning module 730 can perform the operation S230 introduced in the foregoing.

[0092] The whitelist setting module 740 is configured to extract the class name in the second class set and add the class name to the whitelist. In an embodiment, the whitelist setting module 740 can perform the operation S240 described above.

[0093] The class construction module 750 is configured to construct a second deserialization class based on the whitelist and the first deserialization class, wherein the second deserialization class is configured to, when a target class calls a deserialization operation method of the second deserialization class, first verify the target class by using the whitelist, and when it is determined by the verification that the target class belongs to the whitelist, allow the target class to perform the deserialization operation, and otherwise throw an exception. In an embodiment, the class construction module 750 can perform the operation S250 described above.

[0094] The replacement module 760 is configured to replace, by using a deserialization operation method of the second deserialization class, a deserialization operation method of a first deserialization class referenced in the code of the application program in full to update the code of the application program, wherein the first deserialization class is a class originally used to implement a deserialization function in the code of the application program. In an embodiment, the replacement module 760 can perform the operation S260 described above.

[0095] The output module 770 is configured to output the updated code of the application program. In an embodiment, the output module 770 can perform the operation S270 described above.

[0096] According to an embodiment of the present disclosure, any of the serialization function scanning module 401, the serialization whitelist scanning module 402, the vulnerability protection module 403, the first obtaining module 710, the first extracting module 720, the whitelist scanning module 730, the whitelist setting module 740, the class constructing module 750, the replacing module 760 and the output module 770 can be combined in one module, or any of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of the modules can be combined with at least part of the functions of other modules, and implemented in one module. According to an embodiment of the present disclosure, at least one of the serialization function scanning module 401, the serialization whitelist scanning module 402, the vulnerability protection module 403, the first obtaining module 710, the first extracting module 720, the whitelist scanning module 730, the whitelist setting module 740, the class constructing module 750, the replacing module 760 and the output module 770 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on chip, a system on board, a system on package, an application specific integrated circuit (ASIC), or any other reasonable manner of hardware or firmware by integrating or packaging the circuit, or implemented in any one of software, hardware and firmware or in a proper combination of any of the above. Alternatively, at least one of the serialization function scanning module 401, the serialization whitelist scanning module 402, the vulnerability protection module 403, the first obtaining module 710, the first extracting module 720, the whitelist scanning module 730, the whitelist setting module 740, the class constructing module 750, the replacing module 760 and the output module 770 can be at least partially implemented as a computer program module which can perform the corresponding functions when the computer program module is run.

[0097] Figure 8 A block diagram of an electronic device suitable for implementing the method for protecting against deserialization vulnerabilities according to an embodiment of the present disclosure is schematically shown.

[0098] As shown in Figure 8 The electronic device 800 according to an embodiment of the present disclosure includes a processor 801 which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 802 or loaded from a storage portion 808 into a random access memory (RAM) 803. The processor 801 can include, for example, a general-purpose microprocessor (such as a CPU), an instruction set processor and / or a related chipset, and / or a special-purpose microprocessor (such as an application specific integrated circuit (ASIC)), and the like. The processor 801 can also include an on-board memory for cache use. The processor 801 can include a single processing unit or a plurality of processing units for performing different actions of the method processes according to an embodiment of the present disclosure.

[0099] In the RAM 803, various programs and data required for the operation of the electronic device 800 are stored. The processor 801, the ROM 802, and the RAM 803 are connected to each other via the bus 804. The processor 801 performs various operations of the method flow according to the embodiments of the present disclosure by executing the programs in the ROM 802 and / or the RAM 803. It should be noted that the programs can also be stored in one or more memories other than the ROM 802 and the RAM 803. The processor 801 can also perform various operations of the method flow according to the embodiments of the present disclosure by executing the programs stored in the one or more memories.

[0100] According to an embodiment of the present disclosure, the electronic device 800 can further include an input / output (I / O) interface 805, which is also connected to the bus 804. The electronic device 800 can further include one or more of the following components connected to the I / O interface 805: an input part 806 including a keyboard, a mouse, and the like; an output part 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), and the like, and a speaker, and the like; a storage part 808 including a hard disk, and the like; and a communication part 809 including a network interface card such as a LAN card, a modem, and the like. The communication part 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like is mounted on the drive 810 as necessary, so that a computer program read therefrom is installed in the storage part 808 as necessary.

[0101] The present disclosure also provides a computer readable storage medium, which can be included in the device / apparatus / system described in the above embodiments; or can exist separately without being assembled into the device / apparatus / system. The above computer readable storage medium carries one or more programs, when the one or more programs are executed, the method according to the embodiments of the present disclosure is implemented.

[0102] According to an embodiment of the present disclosure, the computer readable storage medium can be a nonvolatile computer readable storage medium, for example, can include, but is not limited to, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any appropriate combination thereof. In the present disclosure, the computer readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present disclosure, the computer readable storage medium can include the ROM 802 and / or the RAM 803 described above and / or one or more memory other than the ROM 802 and the RAM 803.

[0103] Embodiments of the present disclosure also include a computer program product, which includes a computer program containing program codes for executing the methods shown in the flowcharts. When the computer program product is run in a computer system, the program codes are used to make the computer system implement the de-serialization vulnerability protection method provided by the embodiments of the present disclosure.

[0104] The above-described functions defined in the system / device of the embodiments of the present disclosure are performed when the computer program is executed by the processor 801. According to an embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by computer program modules.

[0105] In one embodiment, the computer program can rely on a tangible storage medium such as an optical storage device, a magnetic storage device, etc. In another embodiment, the computer program can also be transmitted, distributed, and downloaded in the form of a signal on a network medium, and be downloaded and installed through the communication part 809, and / or be installed from the detachable medium 811. The program codes contained in the computer program can be transmitted by any appropriate network medium, including but not limited to wireless, wired, etc., or any appropriate combination thereof.

[0106] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 809, and / or be installed from the detachable medium 811. When the computer program is executed by the processor 801, the above-described functions defined in the system of the embodiments of the present disclosure are performed. According to an embodiment of the present disclosure, the system, device, apparatus, module, unit, etc. described above can be implemented by computer program modules.

[0107] According to embodiments of the present disclosure, program code of the computer program for performing the methods provided by the embodiments of the present disclosure can be written in any combination of one or more programming languages, and can be implemented in a computer program product. Specifically, the computer program can be implemented in a high-level procedural and / or object-oriented programming language, and / or in assembly / machine language. The programming language includes, but is not limited to, Java, C++, python, “C” language, or similar programming languages. The program code can execute entirely on the user's computing device, partly on the user's device, and partly on a remote computing device, or entirely on the remote computing device or server. In the latter scenario, the remote computing device can be connected to the user's computing device through any kind of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computing device, such as through the Internet using an Internet Service Provider (ISP).

[0108] The computer program product of the present disclosure can be a computer program product, which is a machine-readable medium (or computer readable medium) having stored therein a sequence of instructions executable by a machine such as a personal digital assistant (PDA), a laptop, a desktop computer, or a server. Alternatively, the computer program product can be a propagated signal per se generated by using the program code, and the program code can be stored on a machine-readable medium that can be read by a machine such as a personal digital assistant (PDA), a laptop, a desktop computer, or a server. The program code of the computer program product defines a function, preferably a corresponding action, and / or implements the elements / object / means for performing this function or a part thereof as disclosed in the embodiments of the present disclosure. The program code can be executed by using one or more processors.

[0109] Those skilled in the art will appreciate that features of the various embodiments and / or claims of the present disclosure can be combined or / and integrated with one another, even though such combinations or integrations are not expressly disclosed in the present disclosure. In particular, the features of the various embodiments and / or claims of the present disclosure can be combined and / or integrated with one another in any manner, without departing from the spirit and scope of the present disclosure. All such combinations and / or integrations are within the scope of the present disclosure.

[0110] The above describes embodiments of the present disclosure. However, these embodiments are merely for illustrative purposes, and are not intended to limit the scope of the present disclosure. Although each embodiment is described above separately, this does not mean that the measures in each embodiment cannot be used advantageously in combination. The scope of the present disclosure is defined by the appended claims and their equivalents. Those skilled in the art can make various substitutions and modifications without departing from the scope of the present disclosure, and these substitutions and modifications should all fall within the scope of the present disclosure.

Claims

1. A method of deserialization vulnerability protection, the method comprising: The method comprises: acquiring code of an application program; extracting all classes in the code of the application program to obtain a first class set; filtering out classes meeting a trusted source condition from the first class set to obtain a second class set, wherein the trusted source condition is used to filter out classes with trusted sources; extracting class names in the second class set and adding them to a white list; constructing a second deserialization class based on the white list, wherein the second deserialization class is configured to, when a target class calls a deserialization operation method of the second deserialization class, first verify the target class by using the white list, and when it is determined by the verification that the target class belongs to the white list, allow the target class to perform a deserialization operation, otherwise, throw an exception; using a deserialization operation method of the second deserialization class to replace a deserialization operation method of a first deserialization class referenced in the code of the application program in full to update the code of the application program, wherein the first deserialization class is a class originally in the code of the application program and used to implement a deserialization function; and outputting the updated code of the application program.

2. The method of claim 1, wherein, The filtering out of classes meeting a trusted source condition from the first class set to obtain a second class set comprises: filtering out classes meeting a trusted source condition from the first class set to obtain a third class set; filtering out classes implementing a serializable interface from the third class set to obtain a fourth class set; finding classes inheriting each class in the fourth class set from the third class set to obtain a fifth class set; and merging the fourth class set and the fifth class set to obtain the second class set.

3. The method of claim 1, wherein, The filtering out of classes meeting a trusted source condition from the first class set to obtain a second class set comprises: filtering out classes with class names meeting a preset format from the first class set.

4. The method of claim 3, wherein, When the application program is statically integrated with trusted third-party code, after the filtering out of classes with class names meeting a preset format from the first class set, the filtering out of classes meeting a trusted source condition from the first class set to obtain a second class set further comprises: filtering out inherited classes and attribute classes of the classes with class names meeting a preset format from classes with class names not meeting a preset format in the first class set; filtering out classes implementing a serializable interface from the filtered inherited classes and attribute classes.

5. The method of claim 1, wherein, The application program loads and calls trusted third-party code at runtime, and the filtering out of classes meeting a trusted source condition from the first class set to obtain a second class set comprises: acquiring the third-party code; filtering out classes meeting a trusted source condition from the first class set and the third-party code to obtain the second class set; wherein The trusted source condition comprises at least one of the following: a class name meeting a preset format; or a class with a class name meeting a preset format having an attribute relationship or an inheritance relationship and implementing a serializable interface.

6. The method of claim 1, wherein, Before the filtering out of classes meeting a trusted source condition from the first class set, the method further comprises: perform a full scan on code of the application program to determine whether a deserialization operation method is used in the application program; wherein, in a case where it is determined that the deserialization operation method is used in the application program, at least a class meeting a trusted source condition is filtered out from the first class set.

7. The method of claim 6, wherein, The full scan on the code of the application program to determine whether the deserialization operation method is used in the application program comprises: filtering out a class referencing the first deserialization class by checking a bytecode constant pool to obtain a sixth class set; finding a class using the deserialization operation method of the first deserialization class from the sixth class set to obtain a finding result; when the finding result is not empty, it is determined that the deserialization operation is used in the application program, otherwise, it is determined that the application program does not use the deserialization operation.

8. The method of claim 1, wherein, The full replacement of the deserialization operation method of the first deserialization class referenced in the code of the application program by the deserialization operation method of the second deserialization class comprises: adding definition code of the second deserialization class to the code of the application program; and replacing the deserialization operation method of the first deserialization class in the code of the application program by the deserialization operation method of the second deserialization class in a bytecode replacement manner.

9. A deserialization vulnerability protection device, comprising: The apparatus comprises: a first obtaining module configured to obtain code of an application program; a first extracting module configured to extract all classes in the code of the application program to obtain a first class set; a white list scanning module configured to filter out at least a class meeting a trusted source condition from the first class set to obtain a second class set, wherein the trusted source condition is used to filter out a class from a trusted source; a white list setting module configured to extract class names in the second class set and add the class names to a white list; a class constructing module configured to construct a second deserialization class based on the white list and a first deserialization class, wherein the second deserialization class is configured to, when a target class calls a deserialization operation method of the second deserialization class, first check the target class by using the white list, allow the target class to perform a deserialization operation when it is determined that the target class belongs to the white list, and otherwise throw an exception; a replacing module configured to fully replace a deserialization operation method of a first deserialization class referenced in the code of the application program by a deserialization operation method of the second deserialization class to update the code of the application program, wherein the first deserialization class is a class originally used to implement a deserialization function in the code of the application program; and an output module configured to output the updated code of the application program.

10. An electronic device comprising: one or more processors; a storage device for storing one or more computer programs, characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1-8.

11. A computer readable storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the steps of the method according to any one of claims 1-8. The computer program is executed by the processor to implement the steps of the method according to any one of claims 1-8.

Citation Information

Patent Citations

  • Method and device for protecting deserialized vulnerabilities

    CN110166459A

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

    CN116132126A