CN116166452A - 一种远程过程调用的白名单处理方法和装置 - Google Patents

Abstract

本申请公开了一种远程过程调用的白名单处理方法和装置，该方法包括：获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类；从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；判断所述类所依赖的类是否为可信任的类；将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作。通过本申请解决了现有技术中在远程调用过程中序列化工具能够任意调用目标类所带来的安全隐患的问题，进而降低了序列化过程中任意调用的风险，提升了软件产品的安全性。

Description

一种远程过程调用的白名单处理方法和装置

技术领域

本申请涉及到软件领域，具体而言，涉及一种远程过程调用的白名单处理方法和装置。

背景技术

传统的软件项目架构一般为单体架构。这种单体架构的特点是将所有的功能集中在一个项目中进行开发和测试，最终上线时将此项目打包进行部署。图1是根据现有技术的采用单体架构进行项目开发的示意图，如图1所示，网上商城的项目中包括三个模块：订单模块、用户模块和商品模块，这三个模块耦合非常紧密，其使用同一个服务端来提供服务，该服务端运行在服务器上，这三个模块的数据保存在数据库中，三个模块在使用数据的时候也通过服务端访问同一个数据库。这种单体架构的有点是架构简单易上手，并且在部署时操作容易，只需将一个项目打包即可。

单体架构的项目有一个缺点，那就是每个功能模块之间的耦合度太高，如果其中一个功能模块出现问题，那么整个项目都得停下进行维护，不然项目运行就会发生崩溃或者异常。在图1中示出的项目中，如果产品模块出现问题，则该项目中的服务端就需要下线进行维护，这会导致所有的模块都无法使用。

为了解决单体架构所存在的问题，引入了微服务，微服务是一种面向服务的架构风格，其中一个项目被构建为多个不同的小型服务的集合而不是单个服务程序。与服务程序不同的是，微服务可以同时运行多个独立的服务程序，而这些独立的服务程序可以使用不同的编码或或编程语言来创建。图2是根据现有技术的采用微服务进行项目开发的示意图，如图2所示，网上商城项目可以分为三个独立的服务程序：产品服务、订单服务和用户服务，这三个服务均为微服务，三个服务分别通过各自的服务端来提供服务，每个服务均可以单独访问数据库(Data Base，简称为DB)，用户通过电脑(Personal Computer，简称为PC)或智能终端(例如手机)来访问这三个服务。在微服务中，如果产品服务出现问题，则只需要下线产品服务即可，用户服务和订单服务可以继续运行。在微服务中由于各个服务是独立的，因此会经常涉及到远程调用。

在微服务远程调用中，由于网络连接只能承载二进制数据，需要将抽象的请求对象通过序列化工具转化成二进制数据，在通过网络传输后再将二进制数据发序列化为请求对象，序列化和反序列化可以统称为序列化过程。在序列化过程中由于目标类存在漏洞，序列化工具可能超过正常的访问范围，甚至执行远程命令。这会给微服务带来安全隐患。

发明内容

本申请实施例提供了一种远程过程调用的白名单处理方法和装置，以至少解决现有技术中在远程调用过程中序列化工具能够任意调用目标类所带来的安全隐患的问题。

根据本申请的一个方面，提供了一种远程过程调用的白名单处理方法，包括：获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类，所述可信任的类是能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；判断所述类所依赖的类是否为可信任的类；将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作，所述可信任的类包括所述类和所述类所依赖的类。

根据本申请的另一个方面，还提供了一种远程过程调用的白名单处理装置，包括：获取模块，用于获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类，所述可信任的类是能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；查找模块，用于从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；确定模块，用于判断所述类所依赖的类是否为可信任的类；配置模块，用于将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作，所述可信任的类包括所述类和所述类所依赖的类。

根据本申请的另一个方面，还提供了一种电子设备，包括存储器和处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现上述的方法步骤。

根据本申请的另一个方面，还提供了一种可读存储介质，其上存储有计算机指令，其中，该计算机指令被处理器执行时实现上述的方法步骤。

根据本申请的另一个方面，还提供了一种计算机程序产品，其包括计算机程序指令，其中，该计算机程序指令被处理器执行时实现上述的方法。

