De-serialization vulnerability protection method and device, equipment and medium

Abstract

The invention provides a deserialization vulnerability protection method and device, equipment and a medium, and relates to the technical field of information security. The method comprises the following steps: acquiring a code of an application program; extracting all classes in the code of the application program to obtain a first class set; at least screening out classes meeting credible source conditions from the first class set to obtain a second class set; extracting class names in the second class set and adding the class names into a white list; constructing a second deserialization class based on the white list; wherein when the deserialization operation method of the second deserialization class is called by the target class, the white list is firstly used for checking the target class, when it is determined that the target class belongs to the white list, the target class is allowed to execute the deserialization operation, and otherwise, abnormity is thrown out; fully replacing the deserialization operation method of the first deserialization class originally referenced in the code of the application program with the deserialization operation method of the second deserialization class so as to update the code of the application program; and outputting the updated code of the application program.

Description

Technical Field

[0001] The present disclosure relates to the field of information security and can be used in the financial field or other fields. More specifically, it relates to a deserialization vulnerability protection method, device, equipment, medium and program product. Background Art

[0002] Serialization is the process of converting an object into a byte sequence, while deserialization is the process of restoring a byte sequence into an object. These two processes are often used to transmit objects over a network or store them in a file system. A deserialization vulnerability is when an attacker constructs a malicious byte sequence during the deserialization process of an application and successfully causes the application system to deserialize the malicious byte sequence, leading to attacks such as remote code execution and denial of service.

