针对应用程序接口的安全漏洞确定方法和装置与流程

本公开涉及网络安全技术领域，特别是涉及一种针对应用程序接口api的安全漏洞确定方法和装置。

背景技术：

应用程序接口(applicationprogramminginterface，简称api)作为软件系统的组成部分被广泛应用。近年来随着移动互联网技术的发展，前端设备(如手机、平板、桌面电脑等)层出不穷，为了方便后端服务器能够与不同的前端设备通信，提出了restful(representationalstatetransferful)。restful作为一种软件架构风格，既适于客户端应用又适于服务端的应用，能够通过一套统一的api接口为web、ios和android等客户端提供服务。

基于rest(representationalstatetransfer)构建的api就是restful风格api。restful风格给api接口带来的好处是，只要写一次接口就可以供多种前端设备例如web、ios和android等同时使用。这样可以使开发更加快捷，最主要的是使分工更明确。例如一个人专门写接口，其他人只需要知道如何调用就可以了，完全不需要知道是如何实现的。

虽然restful风格的api通用性与兼容性比较好，但是一旦存在安全漏洞，将给后端服务器带来安全隐患。

针对restful风格的api，相关技术提供了一种安全漏洞扫描方法，即通过网络监控复制正常交易数据报文进行安全漏洞扫描，这种方法由于无法监控到所有类型的报文而导致扫描覆盖率低。

技术实现要素：

本公开的一个方面提供了一种针对应用程序接口api的安全漏洞确定方法，包括：获取多个测试案例和至少一个攻击脚本；针对所述多个测试案例中的每个测试案例，确定对应的测试数据；以及执行所述每个测试案例，以便确定所述api是否存在安全漏洞；其中，所述执行所述每个测试案例包括：调用所述api并生成针对所述测试数据的数据报文，所述数据报文包含多个字段；利用所述至少一个攻击脚本中的任意一个脚本替换所述多个字段的任意一个字段或者指定字段，得到替换后的数据报文；发送所述替换后的数据报文到服务器；以及针对所述服务器对所述替换后的数据报文的响应，确定所述api是否存在安全漏洞。

可选地，所述针对所述多个测试案例中的每个测试案例，确定对应的测试数据，包括：根据针对所述每个测试案例的前置条件，生成所述对应的测试数据；以及所述方法还包括：在所述每个测试案例执行完成后，根据针对所述每个测试案例的后置条件，将所述对应的测试数据恢复成原始数据。

可选地，所述方法还包括：如果确定所述api存在安全漏洞，则记录日志。

可选地，所述方法还包括在所述获取多个测试案例之前：创建扫描任务，其中，响应于所述扫描任务被触发，获取所述多个测试案例并针对所述api进行安全漏洞扫描。

可选地，所述方法还包括：确定是否有新增测试案例；以及如果确定有所述新增测试案例，则执行所述新增测试案例并针对所述api确定安全漏洞。

可选地，所述api包括restful软件架构风格的api。

本公开的另一个方面提供了一种针对应用程序接口api的安全漏洞确定装置，包括：获取模块，用于获取多个测试案例和至少一个攻击脚本；确定模块，用于针对所述多个测试案例中的每个测试案例，确定对应的测试数据；以及执行模块，用于执行所述每个测试案例，以便确定所述api是否存在安全漏洞；其中，所述执行模块包括：生成单元，用于调用所述api并生成针对所述测试数据的数据报文，所述数据报文包含多个字段；替换单元，用于利用所述至少一个攻击脚本中的任意一个脚本替换所述多个字段的任意一个字段或者指定字段，得到替换后的数据报文；发送单元，用于发送所述替换后的数据报文到服务器；以及确定单元，用于针对所述服务器对所述替换后的数据报文的响应，确定所述api是否存在安全漏洞。

可选地，所述确定模块，还根据针对所述每个测试案例的前置条件，生成所述对应的测试数据；以及所述装置还包括：恢复模块，用于在所述每个测试案例执行完成后，根据针对所述每个测试案例的后置条件，将所述对应的测试数据恢复成原始数据。

本公开的另一方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了根据本公开实施例的适于针对应用程序接口的安全漏洞确定方法和装置的系统架构；

图2示意性示出了根据本公开实施例的针对应用程序接口的安全漏洞确定方法的流程图；

图3示意性示出了根据本公开实施例的执行测试案例的流程图；

图4示意性示出了根据本公开另一实施例的针对应用程序接口api的安全漏洞确定方法的流程图；

图5示意性示出了根据本公开又一实施例的针对应用程序接口api的安全漏洞确定方法的流程图；

