A method and apparatus for white list processing of remote procedure calls

Abstract

The application discloses a white list processing method and device for remote procedure calling, and the method comprises the following steps: acquiring a class belonging to a first category, wherein the class is a class requiring remote procedure calling, and the class of the first category is a trusted class; searching for a class depended on by the class from a class of other categories, wherein the class of the other categories is a class whose safe execution of a serialization operation and / or a deserialization operation in remote procedure calling is not determined; judging whether the class depended on by the class is a trusted class; and configuring the trusted class in a white list, wherein only the class configured in the white list can execute the serialization operation and / or the deserialization operation in remote procedure calling. The application solves the problem of the security hidden danger caused by the serialization tool in the remote calling process in the prior art, thereby reducing the risk of arbitrary calling in the serialization process and improving the security of a software product.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software, in particular, to a remote procedure call whitelist processing method and device. BACKGROUND

[0002] The traditional software project architecture is generally monolithic architecture. The feature of this monolithic architecture is to develop and test all functions in one project, and finally package the project for deployment when it is online. Figure 1 is a schematic diagram of project development using monolithic architecture according to the prior art, as shown in Figure 1 , the online shopping mall project includes three modules: order module, user module and commodity module. These three modules are very tightly coupled, and use the same service server to provide services, which runs on the server. The data of the three modules is saved in the database, and the three modules access the same database through the service server when using data. The advantage of this monolithic architecture is that the architecture is simple and easy to use, and the operation is easy when deploying, only one project needs to be packaged.

[0003] The monolithic architecture project has one disadvantage, that is, the coupling degree between each function module is too high. If one of the function modules has a problem, the entire project needs to be stopped for maintenance, otherwise the project will crash or have exceptions. In Figure 1 , if the product module has a problem, the service server in the project needs to be taken offline for maintenance, which will cause all modules to be unable to use.

[0004] In order to solve the problems existing in the monolithic architecture, microservices are introduced. Microservices is a service-oriented architecture style, in which a project is built as a collection of multiple different small services instead of a single service program. Unlike service programs, microservices can run multiple independent service programs at the same time, and these independent service programs can be created using different coding or programming languages. Figure 2 is a schematic diagram of project development using microservices according to the prior art, as shown in Figure 2 , the online shopping mall project can be divided into three independent service programs: product service, order service and user service. These three services are microservices, and each service provides services through its own service server. Each service can access the database (DB) independently, and users can access these three services through a personal computer (PC) or a smart terminal (such as a mobile phone). In microservices, if the product service has a problem, only the product service needs to be taken offline, and the user service and the order service can continue to run. In microservices, since each service is independent, remote calls are often involved.

[0005] In the microservice remote call, since the network connection can only carry binary data, the abstract request object needs to be converted into binary data through a serialization tool, and the binary data is serialized into a request object after being transmitted through the network. The serialization and deserialization can be collectively referred to as a serialization process. In the serialization process, due to the vulnerability of the target class, the serialization tool may exceed the normal access range or even execute remote commands. This will bring security risks to the microservice. SUMMARY

[0006] Embodiments of the present application provide a white list processing method and device for remote procedure call, to at least solve the security risks caused by the serialization tool in the remote call process.

[0007] According to an aspect of the present application, a white list processing method for remote procedure call is provided, comprising: acquiring a class belonging to a first category, wherein the class is a class requiring remote procedure call, and the class of the first category is a trusted class, and the trusted class is a class capable of safely performing serialization operation and / or deserialization operation in remote procedure call; searching for a class depended on by the class from a class of other category, wherein the class of the other category is a class whose capability of safely performing serialization operation and / or deserialization operation in remote procedure call is not determined; judging whether the class depended on by the class is a trusted class; and configuring the trusted class in a white list, wherein only the class configured in the white list can perform serialization operation and / or deserialization operation in remote procedure call, and the trusted class includes the class and the class depended on by the class.

[0008] According to another aspect of the present application, a white list processing device for remote procedure call is also provided, comprising: an acquisition module, configured to acquire a class belonging to a first category, wherein the class is a class requiring remote procedure call, and the class of the first category is a trusted class, and the trusted class is a class capable of safely performing serialization operation and / or deserialization operation in remote procedure call; a searching module, configured to search for a class depended on by the class from a class of other category, wherein the class of the other category is a class whose capability of safely performing serialization operation and / or deserialization operation in remote procedure call is not determined; a judging module, configured to judge whether the class depended on by the class is a trusted class; and a configuring module, configured to configure the trusted class in a white list, wherein only the class configured in the white list can perform serialization operation and / or deserialization operation in remote procedure call, and the trusted class includes the class and the class depended on by the class.

[0009] According to another aspect of the present application, an electronic device is also provided, comprising a memory and a processor; wherein the memory is configured to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method steps described above.