在本申请实施例中，采用了获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类，所述可信任的类是能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；判断所述类所依赖的类是否为可信任的类；将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作，所述可信任的类包括所述类和所述类所依赖的类。通过本申请解决了现有技术中在远程调用过程中序列化工具能够任意调用目标类所带来的安全隐患的问题，进而降低了序列化过程中任意调用的风险，提升了软件产品的安全性。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据现有技术的采用单体架构进行项目开发的示意图；

图2是根据现有技术的采用微服务进行项目开发的示意图；

图3是根据相关技术的RPC的交互示意图；

图4是根据本申请实施例的远程过程调用的白名单处理方法的流程图；

图5是根据本申请实施例的JAVA运行时能够加载的类的示意图；

图6是根据本申请实施例的JAVA三方类安全性示意图；

图7是根据本申请实施例的通过暴露接口查找安全类的示意图；以及，

图8是根据本申请实施例的包名回溯流程的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在以下实施方式中涉及到微服务，下面首先以下实施方式中涉及到技术术语进行说明。

JVM

JVM是Java Virtual Machine(Java虚拟机)的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。引入Java虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码(字节码)，就可以在多种平台上不加修改地运行。

JDK

Java语言的软件开发工具包(Java Development Kit，简称为JDK)主要用于各种设备(包括移动设备和嵌入式设备)上的java应用程序开发。JDK是整个Java开发的核心，它包含了Java的运行环境(JVM+Java系统类库)和Java工具。

POJO

简单的Java对象(Plain Ordinary Java Object，简称为POJO)实质上可以理解为简单的实体类，顾名思义POJO类的作用是方便程序员使用数据库中的数据表，对于广大的程序员，可以很方便的将POJO类当做对象来进行使用。

RPC

远程过程调用(Remote Procedure Call，简称为RPC)是一种通过网络从远程计算机程序上请求服务，RPC不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在并为程序之间传输信息数据。图3是根据相关技术的RPC的交互示意图，如图3所示，在进行远程过程调用时可以包括如下步骤：

步骤1，客户端(client)以本地调用方式调用服务。

步骤2，客户端存根(client stub)接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体(将消息体对象序列化为二进制)。

步骤3，客户端通过套接字(sockets)将消息发送到服务端。

步骤4，服务端存根(server stub)收到消息后进行解码(将消息对象反序列化)。

步骤5，服务端存根根据解码结果调用本地的服务。

步骤6，本地服务执行并将结果返回给服务端存根。

步骤7，服务端存根将返回结果打包成消息(将结果消息对象序列化)。

步骤8，服务端(server)通过sockets将消息发送到客户端。

步骤9，客户端存根接收到结果消息，并进行解码(将结果消息发序列化)。

步骤10，客户端得到最终结果。

RPC可以把步骤2、步骤3、步骤4、步骤7、步骤8以及步骤9这些步骤都封装起来。

在上述步骤中，涉及到序列化。下面对序列化进行说明，在微服务远程调用中，由于网络连接只能承载二进制数据，需要将抽象的请求对象通过序列化工具转化成二进制数据，序列化就是将需要通过网络传输的软件对象转换为二进制数据的过程；对应的，反序列化就是将二进制数据转换为软件对象的过程。

在远程调用中，由于服务端只能被动接受来自客户端的请求，需要服务端无条件信任来自客户端的数据。序列化工具能够调动任意范围的目标类，这就导致一定安全隐患。例如在反序列化过程中借助序列化工具能够访问类的特定方法(如设置属性的方法)的方式访问存在风险的类，进而执行任意访问乃至执行远程命令，这会给生产环境的安全性带来威胁。

在现有技术中使用的RPC框架，例如gRPC、Thrift、Jboss、RMI、Sofa RPC、HessianRPC等都提供了序列化、反序列化的能力，这些RPC框架均存在上述的安全隐患。为了解决这个问题，可以采用如下三个可选的方式来解决。

方式一