图6示意性示出了根据本公开实施例的逐案例执行扫描任务的流程图；

图7示意性示出了根据本公开实施例的针对应用程序接口的安全漏洞确定装置的框图；

图8示意性示出了根据本公开另一实施例的针对应用程序接口的安全漏洞确定装置的框图；以及

图9示意性示出了根据本公开实施例的电子设备的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。

本公开的实施例提供了一种针对应用程序接口api的安全漏洞确定方法以及能够应用该方法的针对应用程序接口api的安全漏洞确定装置。该方法包括获取多个测试案例和至少一个攻击脚本。针对多个测试案例中的每个测试案例，确定对应的测试数据。执行每个测试案例，以便确定api是否存在安全漏洞。其中，执行每个测试案例包括调用api并生成针对测试数据的数据报文，数据报文包含多个字段。利用至少一个攻击脚本中的任意一个脚本替换多个字段的任意一个字段或者指定字段，得到替换后的数据报文。发送替换后的数据报文到服务器。针对服务器对替换后的数据报文的响应，确定api是否存在安全漏洞。

图1示意性示出了根据本公开实施例的适于针对应用程序接口api的安全漏洞确定方法和装置的系统架构。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，该系统架构100可以包括：前端设备(如客户端101、客户端102、客户端103)，后端设备(如服务器104)。其中，前端设备可以是web、ios和android等客户端。并且，前端设备和后端设备均可以使用restful风格的api交互。

应该理解，如果前端设备的api接口设计的合理，那么针对前端设备发送的api数据报文，后端设备理论上应该能够按照预期正常响应。如果前端设备的api接口设计的不合理，那么针对前端设备发送的api数据报文，后端设备理论上是不应该按照预期正常响应的。

基于上述原理，本公开实施例构思在于，针对前端设备生成的api数据报文，每次使用一个攻击脚本先替换其中的一个字段后再发送给后端设备。对此，如果后端设备依旧能够按照预期进行响应，则表明当前的api存在安全漏洞。更具体地，这表明api数据报文本次被替换的字段存在安全漏洞。相反，对于替换后的api数据报文，如果后端设备无法按照预期响应，则表明当前的api并不存在安全漏洞。

可见，基于上述逻辑，可以扫描api数据报文的所有字段，以确定api是否存在安全漏洞。以下参考附图并结合具体实施例详细阐述本公开。

图2示意性示出了根据本公开实施例的针对应用程序接口api的安全漏洞确定方法的流程图。

如图2所示，该方法包括以下操作s210～s230。

在操作s210，获取多个测试案例和至少一个攻击脚本。

具体地，在本公开实施例中，可以通过测试案例获取模块从测试案例库中读取多个能够模拟多种应用场景的api测试案例。例如，响应于restful风格的api安全漏洞扫描启动，可以通过测试案例获取模块将现有工程中维护的全量测试案例任务放入任务列表1，并且可以通过任务控制模块根据任务列表1进行遍历控制，以基于每个测试用例对restful风格的api进行安全漏洞扫描。

以黑盒测试案例为例，测试案例获取模块例如可以载入api接口调用信息配置文件、接口数据包文件、前置脚本和后置脚本。其中，执行前置脚本能够生成测试数据，执行后置脚本能够恢复测试数据。

具体地，在本公开实施例中，还可以通过攻击脚本获取模块从攻击脚本库中获取一个或者多个攻击脚本。优选地，可以通过获取多个攻击脚本。

接下来，在操作s220，针对多个测试案例中的每个测试案例，确定对应的测试数据。

在本公开实施例中，为了提高扫描覆盖率，这多个测试用例可以是适于不同应用场景的测试用例。例如，对于余额查询，有时需要查询国内账户的余额，有时需要查询国外账户的余额，此种情况下获取的测试用例即需要包括国内余额查询测试案例和国外余额查询测试案例。

不同的测试用例需要不同的测试数据。例如，对于余额查询测试案例，测试数据可以包括但不限于账号、密码和余额。例如，对于转账测试案例，测试数据可以包括但不限于资金流出账号及其密码和余额，以及资金流入账号。

然后，在操作s230，执行每个测试案例，以便确定api是否存在安全漏洞。

应该理解，在本公开实施例中，既可以扫描api数据报文中的所有字段来确定api在哪些字段处是否存在安全漏洞，也可以仅仅扫描api数据报文中的某些关键字段来确定api在这些关键字段处是否存在安全漏洞。

例如，对于一个账户而言，“附言”、“开户行”、“地区号”等字段以及其他技术性字段一般不太会被恶意攻击，对安全性影响不大。因此在扫描安全漏洞时，可以将api数据报文的这些字段排除在关键字段之外。