[0010] According to another aspect of the present application, a readable storage medium is also provided, having computer instructions stored thereon, wherein the computer instructions are executed by a processor to implement the method steps described above.

[0011] According to another aspect of the present application, a computer program product is also provided, comprising computer program instructions, wherein the computer program instructions are executed by a processor to implement the method described above.

[0012] In the embodiments of the present application, a class belonging to a first category is acquired, wherein the class is a class requiring remote procedure call, and the class of the first category is a trusted class, and the trusted class is a class capable of safely performing serialization operation and / or deserialization operation in remote procedure call; a class depended on by the class is searched from classes of other categories, wherein the classes of other categories are classes whose capability of safely performing serialization operation and / or deserialization operation in remote procedure call is not determined; it is judged whether the class depended on by the class is a trusted class; and the trusted class is configured in a white list, wherein only classes configured in the white list can perform serialization operation and / or deserialization operation in remote procedure call, and the trusted class comprises the class and the class depended on by the class. The present application solves the problem of security risks caused by serialization tools capable of arbitrarily calling target classes in remote call process in the prior art, thereby reducing the risk of arbitrary call in the serialization process and improving the security of software products. BRIEF DESCRIPTION OF DRAWINGS

[0013] The accompanying drawings, which form a part of the present application, are intended to provide further understanding of the present application, and are used to interpret the illustrative embodiments of the present application and their descriptions, and are not intended to be an improper limitation of the present application. In the drawings:

[0014] Figure 1 is a schematic diagram of project development using monolithic architecture according to the prior art;

[0015] Figure 2 is a schematic diagram of project development using microservices according to the prior art;

[0016] Figure 3 is an interaction schematic diagram of RPC according to the related art;

[0017] Figure 4 is a flowchart of the white list processing method of remote procedure call according to the embodiments of the present application;

[0018] Figure 5 is a schematic diagram of a class that can be loaded by a JAVA runtime according to an embodiment of the present application;

[0019] Figure 6 is a schematic diagram of JAVA third-party class security according to an embodiment of the present application;

[0020] Figure 7 is a schematic diagram of finding a secure class by exposing an interface according to an embodiment of the present application; and,

[0021] Figure 8 is a schematic diagram of a package name backtracking process according to an embodiment of the present application. DETAILED DESCRIPTION

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

[0023] It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.

[0024] Microservices are involved in the following embodiments, and first the technical terms involved in the following embodiments are described below.

[0025] JVM

[0026] JVM is the abbreviation of Java Virtual Machine (Java Virtual Machine), and JVM is a specification for computing devices, which is a fictitious computer that is implemented by simulating various computer functions on actual computers. After the introduction of the Java virtual machine, the Java language does not need to be recompiled when running on different platforms. Java language uses Java virtual machine to shield the information related to the specific platform, so that the Java language compiler only needs to generate target code (bytecode) running on the Java virtual machine, and can run on multiple platforms without modification.

[0027] JDK

[0028] The software development kit (Java Development Kit, abbreviated as JDK) of Java language is mainly used for the development of java application programs on various devices (including mobile devices and embedded devices). JDK is the core of the entire Java development, which includes the running environment of Java (JVM+Java system library) and Java tools.

[0029] POJO

[0030] A simple Java object (Plain Ordinary Java Object, POJO for short) can be understood as a simple entity class in essence. As the name implies, the POJO class is used to facilitate programmers to use the data table in the database. For most programmers, the POJO class can be used as an object.

[0031] RPC

[0032] Remote Procedure Call (RPC for short) is a service request from a remote computer program through a network. RPC does not need to understand the underlying network technology protocol. RPC protocol assumes the existence of some transport protocol and transmits information data between programs. Figure 3 is a schematic diagram of the interaction of the RPC according to the related art, as shown in Figure 3 When performing a remote procedure call, the following steps can be included:

[0033] Step 1, the client (client) calls the service in a local call manner.

[0034] Step 2, after the client stub (client stub) receives the call, it is responsible for assembling the method, parameters, etc. into a message body that can be transmitted over the network (serializing the message body object into binary).

[0035] Step 3, the client sends the message to the server through sockets.

[0036] Step 4, the server stub (server stub) decodes the message after receiving the message (deserializes the message object).

[0037] Step 5, the server stub calls the local service according to the decoding result.

[0038] Step 6, the local service executes and returns the result to the server stub.

[0039] Step 7, the server stub packs the return result into a message (serializes the result message object).

[0040] Step 8, the server (server) sends the message to the client through sockets.

[0041] Step 9, the client stub receives the result message and decodes it (serializes the result message).

[0042] Step 10, the client gets the final result.

