用于提高Java沙箱安全性的方法及装置与流程

本申请涉及计算机安全技术领域，特别涉及一种用于提高Java沙箱安全性的方法及装置。

背景技术：

在云计算的场景中，用户提供Java语言编写的代码，由云计算平台执行所述代码。由于所述代码往往存在很多的安全问题(如黑客的攻击代码)，一般会在Java沙箱(Java Sandbox)中执行。

Java沙箱提供了一种按照策略文件限制代码权限的执行环境。Java沙箱运行代码过程中，当调用到方法checkPermission时，Java沙箱的安全管理器(Security Manager)会对所述代码进行权限检查。所述权限检查用于判断所述代码运行过程中调用栈中每一层的方法是否具有策略文件中的权限，所述权限可以包括是否允许写、是否允许读或者是否允许使用网络等；如果所述调用栈中每一层的方法都具有权限，则将所述代码视为是安全的，如果所述调用栈中任一层的方法不具有权限，则将所述代码视为不安全的。

现有技术中，所述云计算平台会提供平台的特权方法，由于所述特权方法具有系统域(system domain)，而安全管理器不会对具有系统域的方法进行权限检查，所以所述特权方法可以绕过所述安全管理器权限检查的步骤。一般的，用户的代码是不允许直接调用特权方法的，用户的代码只能通过可信任的方法(拥有签名的方法)间接的调用特权方法。但是恶意用户通过反射、提权等手段可以使代码直接调用特权方法，当代码直接调用特权方法时，会使得该代码也具有系统域，从而能绕过安全管理器的权限检查。如此，恶意用户的代码就突破了Java沙箱的防护。

综上所述，现有技术中存在Java沙箱安全性不高的问题。

技术实现要素：

本申请实施例的目的是提供一种用于提高Java沙箱安全性的方法及装置，用以解决现有技术中Java沙箱安全性不高的问题。

为解决上述技术问题，本申请实施例提供的用于提高Java沙箱安全性的方法及装置是这样实现的：

一种用于提高Java沙箱安全性的方法，包括：

对待检查代码进行权限检查；

判断所述代码的调用栈中是否存在绕过所述权限检查的方法；

若存在绕过所述权限检查的方法，则判断所述调用栈中方法是否存在签名；

若不存在签名，则判定所述待检查代码存在安全问题。

一种用于提高Java沙箱安全性的装置，包括：

检查模块，用于对待检查代码进行权限检查；

第一判断模块，用于判断所述代码的调用栈中是否存在绕过所述权限检查的方法；

第二判断模块，用于在所述代码的调用栈中存在绕过所述权限检查的方法时，判断所述调用栈中方法是否存在签名；

确定模块，用于在所述调用栈中方法不存在签名时，判定所述待检查代码存在安全问题。

由以上本申请实施例提供的技术方案可见，本申请实施例提供的一种用于提高Java沙箱安全性的方法及装置，可以克服待检查代码直接调用特权方法后绕过权限检查从而造成Java沙箱安全性低的问题，通过对存在绕过权限检查的方法所在调用栈中签名进行检查，若所述调用栈中方法不存在签名，则判定待检查代码存在安全问题。如此，提高了Java沙箱的安全性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例中提供的用于提高Java沙箱安全性的方法的流程图；

图2为本申请一实施例中提供的用于提高Java沙箱安全性的方法的流程图；

图3为本申请一实施例中提供的用于提高Java沙箱安全性的方法的流程图；

图4为本申请一实施例中提供的用于提高Java沙箱安全性的方法的流程图；

图5为本申请一实施例中提供的用于提高Java沙箱安全性的方法的流程图；

图6为本申请一实施例中提供的用于提高Java沙箱安全性的装置的模块示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1为本申请一实施例中提供的提高Java沙箱安全性的方法的流程图。本 实施例中，所述方法包括如下步骤：

S100：对待检查代码进行权限检查；

在本申请实施例中，待检查代码是用户通过Java语言编写的代码，该代码中包含有用户方法。

如上所述，Java沙箱运行待检查代码过程中，当调用到方法checkPermission时，安全管理器会对所述待检查代码进行权限检查。所述权限检查用于判断所述代码运行过程中调用栈中每一层的方法是否具有策略文件中的权限，所述权限可以包括是否允许写、是否允许读或者是否允许使用网络等；如果所述调用栈中每一层的方法都具有权限，则将所述代码视为是安全的，如果所述调用栈中任一层的方法不具有权限，则将所述代码视为不安全的。