[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, the source code of open source code is open, and attackers can easily arrange, organize and process the open source code to form a deserialization attack chain and implement deserialization attacks. Therefore, avoiding untrusted third-party classes triggering deserialization operations is a key to preventing deserialization vulnerabilities. Summary of the invention

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

[0005] In the first aspect of the embodiment of the present disclosure, a method for protecting against deserialization vulnerabilities is provided. The method includes: obtaining the code of an application; extracting all classes in the code of the application to obtain a first class set; filtering out classes that meet the trusted source condition from at least 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; extracting the class names in the second class set and adding them to a whitelist; constructing a second deserialization class based on the whitelist and the first deserialization class; wherein the second deserialization class is configured as follows: when the target class calls the deserialization operation method of the second deserialization class, first use the whitelist to verify the target class, and 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; use the deserialization operation method of the second deserialization class to fully replace the deserialization operation method of the first deserialization class referenced in the code of the application to update the code of the application; wherein the first deserialization class is the class originally used to implement the deserialization function in the code of the application; and output the updated code of the application.

[0006] According to an embodiment of the present disclosure, the method of filtering out classes that meet the trusted source condition from at least the first category set to obtain the second category set includes: filtering out classes that meet the trusted source condition from the first category set to obtain a third category set; filtering out classes that implement serializable interfaces from the third category set to obtain a fourth category set; searching the third category set for classes that inherit each class in the fourth category set to obtain a fifth category set; and merging the fourth category set and the fifth category set to obtain the second category set.

[0007] According to an embodiment of the present disclosure, filtering out classes that meet the trusted source condition from at least the first class set to obtain the second class set includes: filtering out classes whose class names meet a preset format from the first class set.

[0008] According to an embodiment of the present disclosure, when trusted third-party code is statically integrated into the code of the application, after filtering out classes whose class names conform to a preset format from the first class set, filtering out classes that conform to trusted source conditions from at least the first class set, obtaining the second class set also includes: filtering out inheritance classes and attribute classes of the classes whose class names conform to the preset format from the classes whose class names do not conform to the preset format in the first class set; and filtering out classes that implement serializable interfaces from the filtered inheritance classes and attribute classes.

[0009] According to an embodiment of the present disclosure, the application loads and calls trusted third-party code at runtime, wherein at least filtering out classes that meet the trusted source condition from the first category set to obtain the second category set includes: acquiring the third-party code; filtering out classes that meet the trusted source condition from the first category set and the third-party code to obtain the second category set, wherein the trusted source condition includes at least one of the following: a class name that meets a preset format; or a class that has an attribute relationship or an inheritance relationship with a class whose class name meets a preset format and implements a serializable interface.

[0010] According to an embodiment of the present disclosure, before filtering out classes that meet the trusted source condition from at least the first category set, the method also includes: performing a full scan of the code of the application to determine whether a deserialization operation is used in the application; wherein, when it is determined that a deserialization operation is used in the application, filtering out classes that meet the trusted source condition from at least the first category set.

[0011] According to an embodiment of the present disclosure, the full scan of the code of the application to determine whether the deserialization operation is used in the application includes: by checking the bytecode constant pool, filtering out the classes that reference the first deserialization class to obtain a sixth category set; searching the sixth category set for the class that uses the deserialization operation method of the first deserialization class to obtain a search result; when the search result is not empty, determining that the deserialization operation is used in the application, otherwise, determining that the application does not use the deserialization operation.

[0012] According to an embodiment of the present disclosure, the use of the deserialization operation method of the second deserialization class to completely replace the deserialization operation method of the first deserialization class referenced in the code of the application to update the code of the application includes: adding the definition code of the second deserialization class to the code of the application; and using the deserialization operation method of the second deserialization class to completely replace the deserialization operation method of the first deserialization class in the code of the application by bytecode replacement.

[0013] According to a second aspect of the embodiments of the present disclosure, a deserialization vulnerability protection device is provided. 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 used to acquire the code of the application. The first extraction module is used to extract all classes in the code of the application to obtain a first class set. The whitelist scanning module is used to filter out classes that meet the trusted source condition at least 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. The whitelist setting module is used to extract the class names in the second class set and add them to the whitelist. The class construction module is used to construct a second deserialization class based on the whitelist and the first deserialization class; wherein the second deserialization class is configured as follows: when the target class calls the deserialization operation method of the second deserialization class, the target class is first verified using the whitelist, and when the verification determines that the target class belongs to the whitelist, the target class is allowed to perform the deserialization operation, otherwise an exception is thrown. A replacement module is used to use the deserialization operation method of the second deserialization class to completely replace the deserialization operation method of the first deserialization class referenced in the code of the application to update the code of the application; wherein the first deserialization class is the class originally used to implement the deserialization function in the code of the application.

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

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

[0016] According to a fourth aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the deserialization vulnerability protection method provided in the first aspect are implemented.

[0017] According to a fifth aspect of the embodiments of the present disclosure, a program product is provided, including a computer program. When the computer program is executed by a processor, the steps of the deserialization vulnerability protection method provided in the first aspect are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above contents and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

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

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

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

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

[0023] Figure 5 Schematically shows Figure 4 A structural diagram of a serialized whitelist scanning module in the device shown;

[0024] Figure 6 Schematically shows Figure 4 The working flow diagram of the device shown;

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

[0026] Figure 8A block diagram of an electronic device suitable for implementing the 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. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0028] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0029] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.

[0030] The embodiments of the present disclosure provide a method, device, equipment, medium and program product for deserialization vulnerability protection. According to the embodiments of the present disclosure, classes with credible sources (such as classes written by business personnel themselves) can be screened out from the code of the application program, a whitelist can be generated based on the classes with credible sources, and then a safe and credible deserialization class (named "second deserialization class" in this article) can be constructed based on the whitelist, 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 whitelist when it is called, and when it belongs to the whitelist, the target class is allowed to perform the 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 with 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 the deserialization operation, so that the whitelist will be checked first, and only classes with credible sources are allowed to perform the deserialization operation, thereby improving the security of the deserialization operation in this way. Moreover, it can effectively help developers avoid deserialization vulnerability attacks without affecting developers' code writing.