[0043] RPC can encapsulate steps 2, 3, 4, 7, 8 and 9.

[0044] In the above steps, serialization is involved. The following describes serialization. In microservice remote invocation, since the network connection can only carry binary data, the abstract request object needs to be converted into binary data through a serialization tool. Serialization is the process of converting software objects that need to be transmitted over the network into binary data. Correspondingly, deserialization is the process of converting binary data into software objects.

[0045] In remote invocation, since the server can only passively accept requests from the client, the server needs to unconditionally trust the data from the client. Serialization tools can mobilize target classes of any range, which leads to certain security risks. For example, in the deserialization process, the serialization tool can access the specific methods of the class (such as the method of setting the attribute) to access the risky class, and then perform arbitrary access or even execute remote commands, which threatens the security of the production environment.

[0046] The RPC frameworks used in the prior art, such as gRPC, Thrift, Jboss, RMI, Sofa RPC, HessianRPC, etc., all provide serialization and deserialization capabilities. These RPC frameworks all have the above security risks. In order to solve this problem, the following three optional ways can be used to solve it.

[0047] Method one

[0048] The RPC framework requires that the user request and return interface must be defined in advance according to the format declared by the interface description language (Interfacedescription language, referred to as IDL). Only the structure directly declared on the RPC interface is allowed to enter the serialization process at runtime, and all data that does not conform to the structure is solved. This way requires the user to define the corresponding format when developing, which affects the user's development efficiency. Moreover, this way can also lead to the inability to fully support the features of some programming languages, for example, it cannot support Java's generics and class upcasting and downcasting mechanisms, and cannot call RPC interfaces like normal Java method calls.

[0049] Method two

[0050] In this mode, the user needs to manually configure the white list, that is, the user needs to inject a list of expected white list classes into the serialization framework in advance, and by checking whether the input information is in the white list during the deserialization process, if not, the deserialization is prohibited, so as to avoid arbitrary access problems. This mode affects user experience because the user needs to declaratively configure the class information that can be used. Although this mode can avoid accessing problematic target classes by enumerating all used classes through the white list (that is, only allowing access to classes in the white list during serialization), this mode requires complex user configuration and has certain limitations.

[0051] Mode three

[0052] In this mode, a black list is used, that is, a list of untrusted classes is built into the serialization framework, and by checking whether the input information is in the black list during the deserialization process, if so, the deserialization is prohibited, so as to avoid the problem of accessing known potential risk classes. In this mode, the black list is generated in advance, and if an attacker finds a new class, the attacker can attack all applications in the environment that exist in the class, and cannot fundamentally solve the problem of deserialization arbitrary access.

[0053] Through the analysis of the above three modes, it can be obtained that mode two is the easiest to implement, but for mode two, the user needs to manually configure all the white lists, which increases the workload of the user and reduces the user experience. On the other hand, due to the various dependency relationships between classes, the user may also miss the configuration of the white list class.

[0054] To solve the above problems, in the following optional implementation, a white list processing method for remote procedure call is provided, Figure 4 is a flowchart of the white list processing method for remote procedure call according to an embodiment of the application, as Figure 4 The method involved in Figure 4 The steps included in the method are described below.

[0055] Step S402, acquiring a class belonging to a first category, wherein the class is a class that needs to perform remote procedure call, and the class of the first category is a trusted class, and the trusted class is a class that can safely perform serialization and / or deserialization operations in the remote procedure call.

[0056] In this step, the first category of classes can be the public interface class (API) based on which the user makes remote procedure calls. When the client initiates a request to the remote procedure call, there is an interface definition, and the class defined by the interface definition can be the first category of classes. In this public API, there are only the basic defined classes, and in the remote procedure call, there are many more classes actually used than the public API. Therefore, after finding the first category of classes, other trusted classes can be found through step S404.

[0057] In addition, in this step, the user can specify some classes belonging to the first category. Figure 1 In the steps involved and in the following optional embodiments, the user can include a developer who uses a development environment to develop software. Generally, the developer can determine which classes are relatively safe. For example, if the class is developed by the user himself, the user is relatively clear about the class developed by himself, and there is no security problem. Therefore, as an optional embodiment, the user can take the class developed by himself as the first category of classes. Of course, in addition to the class developed by the user himself, if the user can determine that a class is also safe in the serialization process, it can also be the first category of classes. In this step, it is not limited to what the first category of classes includes, as long as one or more classes belonging to the first category of classes can be obtained, the purpose of this step can be achieved.

[0058] Step S404, finding the class depended by the class from other categories of classes, wherein the other categories of classes are classes whose serialization operation and / or deserialization operation in the remote procedure call can not be determined to be safely executed.