以下例子1为云计算场景中用户使用main()方法打开文件名为filename操作的调用栈：

如上所示，该调用栈的调用过程为：首先第4层方法main()调用第3层方法readwrapper(filename)，再调用第2层方法FileInputSteam(filename)，再调用第1层方法checkRead(filename)，然后调用第0层方法checkPermission(FILE_READ_ACTION)。该调用栈中，第4层方法main()属于用户方法，第3层方法readwrapper()属于云计算平台的公有方法(具有签名“alibaba”的可信任方法)，第2层方法FileInputSteam()属于Java系统方法，第1层方法checkRead()属于Java沙箱的方法，第0层方法checkPermission()属于Java沙箱的方法。在第0层checkPermission(FILE_READ_ACTION)触发后，进入权 限检查。该权限检查会从策略文件中获取是否允许读的权限，从而对调用栈中每一层的方法进行检查。由于第0层和第1层的方法为Java沙箱的方法，具有读的权限，第2层的方法为Java系统方法，也具有读的权限，第3层的方法为公有方法，也具有读的权限，第4层的方法为用户方法，由于打开文件需要获取读的权限，若所述策略文件中允许读，则第4层的方法可以获取读的权限，即第4层的方法具有读的权限。这样，因为调用栈中每一层的方法都具有权限，所以待检查代码是安全的，用户可以打开云计算平台中文件名为filename的文件。反之，若所述策略文件不允许读，则第4层的方法不能获取读的权限，即第4层的方法不具有读的权限。这样，因为调用栈中存在不具有权限的方法，所以待检查代码是不安全的，用户不能打开云计算平台中文件名为filename的文件。

以下例子2为在云计算平台提供了特权方法doPrivileged()时，该云计算场景中用户使用main()方法打开文件名为filename操作的调用栈：

该调用栈与上一例子1中的调用栈不同之处在于，在方法main()调用方法readwrapper(filename)之间，多了第5层方法privilegedwrapper()和第4层方法doPrivileged()，即第6层方法main()调用第5层方法privilegedwrapper()，再调用第4层方法doPrivileged()，再调用第3层方法readwrapper(filename)。该调用栈中，第6层方法main()属于用户方法，第5层方法privilegedwrapper()和第3层方法readwrapper(filename)属于云计算平台的公有方法，第4层方法doPrivileged()属 于云计算平台的特权方法，第2层方法FileInputSteam(filename)属于Java系统方法，第1层方法checkRead()属于Java沙箱的方法，第0层方法checkPermission()属于Java沙箱的方法。在第0层checkPermission(FILE_READ_ACTION)触发后，进入权限检查。该权限检查与上一例子中的权限检查不同之处在于，第4层的方法doPrivileged()为特权方法，可以绕过权限检查，第5层的方法privilegedwrapper()调用了第4层的特权方法，也可以绕过权限检查。由于第5层的方法privilegedwrapper()属于云计算平台的公有方法，本身就具有读的权限，所以即使其绕过权限检查，并不影响对第6层的方法main()的检查。

以下例3为在云计算平台提供了特权方法doPrivileged()，并且该云计算场景中用户使用main()方法直接调用该特权方法doPrivileged()，打开文件名为filename操作的调用栈。

该调用栈与上一例子2中的调用栈不同之处在于，方法main()直接调用了特权方法doPrivileged()，即第5层方法main()调用第4层方法doPrivileged()。在权限检查时，由于第4层的方法doPrivileged()为特权方法可以绕过权限检查，第5层的方法main()调用了特权方法也可以绕过权限检查。如此，第0层和第1层的方法为Java沙箱的方法，具有读的权限，第2层的方法为Java系统方法，也具有读的权限，第3层的方法为公有方法，也具有读的权限，第4层和第5层绕过了权限检查，即使在策略文件不允许读的情况下，该权限检查始终是都是通过的， 从而安全管理器得出待检查代码是安全的。这样，对于用户方法main即使不具有读的权限，也可以打开云计算平台中文件名为filename的文件。

S110：判断所述代码的调用栈中是否存在绕过所述权限检查的方法；若存在绕过所述权限检查的方法，则执行S120。

安全管理器判断所述代码的调用栈中是否存在绕过所述权限检查的方法。