[0031] It should be noted that the deserialization vulnerability protection method, device, equipment, medium and program product determined in 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 The 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] like Figure 1 As shown, the application scenario 100 according to this embodiment may include at least one terminal device (three are shown in the figure, terminal devices 101, 102, 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, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

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

[0035] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

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

[0037] It should be noted that the deserialization vulnerability protection method provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the deserialization vulnerability protection device, equipment, medium and program product provided in the embodiment of the present disclosure can generally be set in the server 105. The deserialization vulnerability protection method provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Accordingly, the deserialization vulnerability protection device, equipment, medium and program product provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the terminal devices 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 embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

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

[0040] like Figure 2 As shown, the deserialization vulnerability protection method of this embodiment may include operations S210 to S270.

[0041] In operation S210, the code of the application is obtained. For example, the user can upload the code of the application 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 of the application and the code storage path, and the server 105 reads the code of the application according to the instruction.

[0042] In operation S220, all classes in the code of the application are extracted to obtain a first class set. The code of the application may be fully scanned to extract classes according to class declarations in the code, or all classes may be extracted by viewing a bytecode constant pool.

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

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

[0045] In one embodiment, the trusted source condition may include: the class name must conform to a preset format. For example, when a business person writes code and the class has a standard naming format (e.g., contains a specific string), classes with the standard naming format may be screened. These classes are classes written by the business person himself and are trusted sources.

[0046] In other embodiments, the trusted source condition may also include: having an attribute relationship or inheritance relationship with a class whose class name conforms to a preset format. For example, the classes written by the business personnel themselves are screened out through the preset format, and considering that the inherited classes and / or attribute classes of the classes written by the business personnel themselves constitute a part of the classes written by the business personnel, the inherited classes and / or attribute classes (if any) of the classes whose class names conform to the preset format may also be included in the classes with trusted sources.

[0047] In some other embodiments, the trusted source condition may also include: having an attribute relationship or inheritance relationship with a class whose class name conforms to a preset format and implementing a serializable interface. In this way, the inherited class or attribute class of the class whose class name conforms to a preset format selected implements a serializable interface, which can avoid adding the inherited class or attribute class that does not require a deserialization operation to the whitelist, thereby reducing the redundancy of the whitelist.

[0048] When trusted third-party code is statically integrated into the code of an application, in some embodiments, classes whose class names conform to a preset format can be first screened out from the first class set and added to the whitelist, and then inherited classes and attribute classes of classes whose class names conform to the preset format can be screened out from the first class set whose class names do not conform to the preset format, and classes that implement serializable interfaces can be further screened out from these inherited classes and attribute classes and added to the whitelist. In this way, the scope of classes with trusted sources can be increased, thereby improving the coverage of the whitelist.

[0049] When the application loads and calls trusted third-party code at runtime, classes that meet the trusted source conditions can be filtered out from the first category set and the third-party code respectively, and added to the whitelist.

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

[0051] Then, operation S260 is performed to completely replace the deserialization operation method of the first deserialization class referenced in the application code with the deserialization operation method of the second deserialization class to update the application code; wherein the first deserialization class is a class originally used in the application code to implement the deserialization function. For example, when the language used in the application code is Java, the first deserialization class can be, for example, a class that implements the deserialization function provided by the Java language itself, such as objectInputStream; or it can be a user-defined class that implements the deserialization function.

[0052] Specifically, during replacement, you can first add the definition code of the second deserialization class to the application code, and at the same time, through bytecode replacement, use the deserialization operation method of the second deserialization class to completely replace the deserialization operation method of the first deserialization class in the application code.

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

[0054] After the application output by operation S270 is installed, when the deserialization operation is performed at runtime, the deserialization operation method of the second deserialization class will be called, which will trigger the whitelist verification mechanism. Only classes with trusted sources are allowed to perform deserialization operations. Exceptions will be thrown for classes that do not pass the whitelist verification, thereby improving the security of the deserialization operation.

[0055] In some embodiments, when an exception is thrown, the business personnel can be prompted to check. If the manual check determines that the target class that calls the second deserialization class is safe and reliable, the class name of the target class can be added to the whitelist, and then the whitelist can be updated. Thus, the next time the target class calls the second deserialization class for deserialization operation, it can proceed smoothly, which is conducive to the normal operation of the business.

[0056] The generation and update method of the whitelist in the embodiment of the present disclosure can ensure comprehensive coverage of the whitelist to a large extent and effectively reduce the impact on normal business transactions.

[0057] Figure 3 The 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.

[0058] like Figure 3 As shown, according to this embodiment, operation S230 may include operations S301 to S304.

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

[0060] Next, in operation S302, classes that implement a serializable interface (such as the Serializable interface in the Java language) are screened out from the third set to obtain a fourth set, wherein a class can only be deserialized if it implements a serializable interface.

[0061] Then in operation S303, the class that inherits each class in the fourth class set is searched from the third class set to obtain a fifth class set.

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

[0063] In this embodiment, after filtering out classes with trusted sources according to the trusted source condition, classes that can perform deserialization operations can be further filtered out, so that the classes in the second category set are not only trusted in source, but also classes that can perform deserialization operations in the application, so that the whitelist formed based on the class names in the second category set has more concise information and low redundancy. Therefore, when the second deserialization class is called, during the whitelist verification process, the whitelist used for verification is more concise and the verification efficiency is higher.

[0064] Figure 4 The structure diagram of a device 400 that can implement the deserialization vulnerability protection method of the embodiment of the present disclosure is schematically shown. The device 400 can be set in the server 105.

[0065] like Figure 4 As shown, the device 400 may include a serialization function scanning module 401 , a serialization whitelist scanning module 402 , and a vulnerability protection module 403 .

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

[0067] In one embodiment, at least before the aforementioned operation S230, the code of the application can be fully scanned to determine whether the deserialization operation method is used in the application, and then only when it is determined that the deserialization operation method is used in the application, the operation S230 to the operation S270 are performed to replace and update the code of the application through the deserialization protection method of the embodiment of the present disclosure. In this way, for the case where it is determined that the deserialization operation method is not used in the application, the server 105 can return to the user the problem that there is no deserialization vulnerability. Among them, in the device 400, the serialization function scanning module 401 can be used to check whether the deserialization operation method is used in the application.

[0068] Specifically, the serialization function scanning module 401 can perform a full scan on the code of the application. For example, the bytecode constant pool can be checked to quickly screen the classes that use the first deserialization class (such as objectInputStream in java) to obtain the sixth category collection. Then, the class that uses the deserialization operation method of the first deserialization class (such as readObject() in the java language) is searched from the sixth category collection. For example, the function call relationship of each class can be checked by string matching to determine whether the deserialization operation method is used in the class, and then the search result is obtained. If the search result is empty, it means that the application does not use the deserialization operation method, and it is considered that there is no need to perform deserialization vulnerability protection and it can be terminated. If the search result is not empty, it means that the application uses the deserialization operation, and the deserialization vulnerability protection of the embodiment of the present disclosure needs to be performed. In this way, the processing of application code that does not use the deserialization operation can be avoided, saving computing resources.

[0069] When the application needs to perform anti-sequence vulnerability protection, the device 400 can generate a whitelist by performing operations S230 to S240 through the serialization whitelist scanning module 402. In one embodiment, the structure and working process of the serialization whitelist scanning module 402 can refer to Figure 5 's hint.

[0070] After obtaining the whitelist, the vulnerability protection module 403 can perform operations S260 and S270. Specifically, the vulnerability protection module 403 constructs a second deserialization class in a customized manner. In one embodiment, the second deserialization class is a class (e.g., objectInputStream) provided by the programming language used by the application to implement the deserialization function, and a whitelist control method is added therein, so that only classes belonging to the whitelist are allowed to execute the deserialization operation method, thereby making the second deserialization class a safe deserialization class.

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

[0072] Figure 5 Schematically shows Figure 4 A structural diagram of the serialized whitelist scanning module 402 of the system is shown.

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

[0074] Deserialization vulnerabilities are mainly caused by untrusted third-party classes (such as classes in open source code) triggering unsafe deserialization operations. Therefore, when setting up a whitelist, the disclosed embodiment may consider adding classes in business codes from trusted sources and classes in trusted third-party codes that the business codes depend on to the whitelist to ensure that deserialization vulnerability protection is performed under the premise of the normal operation of the business functions of the application. Furthermore, since a class can only be deserialized if it implements a serializable interface (such as the Serializable interface), in order to improve judgment efficiency, only classes that implement a serializable interface may be searched when generating a whitelist.

[0075] In one embodiment, the business code scanning unit 412 first analyzes the classes folder in the deployment package of the application. The folder stores the business code, and the first-level package name of the business code can be extracted. When the naming of the class of the business code is set in the writing rules of the business code with a preset format, such as the package name of the business class A is com.company, yewu1.A, and the package name of the business class B is com.company.yewu2.B, it can be known that the preset format of the naming of all business classes is that they all have the com.company string, so that the class with the com.company string can be filtered out from the classes folder. Correspondingly, in the third-party jar package that the project depends on, the class with the com.company package name can also be scanned in batches, thereby obtaining all business classes. Next, the business code scanning unit 412 can recursively extract the inheritance relationship of the business class, query whether the inheritance chain of the business class contains a serializable interface, if it contains, then the class is added to the second class set, if it does not contain, 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 conditions and can perform a deserialization operation.

[0076] The third-party class scanning unit 422 can analyze the dependencies of the classes added to the second category collection by the business code scanning unit 412, extract the inheritance classes and attribute classes that these classes depend on, and determine whether the inheritance classes and attribute classes also inherit the serializable interface. If so, these classes are also added to the second category collection to ensure the normal operation of the deserialization function that runs normally in the application.

[0077] In the case where third-party code is statically integrated into the code of the application, all classes whose sources are credible and can be deserialized can be automatically extracted through the processing of the business code scanning unit 412 and the third-party class scanning unit 422.

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

[0079] like Figure 6 As shown, the working process of the device 400 may include steps S1 to S5.

[0080] Step S1: Scan the entire deployment package of the application to determine whether the deserialization operation is used in the application code. If not, it proves that no protection is required and the process ends directly. Otherwise, jump to step S2.

[0081] Step S2: extracting classes that meet the trusted source condition and can perform deserialization operations from the application code to obtain a second set, and then extracting the class names in the second set to generate a whitelist.

[0082] Step S3: Add a second deserialization class with a whitelist verification mechanism to the code of the application. When the deserialization operation method of the second deserialization class is called by the target class, it will first determine whether the class name of the target class belongs to the whitelist. If so, the deserialization operation is allowed, otherwise an exception is thrown and the deserialization operation is terminated, thereby achieving the purpose of whitelist control.

[0083] Step S4: Use the deserialization operation method of the second deserialization class to replace the deserialization operation method of the first deserialization class originally referenced in the application code. For example, for the classes using the deserialization operation method identified in step S1, perform bytecode replacement and replace the deserialization operation methods referenced 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 ends.

[0085] It can be seen that the device 400 can decide whether to perform deserialization vulnerability protection by determining whether the application code uses deserialization operations. For those that really need protection, the business class and the third-party classes that the business class depends on can be automatically scanned, and the class names of the classes that meet the trusted source conditions and can perform deserialization operations can be used as a whitelist and added to the custom second deserialization class. The second deserialization class is then used to batch replace the original first deserialization class in the application code, thereby achieving whitelist protection for deserialization vulnerabilities.

[0086] According to the embodiments of the present disclosure, the deserialization operation can be effectively protected by the whitelist set automatically without basically affecting the business, which can help developers defend against deserialization attacks. In some cases, developers may not understand security, resulting in the deserialization operation method used in coding may lack security control links, and do not know how to intercept malicious deserialization behavior. Through the method of the embodiments of the present disclosure, the code of the application can be rewritten without affecting the developer's code writing, and the deserialization operation method originally referenced in the application can be rewritten as the deserialization operation method of the second deserialization class, which effectively helps developers avoid attacks from deserialization vulnerabilities.

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

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

[0089] The first acquisition module 710 is used to acquire the code of the application program. In one embodiment, the first acquisition module 710 may perform the operation S210 described above.

[0090] The first extraction module 720 is used 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 may perform the operation S220 described above.

[0091] The whitelist scanning module 730 is used to filter out classes that meet the trusted source condition from at least 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 one embodiment, the whitelist scanning module 730 may perform the operation S230 described above.

[0092] The whitelist setting module 740 is used to extract the class names in the second class set and add them to the whitelist. In one embodiment, the whitelist setting module 740 may perform the operation S240 described above.

[0093] The class construction module 750 is used to construct a second deserialization class based on the whitelist and the first deserialization class; wherein the second deserialization class is configured as follows: when the target class calls the deserialization operation method of the second deserialization class, the target class is first verified using the whitelist, and when the verification determines that the target class belongs to the whitelist, the target class is allowed to perform the deserialization operation, otherwise an exception is thrown. In one embodiment, the class construction module 750 can perform the operation S250 described above.

[0094] The replacement module 760 is used to use the deserialization operation method of the second deserialization class to completely replace the deserialization operation method of the first deserialization class referenced in the code of the application program to update the code of the application program; wherein the first deserialization class is the class originally used in the code of the application program to implement the deserialization function. In one embodiment, the replacement module 760 can perform the operation S260 described above.

[0095] The output module 770 is used to output the updated application code. In one embodiment, the output module 770 can perform the operation S270 described above.

[0096] According to an embodiment of the present disclosure, any multiple modules among the serialization function scanning module 401, the serialization whitelist scanning module 402, the vulnerability protection module 403, the first acquisition module 710, the first extraction module 720, the whitelist scanning module 730, the whitelist setting module 740, the class construction module 750, the replacement module 760 and the output module 770 can be combined into one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of these 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 serialized function scanning module 401, the serialized whitelist scanning module 402, the vulnerability protection module 403, the first acquisition module 710, the first extraction module 720, the whitelist scanning module 730, the whitelist setting module 740, the class construction module 750, the replacement 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 a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware and firmware or in an appropriate combination of any of them. Alternatively, at least one of the serialization function scanning module 401, the serialization whitelist scanning module 402, the vulnerability protection module 403, the first acquisition module 710, the first extraction module 720, the whitelist scanning module 730, the whitelist setting module 740, the class construction module 750, the replacement module 760 and the output module 770 can be at least partially implemented as a computer program module, which can perform the corresponding function when the computer program module is executed.

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

[0098] like Figure 8 As shown, 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 a program stored in a read-only memory (ROM) 802 or a program loaded from a storage part 808 to a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include an onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

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

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

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

[0102] According to an embodiment of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, may include but is not limited to: 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), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, an apparatus or a device. For example, according to an embodiment of the present disclosure, a computer-readable storage medium may include the ROM 802 and / or RAM 803 described above and / or one or more memories other than ROM 802 and RAM 803.