[0059] In many scenarios, there is a certain dependency relationship between classes. The dependency relationship is the connection between classes. The dependency relationship indicates that one class depends on the definition of another class. For example, in an online shopping project, the order class (order) needs to access the user account class (account), so the account class needs to be referenced in the order class, that is, the order class depends on the account class, and if the account class is modified, it will affect the order class. In this step, since the classes in the first category are trusted classes, in this step, the classes depended by the trusted classes in other categories are found. The classes in other categories have not been determined to be trusted classes. Through the finding of the dependency relationship, more trusted classes can be found from the trusted classes obtained in step S402, which reduces the workload of manual input by the user.

[0060] Step S406, determining whether the class depended by the class is a trusted class.

[0061] After the classes in the first category are found to depend on other classes, the classes in the first category depend on other classes are also trusted classes because the classes in the first category need to return data from the dependent classes and so on. For example, in the case that the classes in the first category are classes developed by the user, the classes on which the classes depend are also selected by the user to be used in the process of developing the classes, and thus the classes can also be considered as trusted classes.

[0062] In step S408, the trusted classes are configured in a white list, wherein only the classes configured in the white list can perform serialization and / or deserialization operations in remote procedure calls, and the trusted classes include the classes and the classes on which the classes depend.

[0063] In this step, after the trusted classes are obtained, the trusted classes can be configured in a white list, which is used for judging serialization and / or deserialization operations in remote procedure calls, for example, by checking whether the input information is in the white list in the process of deserialization, and if not, deserialization is prohibited. Because the classes in the white list include the classes on which the classes depend in addition to the pre-configured classes in the first category, the configuration operation of the user is reduced, and the reliability of the classes in the white list is ensured. Thus, the above steps solve the problem of security risks caused by the serialization tool being able to arbitrarily call target classes in the prior art, and further reduce the risk of arbitrary calling in the serialization process and improve the security of software products.

[0064] In the above step S402, the classes belonging to the first category are obtained. In an optional embodiment, the user can take all the classes developed by the user in a project as a subset of the classes in the first category, and then find the dependent classes according to each class in the subset, thereby forming a universal set. The classes in the universal set are all the trusted classes in the project, and then the classes in the universal set are configured in the white list, so that all the trusted classes in the project can be configured in the white list. That is, in the optional embodiment, a set of classes input by the user can be received, wherein the classes in the set are all the classes in the first category; for each class in the set, the step of finding the dependent classes is performed, and each class in the set and the dependent classes are determined as trusted classes. Through the optional embodiment, the workload of the user configuration is further reduced, and the user experience is improved.

[0065] In the process of finding the classes depended by a class, the classes used by the class can be obtained by analyzing the code, and the classes used by the class can be considered as the classes depended by the class, i.e. in the optional embodiment, finding the classes depended by the class from other classes can include the following steps: finding all the classes used by the class according to the dependency chain relationship of the class; and taking the classes used by the class as the classes depended by the class. Of course, other ways can also be used to find the classes depended by a class, which will not be described here.

[0066] After the classes depended by the class are found, in order to find more trusted classes, the package function provided by some programming languages can also be used to find more trusted classes. In programming, a directory for saving the class can be provided for each class, the directory can be divided into multiple levels, and the directory where each class is located can be packaged into a package, and the name of the package can reflect the directory where the class is located. For example, the name of a package is directory 1. directory 2. directory 3, and the “.” is used to separate the directories at different levels. In addition to using “.”, special symbols can also be used to separate the directories. A package can include multiple classes, for example, the directory 1. directory 2. directory 3 package can include three classes, the three classes are all in the directory 3, the directory 3 is in the directory 2, and the directory 2 is in the directory 1; for another example, the directory 1. directory 2 package can include the three classes in the above package and the classes in the directory 2. Usually, the multiple classes included in a package are similar in function, so if the classes are in the same package, it can be considered that the properties of the classes in the package are similar, i.e. if a class in the package is a trusted class, the classes in the package can be considered as trusted classes. Based on the above relationship between the package and the class, in an optional embodiment, the package name of the class and / or the classes depended by the class can be obtained; all the classes under the package name are determined as trusted classes; and all the classes determined as the trusted classes under the package name are added to the white list. Through the optional embodiment, the number of trusted classes can be further expanded, and the role of the white list can be strengthened.

[0067] As mentioned in the above paragraph, a package can include N-level package names, for example, the package of directoryl.directory2.directory3 includes 3-level package names. Considering that different developers can use different naming rules, if a class is in directoryl.directory2.directory3, all classes under directory3 can be considered as trusted classes, or all classes under directory2 can be considered as trusted classes, or all classes under directoryl can be considered as trusted classes. In an optional embodiment, the user can configure the number of levels of package names that can be included. That is, the package name includes N-level package names, where N is greater than or equal to 1, and determining all classes under the package name as trusted classes can include the following steps: receiving a user-configured n, where n is greater than or equal to 1 and n is less than or equal to N; obtaining the first n-level package name in the package name; and determining all classes under the first n-level package name as trusted classes. In the above example, if a trusted class is included in the package of directoryl.directory2.directory3, and the user configures n as 2, all classes under directoryl.directory2 can be considered as trusted classes.