如上述例子1中所示，由于调用栈中不存在绕过所述权限检查的方法，所以安全管理器可以根据该权限检查的结果判断待检查的代码是否安全，即如果权限检查通过，则安全管理器判断待检查的代码是安全的；如果权限检查不通过，则安全管理器判断待检查的代码存在安全问题。

如上述例子2中所示，由于调用栈中存在绕过所述权限检查的方法(doPrivileged()和privilegedwrapper())，所以执行S120步骤。

如上述例子3中所示，由于调用栈中存在绕过所述权限检查的方法(doPrivileged()和main())，所以执行S120步骤。

S120：判断所述调用栈中方法是否存在签名；若不存在签名，则执行S130步骤。

沿用例子2，第6层没有签名，第5层的签名为“alibaba”，第4层没有签名，第3层没有签名，第2层没有签名，第1层没有签名，第0层没有签名。由于所述调用栈中第5层的方法存在签名“alibaba”，所以安全管理器判断所述待检查的代码通过权限检查，即待检查的代码是安全的。

沿用例子3，第5层没有签名，第4层没有签名，第3层没有签名，第2层没有签名，第1层没有签名，第0层没有签名。安全管理器判断所述调用栈中方法是否存在签名时，由于所述调用栈中不存在签名，所以执行S130步骤。

S130：判定所述待检查代码存在安全问题。

安全管理器判断所述待检查代码存在安全问题，将抛出安全异常，终止待检查代码的调用，在例子3中，则用户无法打开云计算平台中文件名为filename的文件。

本实施例中，通过对存在绕过权限检查的方法所在调用栈中签名进行检查，若所述调用栈中方法不存在签名，则判定待检查代码存在安全问题。如此，就可以避免调用特权方法绕过权限检查，从而提高了Java沙箱的安全性。

在例子3中，如果第3层的方法readwrapper()也具有签名(在实际应用中云计算平台提供的公有方法可能存在签名)，那么安全管理器可以得出所述待检查的代码通过权限检查，即待检查的代码是安全的。然而例子3中存在第5层的用户方法main()直接调用第4层的特权方法doPrivileged()，得出待检查的代码是安全的这显然是不合理的。

为了解决以上调用栈中公有方法存在签名时，Java沙箱不能检查出用户方法直接调用特权方法的问题，如图2所示，在判断所述调用栈中方法是否存在签名之后，本方法还可以包括如下步骤：

S121：若存在签名，则判断所述签名对应的方法的深度是否大于特权方法的深度；若不大于特权方法的深度，则执行S130。

本实施例中，所述深度为方法在调用栈中的层数，例如一方法位于调用栈中的第3层，则该方法的深度即为3。

在上述例子2中的基础上，如果第3层的方法readwrapper()也具有签名“alibaba”，则调用栈为：

该调用栈中，签名对应的方法readwrapper()的深度为3；签名对应的方法 privilegedwrapper()的深度为5，而特权方法doPrivileged()的深度为4。很明显的方法privilegedwrapper()的深度大于特权方法doPrivileged()的深度，所以安全管理器判定所述待检查的代码通过权限检查，即待检查的代码是安全的。

在上述例子3中的基础上，如果第3层的方法readwrapper()也具有签名“alibaba”，则调用栈为：

该调用栈中，签名对应的方法readwrapper()的深度为3；而特权方法doPrivileged()的深度为4。很明显的方法privilegedwrapper()的深度小于特权方法doPrivileged()的深度，所以安全管理器执行S130步骤，即判定所述待检查代码存在安全问题。

在本申请的一个具体的实施例中，如图3所示，在判断所述调用栈中方法是否存在签名之后，所述方法还可以包括如下步骤：

S122：若存在签名，从策略文件中获取预设签名；

S123：判断所述调用栈中方法的签名是否符合所述预设签名；若不符合所述预设签名，则执行S130步骤。

在实际的应用中，云计算平台一般只接受其平台提供的签名，而不接受别的平台提供的签名。或者所述云计算平台只接受其平台允许的签名，而不接受其它的签名。

本实施例中，所述预设签名可以是人为预先在策略文件中配置的。假设例 子2所示的调用栈中第5层的方法privilegedwrapper()的签名为“AAA”，而所述预设签名为“alibaba”。那么，由于所述签名“AAA”不符合预设签名“alibaba”，则执行S130步骤，即判定所述待检查代码存在安全问题。

在本申请的一个具体的实施例中，如图4所示，在判断所述调用栈中方法是否存在签名之后，所述方法还可以包括如下步骤：

S124：若存在签名，获取所述调用栈中方法的类名；