[0103] The embodiment of the present disclosure also includes a computer program product, which includes a computer program, and the computer program includes a program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the deserialization vulnerability protection method provided by the embodiment of the present disclosure.

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

[0105] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices, magnetic storage devices, etc. In another embodiment, the computer program may also be transmitted and distributed in the form of signals on a network medium, and downloaded and installed through the communication part 809, and / or installed from a removable medium 811. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

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

[0107] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level process and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, python, "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on the remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect through the Internet).

[0108] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a 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 box can also occur in a different order from the order marked in the accompanying drawings. For example, two 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 box in the block diagram or flow chart, and the combination of the boxes in the block diagram 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.

[0109] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0110] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A deserialization vulnerability protection method, characterized in that: The method comprises: Get the application code; Extract all classes in the code of the application to obtain a first class set; At least from the first category set, a category that meets the trusted source condition is screened out to obtain a second category set, wherein the trusted source condition is used to screen out categories with trusted sources; Extract the class names in the second class set and add them to the whitelist; Based on the whitelist, construct a second deserialization class; wherein the second deserialization class is configured to: when the target class calls the deserialization operation method of the second deserialization class, first use the whitelist to verify the target class, and 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; Using the deserialization operation method of the second deserialization class to completely replace the deserialization operation method of the first deserialization class referenced in the code of the application program, so as to update the code of the application program; wherein the first deserialization class is a class originally used in the code of the application program to implement the deserialization function; and Output the updated code of the application.