[0068] This way of using package names to determine whether a class is a trusted class can not be suitable for all classes. In this case, the user can also configure which classes can use package names to determine trusted classes and which classes cannot use package names to determine trusted classes. That is, in an optional embodiment, before obtaining the package name of the package in which the class depends, the method can further include the following steps: determining whether the class depends on a class belonging to a predetermined class; and in the case that the class does not belong to the predetermined class, performing the steps of obtaining the package name and determining all classes under the package name as trusted classes. For example, the classes in the predetermined class are classes that are provided by default in a programming tool or programming environment. This is because the types of classes provided by default in a programming tool or programming environment are diverse, and can include untrusted classes. Therefore, for classes in this class, the way of using package names to determine trusted classes can not be suitable. For classes provided by default in a programming tool or programming environment, the user can configure which classes are trusted classes, or classes that are dependent on the first class can be considered as trusted classes.

[0069] As can be seen from the above optional embodiment, the first class of classes can include classes developed by the user, and the other classes can include at least one of the following: classes provided by default in a programming tool or programming environment, and external classes introduced by the user. In the following embodiments, the first class of classes can be referred to as one party, the classes provided by default in a programming tool or programming environment can be referred to as two parties, and the external classes introduced by the user can be referred to as three parties.

[0070] The above embodiments can be applied to various programming languages. The following describes an example in Java. Figure 5 is a schematic diagram of classes that can be loaded by a JAVA runtime according to an embodiment of the present application, as shown in Figure 5 For a JVM environment, in the runtime environment of Java, all classes that can be loaded can be divided into three types, namely, classes developed by a user, classes provided by default by JDK after the user uses the JDK environment, and external classes introduced by the user through a class path. For convenience of description, the three types are referred to as one-party, two-party, and three-party classes. The one-party classes are classes developed by the user, the two-party classes are classes provided by default by the JDK, and the three-party classes are external classes introduced by the user.

[0071] In the security practice of software, it is generally considered that the one-party classes provided by the user (a developer who develops software using a framework) are safe by default, because the one-party classes are developed by the user and the behavior thereof is defined by the user. From the perspective of the framework, it is necessary to unconditionally trust that the structure defined by the developer using the framework is correct, otherwise, serialization has no meaning. The two-party classes and the three-party classes are not controlled by the user, and due to the influence of supply chain security and other problems, the two-party libraries and the three-party libraries can have classes with deserialization vulnerabilities. For example, in the two-party classes, there are a large number of ToString methods in the JDK that can possibly call the classes of the runtime Runtime; for another example, the three-party rometools also has a risk of local access. The ToString method returns a string that represents the object in a text manner, and the rometools is a serialization and deserialization tool. Figure 6 is a schematic diagram of JAVA three-party class security according to an embodiment of the present application, as shown in Figure 6 The one-party classes are safe by default, and the two-party classes and the three-party classes have safe classes and unsafe classes. Therefore, it is necessary to find the safe classes in the two-party classes and the three-party classes and put the safe classes into a whitelist.

[0072] In order to distinguish the safe and trusted classes from the classes with deserialization vulnerabilities, an automatic recursive analysis method is used to obtain all safe and trusted classes that can be used for serialization. Figure 7 is a schematic diagram of finding safe classes by exposing interfaces according to an embodiment of the present application, as shown in Figure 7As shown in the microservice call, the application needs to expose the interface to the outside first (i.e., com.example.service.DemoService shown in the figure, which is an example interface), through the above-mentioned optional implementation of the distinction between class roles, these interfaces belong to one-party classes, which are directly provided by the user and are secure by default. This interface class often depends on some two-party classes and three-party classes, such as java.lang.String (Java string class, which contains the value of the string and some methods for implementing string-related operations), and three-party classes such as public components developed within the team. Then through the mechanism of dependency chain relationship analysis, all classes that will be used by the RPC interface are automatically found and marked as trusted classes, and all other two-party classes and three-party classes are marked as untrusted classes and will be rejected during deserialization. For example, in Figure 7 the analysis in the interface uses the two-party class java.lang.String, and the three-party class org.example.pojo.Greeter is used by the interface. Since the interface is a one-party class and is secure, the java.lang.String as a two-party class and the org.example.pojo.Greeter as a three-party class are also secure, that is, these two classes can be added to the whitelist. There are unused classes in the three-party class, for example, com.demo.good, which will not be added to the whitelist. For classes that are known to be insecure, such as the com.rometools.rome class, they will not be added to the whitelist or can be added to the blacklist.