图3示意性示出了根据本公开实施例的执行测试案例的流程图。

其中，如图3所示，根据本公开实施例，操作s230可以进一步包括操作s231～s234。

首先，在操作s231，调用api并生成针对测试数据的数据报文，数据报文包含多个字段。

应该理解，在本公开实施例中，该api例如可以包括restful软件架构风格的api(以下简称restful风格的api)。

并且，在本公开实施例中，可以通过案例内容解析模块读取restful风格的api调用参数，然后根据调用参数调用api。

restful风格的api调用参数具体可以包括但不限于调用方id、对外服务网关地址、网关公钥、版本号、签名算法、调用方签名使用的私钥、请求实现类、响应实现类、请求实现路径等。

此外，在本公开实施例中，还可以通过案例内容解析模块读取对应测试案例的前置脚本，然后通过执行对应测试案例的前置脚本来生成测试数据，进而根据测试数据生成api数据报文。

接下来，在操作s232，利用至少一个攻击脚本中的任意一个脚本替换多个字段的任意一个字段或者指定字段，得到替换后的数据报文。

在本公开实施例中，无论是对字段进行全量扫描还是只对部分关键字段进行扫描，每次可以只替换api数据报文中的一个字段。如此，如果存在安全漏洞，则可以确定具体是api数据报文中的哪个/哪些字段存在安全漏洞。

并且，为了避免偶然事件的影响，针对api数据报文中的每个字段进行安全漏洞扫描时，可以使用现有工程中维护的所有攻击脚本中的每个脚本各替换一次。

具体地，可以通过任务控制模块控制测试数据修改模块，使得测试数据修改模块能够根据测试案例执行流程，将相应的字段替换为相应的攻击脚本。

应该理解，在本公开实施例中，任务控制模块可以用于控制测试案例执行流程和扫描任务执行流程。具体地，任务控制模块先控制进入一个字段的扫描任务执行流程，即固定某一字段，并针对该固定字段遍历攻击脚本库中的每个攻击脚本，使之逐个替换该固定字段的内容，直到攻击脚本库遍历结束，该固定字段的扫描任务执行完成。接着任务控制模块控制进入下一个字段的扫描任务执行流程。直到一个api数据报文中的全部字段遍历完成后，一个测试案例的执行流程执行完成。接着任务控制模块控制进入下一个测试案例的执行流程。

然后，在操作s233，发送替换后的数据报文到服务器。

具体地，在本公开实施例中，通信模块可以根据api配置信息将对应的攻击脚本和对应的测试数据组装成数据包并向api对外服务网关发送报文并接收服务器对此返回报文。应该理解，在本公开实施例中，api对外服务网关例如可以用于接收通信模块发送的报文并将其转发给服务器。此外，api对外服务网关例如还可以用于接收服务器返回的报文并将其转发给通信模块。

再然后，在操作s234，针对服务器对替换后的数据报文的响应，确定api是否存在安全漏洞。

针对前端设备发送的经攻击脚本替换后的api数据报文，如果后端设备如服务器依旧能够按照预期响应，则表明当前的api存在安全漏洞。更具体地，这表明api数据报文中本次被替换的字段存在安全漏洞。相反，对于经攻击脚本替换后的api数据报文，如果后端设备如服务器无法按照预期响应，则表明当前的api并不存在安全漏洞。

具体地，在本公开实施例中，通信结果比对模块可以用于检查接口返回码并将接口返回码与正常状态码进行比对，以确定当前字段是否存在安全漏洞。其中，如果接口返回码与正常状态码一致，则表明当前字段存在安全漏洞。如果接口返回码与正常状态码不一致，则表明当前字段不存在安全漏洞。

与在生产场景下进行api安全漏洞扫描不同，本公开实施例提供了一种在测试场景下进行api安全漏洞扫描的方案。由于多个测试案例尤其是对一个比较完整的测试案例库中的多个测试案例而言，一般会涉及多种测试场景。因此本公开实施例提供的技术方案能够监控到更多类型甚至是所有类型的api数据报文，例如本公开实施例可以根据现有工程项目中的测试案例库和攻击脚本库，实现逐接口字段、全攻击脚本库的安全漏洞扫描，从而能够提高api接口分支的扫描覆盖率。

图4示意性示出了根据本公开另一实施例的针对应用程序接口api的安全漏洞确定方法的流程图。

作为一种可选的实施例，如图4所示，该方法除了包括如图2所示的操作s210和s230之外，例如还可以包括操作s410～s420。