2. The method according to claim 1, characterized in that The method of filtering out at least the classes that meet the trusted source condition from the first class set to obtain the second class set includes: Filtering out the classes that meet the trusted source condition from the first class set to obtain a third class set; Filter out classes that implement serializable interfaces from the third set to obtain a fourth set; Searching the third set for a class that inherits each class in the fourth set to obtain a fifth set; and The fourth category set and the fifth category set are combined to obtain the second category set.

3. The method according to claim 1, characterized in that The method of filtering out at least the classes that meet the trusted source condition from the first class set to obtain the second class set includes: Classes whose class names conform to a preset format are screened out from the first class set.

4. The method according to claim 3, characterized in that When a trusted third-party code is statically integrated into the code of the application, after filtering out classes whose class names conform to a preset format from the first category set, filtering out classes that conform to a trusted source condition from at least the first category set to obtain the second category set further includes: Filtering out, from the classes whose class names do not conform to the preset format in the first class set, inherited classes and attribute classes of the classes whose class names conform to the preset format; Filter out classes that implement the serializable interface from the filtered inherited classes and attribute classes.

5. The method according to claim 1, characterized in that The application loads and calls trusted third-party code at runtime, wherein the second category set is obtained by filtering out classes that meet the trusted source condition from at least the first category set, including: Obtaining the third-party code; Filtering out classes that meet the trusted source condition from the first class set and the third-party code to obtain the second class set; wherein, The trusted source condition includes at least one of the following: The class name conforms to the preset format; or A class that has an attribute relationship or inheritance relationship with a class whose name conforms to the preset format and implements a serializable interface.