[0073] After all trusted classes are found, as an optional implementation, in order to better adapt to Java's generics and upcasting and downcasting mechanisms, a package name backtracking mechanism can also be provided, that is, after a class is found, all classes under its package name are also included in the trusted list. First, the concept of package in Java is explained.

[0074] In order to facilitate the management of files on the hard disk, files are usually stored in directories. Similarly, in program development, the coded classes also need to be stored in directories in the project for file management. For this purpose, Java introduces the package mechanism, and programs can manage Java classes in directories through package declaration. The package in Java is specially used to store directories, and classes with the same function are usually stored in the same package. The package is declared by the package keyword, for example, package cn.zhejiang.hangzhou; / / this code generates a three-level directory package, the first level directory is cn, the second level directory is zhejiang, and the third level directory is hangzhou.

[0075] It should be noted that in the development of Java programs, the defined class usually contains a package name. In development, many packages may be used in a project, and when a class in a package needs to call a class in another package, the import keyword needs to be used to import the required class. Using the import keyword can import a class under a specified package in the program, so you don't have to write the full class name every time you use it, which simplifies the code amount. In JDK, different classes of different functions are placed in different packages, among which the core classes of Java are mainly placed in the java package and its sub-packages, and most of the extended classes of Java are placed in the javax package and its sub-packages. There are many other packages in JDK, such as the java.sql package for database programming, the javax.swing package for writing GUI, and so on. All classes in all packages in JDK constitute the Java class library.

[0076] In Java development, the package names of classes provided by different organizations will be very different, such as the package name used by Dubbo (the name of an organization) is org.apache.dubbo, and the package name used by Spring (the name of another organization) is org.springframework. Considering this problem, a variable of n-level package name can be provided for users to set, and users can configure this variable as the default package name depth of their organization.

[0077] For example, when n is configured as 3, for the com.example.dance.pojo.User class, all classes under com.example.dance will also be added to the trusted list during execution. In this example, while isolating the problematic third-party library, all user-defined classes are covered as much as possible.

[0078] For example, when n is configured as 4, for the com.example.dance.pojo.User class, all classes under com.example.dance.pojo will also be added to the trusted list during execution. Classes in this list will all be added to the whitelist.

[0079] In actual application, it is found that the backtracking mechanism is not used much for some two-way classes provided by programming languages, for example, the two-way classes provided by JDK are not suitable for automatic backtracking mechanism, because there are a large number of classes with deserialization vulnerabilities in the JDK environment and it is easy to cause this class to be loaded into the trusted list after starting the automatic backtracking. For security considerations, the built-in whitelist + only load specific classes that have been used will be used for JDK two-way classes.

[0080] Figure 8This is a schematic diagram of the package name backtracking process according to an embodiment of this application, such as... Figure 8 As shown, the original input comes from two sources: RPC interfaces and a whitelist of built-in JDK classes. Classes from RPC interfaces are automatically considered trusted classes, and the attributes of trusted classes and the input and / or output parameter types of the interfaces are also automatically considered trusted classes. All trusted classes are then checked to see if they are provided by a third-party JDK. If so, only the class itself is added to the trusted class list. If not, it checks if an n-level package name exists. If it exists, all classes under that n-level package name are added to the trusted class list; otherwise, only the class itself is added. Whitelisted built-in JDK classes are directly added to the trusted class list. The final trusted class list is used to intercept potentially risky serialization attempts.

[0081] For microservices, the user-subscribed or published interfaces within the microservice can be selected as the base trusted class (i.e., the first category of classes). This base trusted class can cover the scenarios that serialization and / or deserialization might use in the RPC domain. By dynamically generating a trusted list, the user's usage cost is reduced, and application security is improved. Furthermore, the overall trusted list can be improved by using a mechanism of automatic package name analysis, largely covering all potentially used classes and reducing the impact of enabling the serialization trusted list on users making microservice calls using subclasses or generics.

[0082] The above optional implementation methods will now be compared with the three methods mentioned above.

[0083] Method 1

[0084] The RPC framework requires that user requests and responses must be predefined according to the format declared in the Interface Description Language (IDL). At runtime, only structures directly declared on the RPC interface are allowed to enter the serialization process, and all data that does not conform to the structure is resolved.

[0085] This approach significantly impacts user experience, requiring users to define classes according to a specific format during development. It also fails to fully support Java's generics and class upcasting / downcasting mechanisms, and cannot call RPC interfaces like normal Java methods. The alternative implementation described above is still based on user-defined POJOs, eliminating the need for user-defined IDLs. Furthermore, it utilizes automatic recursion and package backtracking mechanisms to retrieve all classes that users might use, thus satisfying diverse usage scenarios.