RPC框架通过要求用户请求和返回的接口必须按照接口描述语言(Interfacedescription language，简称为IDL)声明的格式预先定义，在运行时仅允许RPC接口上直接声明的结构体进入序列化过程，对于所有不符合该结构的数据全部解决。这种方式要求用户在开发的时候就按照对应的格式进行定义，从而影响了用户开发效率。并且，这种方式还这会导致无法完整支持某些编程语言的特性，例如，无法支持Java的泛型和类的向上、向下转型机制，无法和正常调用Java方法一样调用RPC接口。

方式二

在该方式中需要用户手动配置白名单，即需要用户提前向序列化框架注入一个预期的白名单类列表，通过在反序列化的过程中检查输入的信息是否在白名单列表中，如果不存在则禁止反序列化，以此来避免任意访问的问题。该方式由于需要用户声明式配置所可能使用到的类信息，影响用户体验。通过该方式虽然可以通过枚举所有所用到的类通过白名单的方式(即在序列化的过程中仅允许访问白名单中的类)避免访问有问题的目标类，但是，这种方式需要用户进行复杂的配置，具有一定的局限性。

方式三

在该方式中使用了黑名单，即由序列化框架内置一个不信任类的列表，通过在反序列化的过程中检查输入的信息是否在黑名单列表中，如果存在则禁止反序列化，以此来避免访问已知的潜在风险类的问题。在该方式中由于黑名单列表是预先生成的，如果攻击者找到一个新的类则可以攻击所有环境中存在此类的应用，无法从根本上解决反序列化任意访问的问题。

通过对上述三种方式分析可以得到，其中的方式二应该是最容易实现的，但是对于方式二来说目前需要用户手动配置所有的白名单，一方面这会加大用户的工作量，降低用户体验；另一方面，由于类之间还存在各种依赖关系，用户也可能会遗漏配置白名单的类。

为了解决上述问题，在以下可选实施方式中提供了一种远程过程调用的白名单处理方法，图4是根据本申请实施例的远程过程调用的白名单处理方法的流程图，如图4所述，下面对图4中所涉及的方法包括的步骤进行说明。

步骤S402，获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类，所述可信任的类是能够安全执行远程过程调用中序列化操作和/或反序列化操作的类。

在该步骤中，第一类别的类可以是来自用户进行远程过程调用的时候所需要基于的公共接口类(API)，客户端发起请求到远程过程调用的时候会有一个接口的定义，该接口定义的类可以作为第一类别的类。在此公共API仅仅是基础定义的类，在远程过程调用中，实际使用的类比公共API多很多。因此，在找到第一类别的类之后再通过步骤S404就可以找到其他可信任的类。

另外，在该步骤中可以由用户制定一些属于第一类别的类，在图1涉及的步骤中以及在以下可选的实施方式中，用户可以包括使用开发环境进行软件开发的开发者。通常情况下，开发者能够确定哪些类是比较安全的。例如，如果该类是用户自己开发的，则用户对自己开发的类是比较清楚的，其不会涉及到安全问题。因此，作为一个可选的实施方式用户可以将自己开发的类作为第一类别的类。当然，除了用户自己开发的类之外，如果用户可以确定某个类在序列化流程中也是安全的，则也可以作为第一类别的类。在该步骤中并不限制第一类别的类具体包括哪些内容，只要能够获取到一个或多个属于第一类别的类，那就可以实现该步骤的目的。

步骤S404，从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类。

在很多场景下，类和类之间均存在一定的依赖关系。依赖关系是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义，例如，在网上商城项目中，订单类(order)需要访问用户账户类(account)，所以在订单类中需要引用账户类，即订单类依赖账户类，如果修改账户类，会影响到订单类。在该步骤中，由于第一类别中的类均是可信任的类，因此在该步骤中在其他类别中查找可信任的类所依赖的类，其他类别中的类尚未确定是否属于可信任的类，通过依赖关系的查找可以从步骤S402中得到的可信任的类查找到更多的可信任的类，这样就减少了用户手工输入的工作量。

步骤S406，判断所述类所依赖的类是否为可信任的类。

在查找到第一类别中的类所依赖的类之后，由于第一类别中的类需要从所依赖的类中返回数据等，因此第一类别所依赖的类也必然是可信任的类。例如，在第一类别的类是用户自行开发的类的情况下，用户在开发这些类的过程中其所依赖的类也是用户选择出来来进行使用的，因此，这些类也可以认为是可信任的类。