6. The method according to claim 1, characterized in that Before filtering out the classes that meet the trusted source condition from at least the first class set, the method further includes: Perform a full scan of the code of the application to determine whether a deserialization operation method is used in the application; Wherein, when it is determined that the deserialization operation method is used in the application, at least classes that meet the trusted source condition are screened out from the first class set.

7. The method according to claim 6, characterized in that The full scanning of the code of the application to determine whether the deserialization operation is used in the application includes: By checking the bytecode constant pool, the class that references the first deserialized class is filtered out to obtain the sixth class set; Searching for a class that uses the deserialization operation method of the first deserialization class from the sixth class set, and obtaining a search result; When the search result is not empty, it is determined that the deserialization operation is used in the application; otherwise, it is determined that the application does not use the deserialization operation.

8. The method according to claim 1, characterized in that The method of using the deserialization operation method of the second deserialization class to completely replace the deserialization operation method of the first deserialization class referenced in the code of the application program includes: Adding the definition code of the second deserialization class to the code of the application program; and By means of bytecode replacement, the deserialization operation method of the second deserialization class is used to completely replace the deserialization operation method of the first deserialization class in the code of the application.

9. A deserialization vulnerability protection device, characterized in that: The device comprises: A first acquisition module is used to acquire the code of the application program; A first extraction module, used to extract all classes in the code of the application program to obtain a first class set; A whitelist scanning module, used to filter out classes that meet the trusted source condition from at least the first class set to obtain a second class set, wherein the trusted source condition is used to filter out classes with trusted sources; A whitelist setting module, used for extracting class names from the second class set and adding them to the whitelist; A class construction module, 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 using the whitelist, and 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; a replacement module, configured to completely replace the deserialization operation method of the first deserialization class referenced in the code of the application program with the deserialization operation method of the second deserialization class, so as to update the code of the application program; wherein the first deserialization class is a class originally used in the code of the application program to implement a deserialization function; and The output module is used 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, The method is 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 to 8.

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

Images