[0086] Method 2

[0087] In this mode, the user needs to manually configure the white list, that is, the user needs to inject a list of expected white list classes into the serialization framework in advance, and check whether the input information is in the white list during the deserialization process, and if not, the deserialization is prohibited, so as to avoid arbitrary access. This mode affects user experience because the user needs to declaratively configure the class information that can be used.

[0088] This mode requires the user to manually declaratively configure the class information that can be used, and has certain limitations. The above optional implementation avoids user explicit configuration by automatically recursively obtaining all classes that can be used by the user through a package backtracking mechanism, thereby improving user experience.

[0089] Mode three

[0090] In this mode, a black list is used, that is, a list of untrusted classes is built into the serialization framework, and whether the input information is in the black list during the deserialization process is checked, and if so, the deserialization is prohibited, so as to avoid the problem of accessing known potential risk classes.

[0091] In this mode, the black list is generated in advance, and if an attacker finds a new class, the attacker can attack all applications that exist in the environment, and the problem of arbitrary access in deserialization cannot be fundamentally solved. The above optional implementation adopts a white list mechanism and is not affected by future new classes.

[0092] In summary, in the above optional implementation, a dynamic white list of classes is calculated for the user at runtime through an automatic analysis and backtracking mechanism, and the user only needs a simple configuration to reduce the risk of arbitrary calls in the serialization process, improve security, and reduce potential risks.

[0093] In this embodiment, an electronic device is provided, including a memory and a processor, the memory stores a computer program, and the processor is configured to run the computer program to execute the method in the above embodiments.

[0094] The procedures described above can be implemented in a processor or stored in a memory (or computer readable medium) that is permanently, non-permanently, removably or non-removably coupled to the processor. The computer readable medium includes information storage of any method or technology, which can be realized by any method or technology. The information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage device, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer readable medium does not include transitory medium such as modulated data signal and carrier wave.

[0095] These computer programs can also be loaded into a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate computer implemented processes, so that the instructions executed on the computer or other programmable device provide a process for implementing the functions specified in the flowchart Figure 1 The functions specified in one flowchart or multiple flowcharts and / or blocks can be implemented by different modules. Figure 1 The functions specified in one flowchart or multiple flowcharts and / or blocks can be implemented by different modules.

[0096] The embodiment provides the device or system. The device is called a remote procedure call whitelist processing device, which comprises an acquisition module, a search module, a determination module and a configuration module. The acquisition module is used to acquire a class belonging to a first category, the class is a class requiring remote procedure call, the class of the first category is a trusted class, and the trusted class is a class capable of safely performing serialization operation and / or deserialization operation in remote procedure call. The search module is used to search for a class depended on by the class from a class of other categories, the class of other categories is a class whose capability of safely performing serialization operation and / or deserialization operation in remote procedure call is not determined. The determination module is used to determine whether the class depended on by the class is a trusted class. The configuration module is used to configure the trusted class in a whitelist, wherein only the class configured in the whitelist can perform serialization operation and / or deserialization operation in remote procedure call, and the trusted class comprises the class and the class depended on by the class.

[0097] The system or device is used to realize the functions of the method in the above-mentioned embodiments, each module in the system or device corresponds to each step in the method, which has been described in the method and will not be repeated here.

[0098] Optionally, the searching module is configured to search all classes used by the class in sequence according to the dependency chain relationship of the class; and the classes used by the class are all taken as classes depended by the class.

[0099] Optionally, the configuration module is configured to obtain a package name of a package in which the class and / or the classes depended by the class are located; determine all classes under the package name as trusted classes; and add all the classes under the package name determined as the trusted classes to the white list.

[0100] Optionally, the package name comprises N-level package names, where N is greater than or equal to 1, the configuration module is configured to receive an n configured by a user, where n is greater than or equal to 1 and less than or equal to the N; obtain the first n-level package names in the package name; and determine all classes under the first n-level package names as trusted classes.

[0101] Optionally, the determination module is configured to determine whether the classes depended by the class belong to a predetermined category before obtaining a package name of a package in which the classes depended by the class are located, where the predetermined category is preset; and in a case where the classes depended by the class do not belong to the predetermined category, perform the steps of obtaining the package name and determining all classes under the package name as trusted classes again.

[0102] Optionally, the classes of the predetermined category are classes provided by default in a programming tool or a programming environment.

[0103] Optionally, the classes of the predetermined category include classes depended by the classes of the first category and classes configured by the user in advance.

[0104] Optionally, the obtaining module is configured to receive a set of classes input by a user, where the classes in the set are all classes of the first category; the searching module is configured to perform the step of searching the classes depended by each class in the set; and the determination module is configured to determine each class in the set and the classes depended by the class as trusted classes.