步骤S408，将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作，所述可信任的类包括所述类和所述类所依赖的类。

在该步骤中，在得到可信任的类之后，可以将可信任的类均配置在白名单中，该白名单是用于远程过程调用中进行序列化和/或反序列化操作的判断，例如，通过在反序列化的过程中检查输入的信息是否在白名单中，如果不存在则禁止反序列化。由于白名单中的类除了预先配置的第一类别的类之外，还包括了自动查找到的这些类所依赖的来，减少了用户的配置操作，也保证了白名单中的类的可靠性。因此，通过上述步骤解决了现有技术中在远程调用过程中序列化工具能够任意调用目标类所带来的安全隐患的问题，进而降低了序列化过程中任意调用的风险，提升了软件产品的安全性。

在上述步骤S402中涉及到获取属于第一类别中的类，在一个可选实施方式中，可以由用户将一个项目中的所有自行开发的类作为一个子集均作为第一类别中的类，然后根据该子集中的每个类找到所依赖的类，从而构成全集。该全集中的类就是该项目中所有的可信任的类，然后将全集中的类均配置在白名单中，这样就可以将一个项目的所有可信任的类均配置在白名单中。即在该可选实施方式中，可以接收用户输入的类的集合，其中，所述集合中的类均是所述第一类别的类；对于所述集合中的每一个类均执行查找所依赖的类的步骤，并将所述集合中的每一个类和其所依赖的类均确定为可信任的类。通过该可选实施方式进一步减少了用户配置的工作量，提高了用户体验。

在查找一个类所依赖的类的过程中，通过对代码的分析就可以得到该类所使用的类，该类所使用的类均可以认为是该类所依赖的类，即在该可选实施方式中，从其他类别的类中查找所述类所依赖的类可以包括如下步骤：根据所述类的依赖链关系依次查找所有会被所述类使用到的类；将所述类会使用到的类均作为所述类所依赖的类。当然也可以使用其他方式来查找一个类所依赖的类，在此不再一一赘述。

在查找到所依赖的类之后，为了能够找到更多的可信任的类，还可以利用有些编程语言中提供的包(package)的功能，来查找到更多可信任的类。在编程中，对于每个类可以提供一个保存该类的目录，该目录可以分为多级目录，每个类所在的目录可以打包成一个包，包的名字中可以题体现出类所在的目录。例如，一个包的名称为目录1.目录2.目录3，这其中的“.”就是用来进行对不同级别的目录来进行分割的，除了使用“.”之外也可以使用特殊符合来对目录进行分割。一个包中可以包括多个类，例如，目录1.目录2.目录3包中可以包括3个类，这三个类均在目录3下，目录3在目录2中，目录2在目录1中；又例如，目录1.目录2包中除了包括上述包中的3个类之外还包括目录2中的类。通常情况下，一个包所包括的多个类是功能相似的类，因此，如果类在同一个包中，则可以认为一个包中的类的性质也是类似的，即如果包中的一个类是可信任的类，则该包中的类均可以认为是可信任的类。基于上述包和类的关系，在一个可选的实施方式中，可以获取所述类和/或所述类所依赖的类所在的包的包名；将所述包名下的所有类确定为可信任的类；将确定为所述可信任的类的所述包名下的所有类添加到所述白名单中。通过该可选的实施方式，可以进一步扩展可信任的类的数量，加强白名单的作用。

正如上述段落所提到的那样，一个包可以包括N级包名，例如目录1.目录2.目录3这个包就包括了3级包名，考虑到不用开发者可能会使用不同的命名规则，因此，如果一个类在目录1.目录2.目录3中，则可以认为目录3下的所有类均是可信任的类；或者，也可以认为目录2下的所有类均是可信任的类；或者也可以认为目录1下所有的类均是可信任的类。在一个可选的实施方式中，可以让用户来配置可以包括几级包名。即所述包名中包括N级包名，其中N大于等于1，将所述包名下的所有类确定为可信任的类可以包括如下步骤：接收用户配置的n，其中，n大于等于1，并且，n小于等于所述N；获取所述包名中的前n级包名；将前n级包名下所有的类确定为可信任的类。在上述的例子中，如果在目录1.目录2.目录3的包中包括了一个可信任的类，而用户配置的n为2，则可以认为目录1.目录2下所有的类均是可信任的类。