其中，在本公开实施例中，操作s310是操作s220的一种实现方式。

在操作s410，根据针对每个测试案例的前置条件，生成对应的测试数据。

应该理解，在本公开实施例中，各测试案例的前置条件包括对应测试案例的前置脚本。其中，执行一个测试案例的前置脚本，可以生成该测试案例的测试数据。

例如，如果需要查询一个账户的余额，则通过执行预先设定的账户余额查询测试案例的前置脚本，可以生成该账户以及密码和余额等测试数据。

再例如，如果使用一张无效的数字证书例如到期日(如2018年12月31日)已过的数字证书监控到期日，则先需要修改该数字证书为有效状态，例如修改该数字证书的到期日为2021年12月31日，再进行到期日监控。这种情况下，可以通过执行预先设定的数字证书到期日测试案例的前置脚本，生成该数字证书的新的有效的到期日作为测试数据。

接下来，在操作s420，在每个测试案例执行完成后(即在执行操作s230之后)，根据针对每个测试案例的后置条件，将对应的测试数据恢复成原始数据。

由于在测试数据准备阶段，即执行相关测试案例的前置脚本时，很可能会修改测试案例的测试数，例如修改一张数字证书的有效期等。而测试数据被修改之后很可能会影响测试案例在执行测试任务阶段的准确性。因此在本公开实施例中，还会执行操作s320，从而在每次攻击前执行前置脚本进行测试数据准备，每次攻击后执行后置脚本进行数据恢复，以免影响测试案例在测试任务阶段的测试操作。

具体地，在本公开实施例中，测试数据修改模块可以根据案例执行流程，从案例内容解析模块获取并执行测试案例的前置脚本和后置脚本。

作为一种可选的实施例，该方法例如还可以包括：如果确定api存在安全漏洞，则记录日志。

具体地，在本公开实施例中，通信结果比对模块每做一次比对操作都可以将比对结果以及api报文内容、返回码传递给日志记录模块。日志记录模块负责记录日志并调用任务控制模块判断下一步流程。进一步，在本公开实施例中，还可以通过报表模块，根据日志记录模块记录的日志明细，进行分析汇总并导出报表。如此，可以将一个api各字段的安全状态报告给编程人员，使编程人员能够及时了解并修改该api的存在安全漏洞的字段。

作为一种可选的实施例，该方法例如还可以包括在获取多个测试案例之前：创建扫描任务，其中，响应于扫描任务被触发，获取多个测试案例并针对api进行安全漏洞扫描。

由于测试案例主要是用于实现测试任务的，而在本公开实施例中，使用测试案例主要是实现api安全漏洞扫描的。为了避免同一个测试案例在同一个时间段内既出现在测试任务中又出现在扫描任务中而导致两个任务互相影响，甚至出现冲突，本公开实施例做了进一步改进。即通过创建并触发一个扫描任务来确定使用某些测试案例扫描某些api的安全漏洞的时机，使得同一个测试案例的测试任务和扫描任务可以完美避开，以免冲突。

图5示意性示出了根据本公开又一实施例的针对应用程序接口api的安全漏洞确定方法的流程图。

作为一种可选的实施例，如图5所示，该方法除了包括如图2所示的操作s210～s230之外，例如还可以包括操作s510～s520。

在操作s510，确定是否有新增测试案例。

在操作s520，如果确定有新增测试案例，则执行新增测试案例并针对api确定安全漏洞。

在本公开实施例中，使用新增的测试案例对api进行安全漏洞扫描的相关操作与使用已有的测试案例对api进行安全漏洞扫描的相关操作相同，在此不再赘述。

通过本公开实施例，在使用全量测试案例以api接口字段为维度进行api全字段安全漏洞扫描的基础上，继续使用增量测试案例对api进行全字段安全漏洞扫描，可以进一步提高测试分支覆盖率。

图6示意性示出了根据本公开实施例的逐案例执行扫描任务的流程图。

以下参考图6并结合具体实施例详细阐述扫描任务以现有工程中维护的测试案例库为基础进行逐案例扫描的实施例方式。如图6所示，该实施例方式包括操作s610～s690。

在操作s610，restful风格api安全漏洞扫描启动，测试案例获取模块将现有工程中维护的全量测试案例任务放入任务列表1。

在操作s620，任务控制模块根据任务列表1进行遍历控制。

在操作s630，案例内容解析模块读取案例文件，获取restful风格api调用参数、测试案例的前置脚本、restful风格api报文字段和对应值、测试案例的后置脚本。接口调用具体参数包括但不限于调用方id、对外服务网关地址、网关公钥、版本号、签名算法、调用方签名使用的私钥、请求实现类、响应实现类、restful风格api请求实现路径。