[0105] Optionally, the classes of the first category include classes developed by the user himself / herself, and the classes of the other categories include at least one of the following: classes provided by default in a programming tool or a programming environment, and external classes introduced by the user.

[0106] The above optional implementation solves the security hidden trouble problem caused by the serialization tool capable of calling the target class arbitrarily in the prior art in the remote calling process, and further reduces the risk of arbitrary calling in the serialization process, and improves the security of the software product.

[0107] The above merely illustrates the embodiments of the present application and is not intended to limit the present application. The present application can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A method for whitelisting remote procedure calls, comprising: Obtain classes belonging to the first category, wherein the classes are those that need to be remotely invoked, the classes in the first category are trusted classes, and the trusted classes are those that can safely perform serialization and / or deserialization operations in remote procedure calls; From other categories of classes, find the classes that the class depends on, wherein the other categories of classes are classes whose ability to safely perform serialization and / or deserialization operations in remote procedure calls is uncertain; Determine whether the class that the stated class depends on is a trustworthy class; The trusted classes are configured in a whitelist, wherein only classes configured in the whitelist can perform serialization and / or deserialization operations in remote procedure calls, and the trusted classes include the class itself and the classes that the class depends on. Configuring the trusted classes in the whitelist includes: Obtain the package name of the package containing the class and / or the classes that the class depends on; All classes under the specified package name are identified as trustworthy classes; Configure all classes under the package name in the whitelist; The package name includes N-level package names, where N is greater than or equal to 1. All classes under the package name are identified as trustworthy classes, including: Receive the user-configured n, where n is greater than or equal to 1 and n is less than or equal to the N; Retrieve the first n levels of package names from the given package name; All classes under the first n level packages are identified as trustworthy classes.

2. The method of claim 1, wherein, From other categories of classes, finding the classes that the class depends on includes: Based on the dependency chain relationship of the class, find all classes that will be used by the class in sequence; All classes that this class will use are considered as classes that this class depends on.

3. The method of claim 1, wherein, Before obtaining the package name of the package containing the classes that the class depends on, the method further includes: Determine whether the class that the class depends on belongs to a predetermined category, wherein the predetermined category is set in advance; If the class that the class depends on does not belong to the predetermined category, then the step of obtaining the package name and determining all classes under the package name as trustworthy classes is executed.

4. The method of claim 3, wherein, The classes in the predetermined category are those provided by default in programming tools or programming environments.

5. The method of claim 4, wherein, Classes belonging to the predetermined category that are depended upon by classes in the first category, as well as classes pre-configured by the user, are considered trustworthy classes.

6. The method according to any one of claims 1 to 5, wherein, A set of classes that receive user input, wherein all classes in the set are classes of the first category; For each class in the set, the step of finding the classes it depends on is performed, and each class in the set and its dependent classes are determined to be a trustworthy class.

7. The method of claim 6, wherein, The first category of classes includes classes developed by the user, and the other categories of classes include at least one of the following: classes provided by default in programming tools or programming environments, and external classes introduced by the user.

8. A whitelist processing device for remote procedure calls, comprising: The acquisition module is configured to acquire a class belonging to a first category, wherein the class is a class requiring a remote procedure call, and the class of the first category is a trusted class, and the trusted class is a class capable of safely performing serialization and / or deserialization in a remote procedure call. The search module is configured to search for a class depended on by the class from classes of other categories, wherein the classes of the other categories are classes whose capability of safely performing serialization and / or deserialization in a remote procedure call is not determined. The determination module is configured to determine whether the class depended on by the class is a trusted class. The configuration module is configured to configure the trusted class in a white list, wherein only classes configured in the white list are capable of performing serialization and / or deserialization in a remote procedure call, and the trusted class includes the class and the class depended on by the class. The configuration of the trusted class in the white list includes: acquiring a package name of a package in which the class and / or the class depended on by the class is located; determining all classes under the package name as trusted classes; configuring all classes under the package name in the white list. The package name includes N-level package names, where N is greater than or equal to 1, and determining all classes under the package name as trusted classes includes: receiving a user-configured n, where n is greater than or equal to 1 and less than or equal to N; acquiring the first n-level package names in the package name; and determining all classes under the first n-level package names as trusted classes.

9. An electronic device comprising a memory and a processor; wherein, The memory is configured to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method steps of any one of claims 1 to 7.

10. A readable storage medium having computer instructions stored thereon, wherein, The computer instructions are executed by the processor to implement the method steps of any one of claims 1 to 7.

11. A computer program product comprising computer program instructions, wherein, The computer program instructions are executed by the processor to implement the method of any one of claims 1 to 7.

Images