这种使用包名来确定类是否为可信任的类的方式可能并不是对于所有的类别的类均适用。在这种情况下，还可以由用户来配置哪些类是可以使用包名来确定可信任的类的，哪些类是不可以使用包名来确定可信的类的，即在一个可选的实施方式中，在获取所述类所依赖的类所在包的包名之前，所述方法还可以包括如下步骤：判断所述类所依赖的类是否属于预定类别，其中，所述预定类别是预先设置的；在所述类所依赖的类不属于所述预定类别的情况下，再执行获取所述包名并将所述包名下的所有类确定为可信任的类的步骤。例如，所述预定类别的类为编程工具或者编程环境中所默认提供的类，这是因为编程工具或编程环境所默认提供的类的类型比较多，其中就可能包括了不受信任的类，因此，对于该类别的类可以考虑不适用包名来确定可信任的类的方式。那么对于编程工具或者编程环境所默认类，可以由用户自行配置哪些是可信任的类，或者该类中被所述第一类别的类所依赖的类认为是可信任的类。

由上述可选实施方式可知，所述第一类别的类可以包括所述用户自行开发的类，所述其他类别的类包括以下至少之一：编程工具或者编程环境中所默认提供的类、所述用户引入的外部类。在以下实施方式中可以将第一类别的类称为一方，将编程工具或者编程环境中所默认提供的类称为二方，将所述用户引入的外部类称为三方。

以上实施方式可以应用到各种编程语言中，下面以Java语言为例进行说明。图5是根据本申请实施例的JAVA运行时能够加载的类的示意图，如图5所示，对于JVM环境来说，在Java的运行时环境内，所有能够被加载的类可以分为三种类型，分别是用户自行开发的类、用户使用JDK环境后由JDK默认提供的类和用户通过类路径引入的外部类，本文为了方便描述分别使用一方、二方和三方进行指代。其中，一方是用户自行开发的类，二方是JDK默认提供的类，三方是由用户引入的外部类。

在软件的安全实践中，一般认为由用户(使用框架进行软件开发的开发者)提供的一方类是默认安全的，因为这部分类由用户开发，其行为是用户定义的，从框架侧来说，需要无条件信任使用框架的开发者定义的结构是正确的，否则序列化就没有意义了。而二方类和三方类不受用户的控制，由于供应链安全等问题的影响，二方库和三方库可能存在有反序列化漏洞的类。例如，在二方类中，JDK中存在大量的ToString方法能够可能调用运行时Runtime的类；又例如，三方的如rometools也存在本地访问的风险，其中，ToString方法会返回一个“以文本方式表示”此对象的字符串，rometools是一个序列化和反序列化工具。图6是根据本申请实施例的JAVA三方类安全性示意图，如图6所示，一方类默认是安全的，而二方类和三方类中部分类是安全的，部分类是不安全。因此，需要发现二方类和三方类中安全的类放入到白名单中。

为了将这部分安全可信的类和存在反序列化漏洞的类区分开来，采用了自动递归分析的方法获取所有可能用于序列化的安全可信类。图7是根据本申请实施例的通过暴露接口查找安全类的示意图，如图7所示，在微服务调用中，应用需要先对外暴露接口(即图中示出的com.example.service.DemoService，这是一个示例接口)，通过上述可选实施方式中对类角色的区分，这些接口属于一方类，由用户直接提供的，默认是安全的。而这个接口类往往会依赖部分二方类和三方类，二方类如java.lang.String(Java字符串类，包含了字符串的值和实现字符串相关操作的一些方法)，三方类如团队内开发的公共组件等。然后通过依赖链关系分析的机制，自动找到所有会被RPC接口使用到的类，并将它们标记为可信类，而剩下的所有其他二方类、三方类将被标记为不可信类，在反序列化过程中将被拒绝。例如，在图7中分析到接口所使用的二方类为java.lang.String，接口所使用的三方类为org.example.pojo.Greeter，由于该接口是一方类是安全的，因此，作为二方类的java.lang.String以及作为三方类的org.example.pojo.Greeter也是安全的，即这两个类可以添加到白名单中。在三方类中还存在未使用的类，例如，com.demo.good，不会被添加到白名单中。对于已经知道的不安全的类，例如，com.rometools.rome类，不添加到白名单中，或者可以也可以添加到黑名单中。