S125：从策略文件中获取预设类名；

S126：判断所述调用栈中方法的类名是否符合所述预设类名；若不符合所述预设类名，则执行S130步骤。

在实际的应用中，与上一实施例类似，云计算平台一般只接受其平台允许的类名，而不接受所述允许的类名以外的其它类名。

本实施例中，所述预设类名可以是人为预先在策略文件中配置的。

例如调用栈中方法的类名为：第0层的类名为classA，第1层的类名为classB，第2层的类名为classC；如果从策略文件中获取的预设类名为classA，classB，classC，classD，则所述调用栈中方法的类名均符合所述预设类名，所以安全管理器可以判定所述待检查代码是安全的。如果从策略文件中获取的预设类名为classA，classC，classD，则所述调用栈中方法的类名classB不符合所述预设类名，所以执行S130步骤，即判定所述待检查代码存在安全问题。

在本申请的一个具体的实施例中，如图5所示，在判断所述调用栈中方法是否存在签名之后，所述方法还可以包括如下步骤：

S127：若存在签名，从策略文件中获取预设调用顺序；

S128：判断所述调用栈中方法的调用顺序是否符合所述预设调用顺序；若不符合所述预设调用顺序，则执行S130步骤。

本实施例中，所述预设调用顺序可以是人为预先在策略文件中配置的。

例如待检查代码的调用栈中方法的调用顺序为：A调用B，再调用C；而从策略文件中获取的预设调用顺序为：A调用D，再调用C。那么，由于所述 调用栈中方法的调用顺序不符合所述预设调用顺序，服务器执行S130步骤，即判定所述待检查代码存在安全问题。

本申请实施例提供还提供一种装置，可以实现上述的方法步骤，且该装置可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为逻辑意义上的装置，是通过服务器的CPU(Central Process Unit，中央处理器)将对应的计算机程序指令读取到内存中运行形成的。

图6为本申请一实施例中提供的用于提高Java沙箱安全性的装置的模块示意图。本实施例中，所述装置包括：

检查模块200，用于对待检查代码进行权限检查；

第一判断模块210，用于判断所述代码的调用栈中是否存在绕过所述权限检查的方法；

第二判断模块220，用于在所述代码的调用栈中存在绕过所述权限检查的方法时，判断所述调用栈中方法是否存在签名；

确定模块230，用于在所述调用栈中方法不存在签名时，判定所述待检查代码存在安全问题。

优选地，在所述第二判断模块220之后，还可以包括：

第一判断子模块，用于在所述调用栈中方法存在签名时，判断所述签名对应的方法的深度是否大于特权方法的深度；

相应地，所述确定模块230，还用于在所述签名对应的方法的深度不大于特权方法的深度时，判定所述待检查代码存在安全问题。

优选地，在所述第二判断模块220之后，还可以包括：

第一获取子模块，用于在所述调用栈中方法存在签名时，从策略文件中获取预设签名；

第二判断子模块，用于判断所述调用栈中方法的签名是否符合所述预设签名；

相应地，所述确定模块230，还用于在所述调用栈中方法的签名不符合所 述预设签名时，判定所述待检查代码存在安全问题。

优选地，在所述第二判断模块220之后，还可以包括：

第二获取子模块，用于在所述调用栈中方法存在签名时，获取所述调用栈中方法的类名；

第三获取子模块，用于从策略文件中获取预设类名；

第三判断子模块，用于判断所述调用栈中方法的类名是否符合所述预设类名；

相应地，所述确定模块230，还用于在所述调用栈中方法的类名不符合所述预设类名时，判定所述待检查代码存在安全问题。

优选地，在所述第二判断模块220之后，还可以包括：

第四获取子模块，用于在所述调用栈中方法存在签名时，从策略文件中获取预设调用顺序；

第四判断子模块，用于判断所述调用栈中方法的调用顺序是否符合所述预设调用顺序；

相应地，所述确定模块230，还用于在所述调用栈中方法的调用顺序不符合所述预设调用顺序时，判定所述待检查代码存在安全问题。

本申请实施例所提供的提高Java沙箱安全性的方法通过对待检查代码进行权限检查；判断所述代码的调用栈中是否存在绕过所述权限检查的方法若是，则判断所述调用栈中方法是否存在签名；在所述调用栈中方法不存在签名时，判定所述待检查代码存在安全问题，从而实现提高Java沙箱安全性的目的。本实施例

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的 改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形 式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算 机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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