在操作s640，案例内容解析模块创建任务列表2，将案例内接口字段放入任务列表2。

在操作s650，任务控制模块根据任务列表2进行遍历控制。

在操作s660，执行该任务的测试案例。

在操作s670，任务控制模块判断任务列表2是否执行完毕。如果执行完毕，则执行操作s680。如果没有执行完毕，则执行操作s650。

在操作s680，任务控制模块判断任务列表1是否执行完毕，如果执行完毕，则执行操作s690。如果没有执行完毕，则执行操作s630。

在操作s690，报表模块根据日志明细生成报表。

图7示意性示出了根据本公开实施例的针对应用程序接口api的安全漏洞确定装置的框图。

如图7所示，针对应用程序接口api的安全漏洞确定装置700包括获取模块701、确定模块702、执行模块703。该处理装置可以执行上面参考方法实施例部分描述的方法，在此不再赘述。

具体地，获取模块701用于获取多个测试案例和至少一个攻击脚本。

确定模块702用于针对多个测试案例中的每个测试案例，确定对应的测试数据。

执行模块703用于执行每个测试案例，以便确定api是否存在安全漏洞。

其中，该执行模块703包括：生成单元7031、替换单元7032、发送单元7033和确定单元7034。

具体地，生成单元7031用于调用api并生成针对测试数据的数据报文，数据报文包含多个字段。

替换单元7032用于利用至少一个攻击脚本中的任意一个脚本替换多个字段的任意一个字段或者指定字段，得到替换后的数据报文。

发送单元7033用于发送替换后的数据报文到服务器。

确定单元7034用于针对服务器对替换后的数据报文的响应，确定api是否存在安全漏洞。

与在生产场景下进行api安全漏洞扫描不同，本公开实施例提供了一种在测试场景下进行api安全漏洞扫描的方案。由于多个测试案例尤其是对一个比较完整的测试案例库中的多个测试案例而言，一般会涉及多种测试场景。因此本公开实施例提供的技术方案能够监控到更多类型甚至是所有类型的api数据报文，例如本公开实施例可以根据现有工程项目中的测试案例库和攻击脚本库，实现逐接口字段、全攻击脚本库的安全漏洞扫描，从而能够提高api接口分支的扫描覆盖率。

图8示意性示出了根据本公开另一实施例的针对应用程序接口api的安全漏洞确定装置的框图。

作为一种可选的实施例，如图8所示，该装置除了包括如图5所示的模块和单元之外，例如还可以包括：恢复模块801。

具体地，在本公开实施例中，确定模块702用于根据针对每个测试案例的前置条件，生成对应的测试数据。

恢复模块801用于在每个测试案例执行完成后，根据针对每个测试案例的后置条件，将对应的测试数据恢复成原始数据。

需要说明的是，装置部分的实施例方式与方法部分的实施例方式对应类似，并且所达到的技术效果也对应类似，在此不再赘述。

根据本公开的实施例的模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，获取模块701、确定模块702、执行模块703中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，获取模块701、确定模块702、执行模块703中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，获取模块701、确定模块702、执行模块703中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图9示意性示出了根据本公开实施例的电子设备的框图。图9示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，电子设备900包括处理器910、计算机可读存储介质920。该电子设备900可以执行根据本公开实施例的方法。

具体地，处理器910例如可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器910还可以包括用于缓存用途的板载存储器。处理器910可以是用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

计算机可读存储介质920，例如可以是非易失性的计算机可读存储介质，具体示例包括但不限于：磁存储装置，如磁带或硬盘(hdd)；光存储装置，如光盘(cd-rom)；存储器，如随机存取存储器(ram)或闪存；等等。

计算机可读存储介质920可以包括计算机程序921，该计算机程序921可以包括代码/计算机可执行指令，其在由处理器910执行时使得处理器910执行根据本公开实施例的方法或其任何变形。

计算机程序921可被配置为具有例如包括计算机程序模块的计算机程序代码。例如，在示例实施例中，计算机程序921中的代码可以包括一个或多个程序模块，例如包括921a、模块921b、……。应当注意，模块的划分方式和个数并不是固定的，本领域技术人员可以根据实际情况使用合适的程序模块或程序模块组合，当这些程序模块组合被处理器910执行时，使得处理器910可以执行根据本公开实施例的方法或其任何变形。

根据本公开的实施例，获取模块701、确定模块702、执行模块703中的至少一个可以实现为参考图9描述的计算机程序模块，其在被处理器910执行时，可以实现上面描述的相应操作。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。