在找到所有可信类之后，作为一个可选的实施方式，为了更好的适配Java的泛型和类的向上、向下转型机制，还可以将提供包名回溯机制，也即是在找到一个类之后也将其包名下所有的类纳入到可信列表中。下面首先对Java中包的概念进行说明。

为了便于对硬盘上的文件进行管理，通常会将文件分目录存放。同理，在程序开发中，也需要将编码的类在项目中分目录存放，以便于文件管理。为此，Java引入了包(package)机制，程序可以通过声明包的方式对Java类分目录管理。Java中的包是专门用来存放目录的，通常功能相同的类存放在同一个包中。包通过package关键字声明，例如，packagecn.zhejiang.hangzhou；//该代码就生成了一个三级目录的包，第一级目录是cn，第二级目录是zhejiang，第三级目录是hangzhou。

需要注意的是，在开发Java程序时，定义的类通常都是含有包名的。在开发时，一个项目中可能会使用很多包，当一个包中的类需要调用另一个包中的类时，需要使用import关键字引入需要的类。使用import关键字可以在程序中导入某个指定包下的类，这样就不必在每次用到该类时都书写完整的类名，简化了代码量。在JDK中，不同功能的类都放在不同的包中，其中Java的核心类主要放在java包及其子包下，Java扩展的大部分类都放在javax包及其子包下，JDK中还有很多其他的包，例如用于数据库编程的java.sql包、编写GUI的javax.swing包等，JDK中所有包中的类构成了Java类库。

在Java开发中，不同组织提供的类其包名会有很大的差异，如Dubbo(一个组织的名称)所使用的包名是org.apache.dubbo，Spring(另一个组织的名称)使用的包名是org.springframework。考虑到这个问题，可以通过提供一个n级包名的变量供用户设置，用户可以将此变量配置为其所在机构的默认包名深度。

例如，当n配置为3的时候，对于com.example.dance.pojo.User类，在执行的时候也会将com.example.dance下所有的类也加入到可信任列表中，在该例子中，在隔离出有问题的三方库的同时尽可能覆盖用户所有定义的类。

又例如，当n配置为4的时候，对于com.example.dance.pojo.User类，在执行的时候会将对于com.example.dance.pojo下所有的类也加入到可信任的列表中，该列表中的类均会加入到白名单中。

在实际应用时，发现对于某些编程语言提供的二方类来说不太使用回溯机制，例如，对于JDK提供的二方类就不适用自动回溯机制，因为JDK环境中存在大量有反序列化漏洞的类且在开启自动回溯后很容易导致这部分类加载进可信列表中，出于安全考虑对于JDK二方类将使用内置白名单+仅加载特定已经被使用到的类的方式。

图8是根据本申请实施例的包名回溯流程的示意图，如图8所示，原始的输入有RPC接口和内置部分JDK类白名单类两个方式，来自RPC接口的类将被自动视为可信类，而可信类的属性和接口的入参和/或出参类型也将被自动视为可信类。所有的可信类接下来会被判断是否为二方JDK所提供的，如果是则仅添加该类自身进入可信类列表，如果不是则判断是否存在n级包名。如果存在则将该n级包名下的所有类都加入到可信类列表，如果不存在则仅添加该类自身进入可信类列表，而内置部分JDK类白名单类将直接加入到可信类列表。最终得到的可信类列表将用于将存在风险的序列化拦截。

对于微服务来说，可以选择微服务下用户订阅或发布的接口作为基础可信类(即第一类别的类)，该基础可信类可以覆盖RPC领域中序列化和/或反序列化所可能使用的场景，通过动态生成可信任列表的方式降低了用户的使用成本，提升了应用的安全性。并且，还可以通过使用包名自动分析的机制来完善整体可信任列表，很大程度上覆盖所有可能使用的类，降低由于开启序列化可信任列表对用户在使用子类或者泛型进行微服务调用的影响。

下面将上述可选实施方式与上文中提到的三种方式进行比较。

方式一

RPC框架通过要求用户请求和返回的接口必须按照接口描述语言IDL声明的格式预先定义，在运行时仅允许RPC接口上直接声明的结构体进入序列化过程，对于所有不符合该结构的数据全部解决。

这种方式对于用户体验影响大，要求用户在开发的时候就按照对应的格式进行定义，且无法完整支持Java的泛型和类的向上、向下转型机制，无法和正常调用Java方法一样调用RPC接口。上述可选实施方式仍基于用户自定义的POJO进行规划，不需要用户定义IDL，且通过自动递归、包回溯机制获取所有用户可能使用到的类来满足用户多种的使用方式。

方式二

在该方式中需要用户手动配置白名单，即需要用户提前向序列化框架注入一个预期的白名单类列表，通过在反序列化的过程中检查输入的信息是否在白名单列表中，如果不存在则禁止反序列化，以此来避免任意访问的问题。该方式由于需要用户声明式配置所可能使用到的类信息，影响用户体验。

这种方式需要用户手工声明式配置所可能使用到的类信息，具有一定的局限性。上述可选实施方式通过自动递归、包回溯机制获取所有用户可能使用到的类避免用户显式配置，提升用户体验。

方式三

在该方式中使用了黑名单，即由序列化框架内置一个不信任类的列表，通过在反序列化的过程中检查输入的信息是否在黑名单列表中，如果存在则禁止反序列化，以此来避免访问已知的潜在风险类的问题。

这种方式中由于黑名单列表是预先生成的，如果攻击者找到一个新的类则可以攻击所有环境中存在此类的应用，无法从根本上解决反序列化任意访问的问题。上述可选实施方式采用的是白名单机制，不受未来新增类的影响。

综上，在上述可选实施方式中，通过一个自动分析、回溯的机制动态为用户在运行时计算出白名单类列表，用户只需要简单的一个配置，就可以降低序列化过程中任意调用的风险，提升安全性，降低潜在的风险。

在本实施例中，提供一种电子装置，包括存储器和处理器，存储器中存储有计算机程序，处理器被设置为运行计算机程序以执行以上实施例中的方法。

上述程序可以运行在处理器中，或者也可以存储在存储器中(或称为计算机可读介质)，计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

这些计算机程序也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤，对应与不同的步骤可以通过不同的模块来实现。

该本实施例中就提供了这样的一种装置或系统。该装置称为一种远程过程调用的白名单处理装置，包括：获取模块，用于获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类，所述可信任的类是能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；查找模块，用于从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；确定模块，用于判断所述类所依赖的类是否为可信任的类；配置模块，用于将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作，所述可信任的类包括所述类和所述类所依赖的类。

该系统或者装置用于实现上述的实施例中的方法的功能，该系统或者装置中的每个模块与方法中的每个步骤相对应，已经在方法中进行过说明的，在此不再赘述。

可选地，所述查找模块，用于根据所述类的依赖链关系依次查找所有会被所述类使用到的类；将所述类会使用到的类均作为所述类所依赖的类。

可选地，其中，所述配置模块，用于获取所述类和/或所述类所依赖的类所在的包的包名；将所述包名下的所有类确定为可信任的类；将确定为所述可信任的类的所述包名下的所有类添加到所述白名单中。

可选地，所述包名中包括N级包名，其中N大于等于1，所述配置模块用于接收用户配置的n，其中，n大于等于1，并且，n小于等于所述N；获取所述包名中的前n级包名；将前n级包名下所有的类确定为可信任的类。

可选地，所述确定模块，用于在获取所述类所依赖的类所在包的包名之前，判断所述类所依赖的类是否属于预定类别，其中，所述预定类别是预先设置的；在所述类所依赖的类不属于所述预定类别的情况下，再执行获取所述包名并将所述包名下的所有类确定为可信任的类的步骤。

可选地，所述预定类别的类为编程工具或者编程环境中所默认提供的类。

可选地，属于所述预定类别的类中被所述第一类别的类所依赖的类以及用户预先配置的类为可信任的类。

可选地，所述获取模块，用于接收用户输入的类的集合，其中，所述集合中的类均是所述第一类别的类；所述查找模块用于对于所述集合中的每一个类均执行查找所依赖的类的步骤，所述确定模块用于将所述集合中的每一个类和其所依赖的类均确定为可信任的类。

可选地，所述第一类别的类包括所述用户自行开发的类，所述其他类别的类包括以下至少之一：编程工具或者编程环境中所默认提供的类、所述用户引入的外部类。

通过上述可选实施方式解决了现有技术中在远程调用过程中序列化工具能够任意调用目标类所带来的安全隐患的问题，进而降低了序列化过程中任意调用的风险，提升了软件产品的安全性。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (13)

1.一种远程过程调用的白名单处理方法，包括：

获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类，所述可信任的类是能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；

从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；

判断所述类所依赖的类是否为可信任的类；

将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作，所述可信任的类包括所述类和所述类所依赖的类。

2.根据权利要求1所述的方法，其中，从其他类别的类中，查找所述类所依赖的类包括：

根据所述类的依赖链关系依次查找所有会被所述类使用到的类；

将所述类会使用到的类均作为所述类所依赖的类。

3.根据权利要求1所述的方法，其中，将所述可信任的类配置在白名单中包括：

获取所述类和/或所述类所依赖的类所在的包的包名；

将所述包名下的所有类确定为可信任的类；

将所述包名下的所有类配置在所述白名单中。

4.根据权利要求3所述的方法，其中，所述包名中包括N级包名，其中N大于等于1，将所述包名下的所有类确定为可信任的类包括：

接收用户配置的n，其中，n大于等于1，并且，n小于等于所述N；

获取所述包名中的前n级包名；

将前n级包名下所有的类确定为可信任的类。

5.根据权利要求3所述的方法，其中，在获取所述类所依赖的类所在包的包名之前，所述方法还包括：

判断所述类所依赖的类是否属于预定类别，其中，所述预定类别是预先设置的；

在所述类所依赖的类不属于所述预定类别的情况下，再执行获取所述包名并将所述包名下的所有类确定为可信任的类的步骤。

6.根据权利要求5所述的方法，其中，所述预定类别的类为编程工具或者编程环境中所默认提供的类。

7.根据权利要求6所述的方法，其中，属于所述预定类别的类中被所述第一类别的类所依赖的类以及用户预先配置的类为可信任的类。

8.根据权利要求1至7中任一项所述的方法，其中，

接收用户输入的类的集合，其中，所述集合中的类均是所述第一类别的类；

对于所述集合中的每一个类均执行查找所依赖的类的步骤，并将所述集合中的每一个类和其所依赖的类均确定为可信任的类。

9.根据权利要求8所述的方法，其中，所述第一类别的类包括所述用户自行开发的类，所述其他类别的类包括以下至少之一：编程工具或者编程环境中所默认提供的类、所述用户引入的外部类。

10.一种远程过程调用的白名单处理装置，包括：

获取模块，用于获取属于第一类别的类，其中，所述类为需要进行远程过程调用的类，所述第一类别的类是可信任的类，所述可信任的类是能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；

查找模块，用于从其他类别的类中，查找所述类所依赖的类，其中，所述其他类别的类是未确定是否能够安全执行远程过程调用中序列化操作和/或反序列化操作的类；

确定模块，用于判断所述类所依赖的类是否为可信任的类；

配置模块，用于将所述可信任的类配置在白名单中，其中，只有配置在白名单中的类才能够在远程过程调用中执行序列化操作和/或反序列化操作，所述可信任的类包括所述类和所述类所依赖的类。

11.一种电子设备，包括存储器和处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现权利要求1至9任一项所述的方法步骤。

12.一种可读存储介质，其上存储有计算机指令，其中，该计算机指令被处理器执行时实现权利要求1至9任一项所述的方法步骤。

13.一种计算机程序产品，其包括计算机程序指令，其中，该计算机程序指令被处理器执行时实现权利要求1至9任一项所述的方法。

Images