识别程序漏洞的方法、装置、存储介质和电子设备与流程

本发明涉及计算机技术领域，特别涉及一种识别程序漏洞的方法和装置、计算机可读存储介质以及电子设备。

背景技术：

随着互联网技术特别是移动网络的飞速发展，越来越多的软件服务提供方采用服务器配合客户端的形式来提供服务。以社交软件为例，用户与客户端程序交互中产生的一些重要数据(例如鉴权、支付等信息)，都需要发送给服务器端进行后续处理。又以游戏软件为例，用户在客户端程序的一些关键操作(例如登陆、内购等)，都由服务器端进行相应处理后反馈给客户端。

客户端服务器(cs，client-server)架构的程序在出现漏洞时，由于会影响到服务器的安全，乃至会影响所有用户的信息安全和使用体验，因此其与仅在单机运行的程序相比，程序漏洞的识别显得尤为重要。

目前对于cs架构程序的漏洞测试，完全依赖人工分析风险，通过手动构造测试数据由客户端发送至服务器端，进而基于观察客户端和服务器的表现，来判断是否存在相应的漏洞。这种漏洞识别手段的成功率，完全依赖于测试人员的技能和经验，因此可靠性难以保证，漏洞挖掘的效率、广度和深度都比较低。

技术实现要素：

为了解决相关技术中完全依赖测试人员手动操作识别程序漏洞的问题，本发明提供了一种识别程序漏洞的方法和装置、计算机可读存储介质以及电子设备。

根据本发明的实施例，提供一种识别程序漏洞的方法，用于对基于客户端和服务器架构的程序进行漏洞检测，所述方法包括：根据所述客户端发送的上行数据和所述服务器发送的下行数据，确定存在对应关系并符合测试对象条件的上行协议和下行协议；将与所述上行协议关联的测试数据传送至所述客户端执行；以及基于来自所述服务器的与所述下行协议关联的返回数据确定是否存在漏洞。

根据本发明的实施例，提供一种识别程序漏洞的装置，用于对基于客户端和服务器架构的程序进行漏洞检测，包括：绑定模块，用于根据所述客户端发送的上行数据和所述服务器发送的下行数据，确定存在对应关系并符合测试对象条件的上行协议和下行协议；测试模块，用于将与所述上行协议关联的测试数据传送至所述客户端执行；以及确定模块，用于基于来自所述服务器的与所述下行协议关联的返回数据确定是否存在漏洞。

根据本发明的实施例，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的识别程序漏洞的方法。

根据本发明的实施例，提供一种电子设备，包括：处理器；以及存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如上所述的识别程序漏洞的方法。

本发明的实施例提供的识别程序漏洞的方案，基于确定出存在对应关系的上行协议和下行协议，通过发送测试数据给客户端执行，并对服务器的响应进行分析，能够自动执行程序漏洞的检测识别，提高了测试效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并于说明书一起用于解释本发明的原理。

图1示出了可以应用本发明实施例识别程序漏洞的方法或装置的示例性系统架构的示意图。

图2示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

图3是根据一示例性实施例示出的一种识别程序漏洞的方法的流程图。

图4是根据另一示例性实施例示出的一种识别程序漏洞的方法的流程图。

图5是根据再一示例性实施例示出的一种识别程序漏洞的方法的流程图。

图6是根据一示例性实施例示出的一种识别程序漏洞的装置的框图。

图7是根据另一示例性实施例示出的一种识别程序漏洞的装置的框图。

图8示出了可以应用本发明实施例的识别程序漏洞的方法或装置的另一示例性系统架构的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1示出了可以应用本发明实施例的识别程序漏洞的方法或装置的示例性系统架构100的示意图。

如图1所示，系统架构100可以包括终端设备101、102、103中的一种或多种，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、便携式计算机和台式计算机等等。服务器105可以是提供各种服务的服务器。

例如，在终端设备103(也可以是终端设备101或102)和服务器105上分别安装基于本发明提供的安装包后，就可对终端设备103上安装的基于cs架构的程序进行漏洞检测。服务器105根据终端设备103上客户端发送的上行数据和服务器(与上述客户端对应的服务器，而非此处的服务器105，图中未示出)发送的下行数据，确定存在对应关系并符合测试对象条件的上行协议和下行协议；将与上行协议关联的测试数据传送至终端设备103上的客户端执行；最后基于来自上述服务器的与下行协议关联的返回数据确定是否存在漏洞。

在一些实施例中，本发明实施例所提供的识别程序漏洞的方法一般由服务器105执行，相应地，识别程序漏洞的装置一般设置于服务器105中。在另一些实施例中，某些终端可以具有与服务器相似的功能从而执行本方法。因此，本发明实施例所提供的识别程序漏洞的方法不限定在服务器端执行。

图2示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图2所示，计算机系统200包括中央处理单元(cpu)201，其可以根据存储在只读存储器(rom)202中的程序或者从存储部分208加载到随机访问存储器(ram)203中的程序而执行各种适当的动作和处理。在ram203中，还存储有系统操作所需的各种程序和数据。cpu201、rom202以及ram203通过总线204彼此相连。输入/输出(i/o)接口205也连接至总线204。

以下部件连接至i/o接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分207；包括硬盘等的存储部分208；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至i/o接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入存储部分208。

特别地，根据本发明的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被中央处理单元(cpu)201执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

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

描述于本发明实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图3至图6所示的各个步骤。

以下对本发明实施例的技术方案的原理和实现细节进行详细阐述。

图3是根据一示例性实施例示出的识别程序漏洞的方法的流程图。如图3所示，该方法用于对基于客户端和服务器架构的程序进行漏洞检测，可以由任意计算设备执行，可包括以下步骤310-330。

在步骤310中，根据客户端发送的上行数据和服务器发送的下行数据，确定存在对应关系并符合测试对象条件的上行协议和下行协议。

这里的客户端和服务器都与待测试的程序相关联。一般而言，客户端安装在终端设备上，通过网络与服务器进行数据交互。从客户端发送至服务器的数据可称为上行数据，从服务器发送至客户端的数据可称为下行数据。

这里的协议是指在客户端与服务器之间遵循一些约定规则的数据。以存在内购内容的游戏程序为例，用户在客户端发起购买操作，服务器对购买操作进行响应，相应会在客户端和服务器之间产生一些具有特定名称的交互数据。例如，从客户端向服务器发送的相应数据字段名中携带有buy(购买)字样，可被称为上行协议；而从服务器向客户端返回的相应数据字段名中携带有buy和rsp(response，响应)字样，可被称为下行协议。

本步骤涉及从客户端与服务器之间交互的数据中，确定出存在对应关系的上行协议和下行协议，后续再基于上行协议构造测试数据，根据服务器对测试数据和正常数据的反馈来确定程序是否存在漏洞。

在一个实施例中，可基于上行协议和下行协议的协议名称(也即对应数据字段的字段名称)或者时间戳，来确定存在对应关系的上行协议和下行协议，具体例如可参见图4实施例。

另外，对于存在对应关系的上行协议和下行协议，也不一定需要对所有协议进行测试。因此，本步骤还涉及从客户端与服务器之间交互的数据中，确定出符合测试对象条件的上行协议和下行协议。例如，对于游戏程序，可将协议是否涉及用户购买和支付等重要内容作为是否符合测试对象条件的确定依据。

在一个实施例中，也可基于上行协议和下行协议的协议名称(也即对应数据字段的字段名称)确定符合所述测试对象条件的上行协议和下行协议，具体例如可参见图4实施例。

在一个实施例中，本发明识别程序漏洞的方法，可由安装上述客户端的终端设备执行，例如也可表现为打包的测试程序。在另一个实施例中，本发明识别程序漏洞的方法，也可由与上述服务器相同不同的服务器来执行，例如也可实施为cs架构的测试程序，测试程序客户端与上述客户端可安装在同一终端设备上，用于从上述客户端获取其发送至服务器的上行数据及从服务器返回的下行数据，并发送至测试程序服务器进行分析。这里的测试程序服务器可独立于被测程序的服务器，从而避免对后者造成性能开销，也方便快速接入其他被测程序使用。

在步骤320中，将与上行协议关联的测试数据传送至客户端执行。

对于步骤310确定出的存在对应关系并符合测试对象条件的上行协议和下行协议，本步骤继续将与其中上行协议关联的测试数据传送至客户端执行。

如前文所述，本发明的实施例可根据服务器对测试数据和正常数据的反馈来确定程序是否存在漏洞。相应的，这里的测试数据一般是指异常数据，从而可用来测试服务器对其产生的反馈与对正常数据的反馈是否相同。

在一个实施例中，测试数据可从预先设置的数据库中获取。例如，对于事先被确定为测试对象的协议，可预先构造相应的测试数据并存储于数据库中。一旦从客户端与服务器交互的数据中识别出对应的协议，便可从数据库中提取相应的测试数据发送至客户端执行。例如，对于涉及用户购买和支付的协议，可预先设置金额异常(例如金额为零或负值)的测试数据；一旦从客户端与服务器交互的数据中识别出涉及用户购买和支付的协议，便可从数据库中提取上述金额异常的测试数据，并发送至客户端执行。

在另一个实施例中，也可直接基于预设规则来构造相应的测试数据。例如，对于步骤310确定出的特定上行协议，本步骤可接续基于预设规则来构造相应的测试数据。

以游戏程序的应用场景为例，可用来构造测试数据的策略例如可包括但不限于：零值盗刷、负值盗刷、数据截断、乘法溢出、加法溢出、协议重发、协议并发、常见值类型漏洞、id规则变化、枚举规则变化等等。测试数据的构造自身并非本发明关注的内容，在此不再赘述。

另外，这里所述将测试数据传送至客户端，具体的数据传送过程可以发生在不同的设备之间(例如从测试程序服务器传送至安装客户端的终端设备)，也可以发生在同一设备上不同的应用程序之间(例如从同一设备上安装的测试程序客户端传送至被测试的客户端)，本发明对此并无限制。

在步骤330中，基于来自服务器的与下行协议关联的返回数据确定是否存在漏洞。

如前文所述，本发明实施例所使用的测试数据一般是指异常数据，从而可用来测试服务器对其产生的反馈与对正常数据的反馈是否相同。

在一个实施例中，这里服务器对正常数据的反馈可来自步骤310的确定过程。例如，步骤310在确定存在对应关系并符合测试对象条件的上行协议和下行协议的同时，可记录服务器返回的下行协议数据的结构、字段、字段内容等信息，从而作为与测试数据响应的比较基准。

接续，在客户端执行测试数据后，基于对服务器返回的下行协议数据进行分析，如果服务器对前后两组数据(例如步骤310的上行协议数据和步骤320的测试数据)的响应相同，说明服务器无法识别出异常数据，因此确定程序存在漏洞，也即相应的协议存在漏洞；如果服务器的响应不同，则说明服务器可能对异常数据进行了区分处理，因此可确定程序不存在漏洞，也即相应的协议不存在漏洞。

在一个实施例中，本步骤基于来自服务器的与下行协议关联的返回数据确定是否存在漏洞，可包括以下判断方式的任意组合。

例如，可判断所述返回数据是否符合下行协议的数据结构，若不符合则可确定不存在漏洞，反之，若是则确定存在漏洞或可继续其他判断。

例如，还可判断所述返回数据是否包括错误码，若包括则确定不存在漏洞，反之，若不包括则确定存在漏洞或可继续其他判断。

例如，还可判断所述返回数据是否超过预设时间才收到，若是则确定不存在漏洞，反之，若否则确定存在漏洞或可继续其他判断。

例如，还可判断所述返回数据是否属于错误通知协议，若是则确定不存在漏洞，反之，若否则确定存在漏洞或可继续其他判断。

最后，在一个实施例中，步骤330的确定分析结果可存入测试数据库中，同时以预设的方式(例如网络页面形式的测试报告)展示给测试用户。

本发明的实施例提供的识别程序漏洞的方案，基于确定出存在对应关系的上行协议和下行协议，通过发送测试数据给客户端执行，并对服务器的响应进行分析，能够自动执行程序漏洞的检测识别，提高了测试效率。

图4是根据另一示例性实施例示出的一种识别程序漏洞的方法的流程图。如图4所示，该方法用于对基于客户端和服务器架构的程序进行漏洞检测，可以由任意计算设备执行，可包括以下步骤410-460。

在步骤410中，根据所述客户端发送的上行数据和所述服务器发送的下行数据，获取上行协议和下行协议的协议名称。

对于客户端与服务器交互的上行协议和下行协议，一般会在字段的特定位置(例如字段头)携带相应的协议名称，以便接收端识别出相应的协议，从而按照约定规则进行相应的处理和响应。在一个实施例中，步骤410可通过抓取上、下行数据中字段特定位置的内容来获取上行协议和下行协议的名称。

以游戏程序为例，通过步骤410例如可获取到涉及内购的上行协议名称buy_card_req(买卡请求)和下行协议名称buycardres(买卡响应)等等。

在步骤420中，对协议名称进行分词和过滤处理，得到协议名称的核心词。

协议名称通常包括多个关键词的组合，还可能包括一些表示协议性质(例如用来表示协议属于请求、响应、参数、通知)的词，步骤420涉及对协议名称进行分词和过滤处理，分词处理是为了得到拆分后的多个关键词，过滤处理是为了从关键词中过滤出对于识别协议对应关系和是否符合测试条件的核心词。换言之，这里的关键词是指对协议名称进行分词处理后得到的多个分词，而核心词则是指按照预设条件对多个分词进行过滤处理后得到的剩余关键词。

在一个实施例中，步骤420可根据但不限于非字母字符和字母大小写来进行分词。另外，分词后得到的关键词可统一转换为小写字母，便于后续进行匹配判断。例如，对于上述从游戏程序中获取到的上行协议名称buy_card_req，根据非字母字符“_”可分词得到buy、card和req三个关键词，而对于获取的下行协议名称buycardres，可根据字母大小写规则分词得到buy、card、res三个关键词。

接续，在一个实施例中，步骤420可根据预设的过滤规则对分词得到的关键词进行过滤。例如，过滤规则可以表现为过滤词汇表的形式，其中包括多个预设的单词，一旦分词后得到的关键词落入该过滤词汇表的范围时，则可将其过滤掉。

示例性而非限制性的，过滤词汇表中的单词例如包括：req(请求),res(响应),resp(响应),rsp(响应),para(参数),cmd(命令),sync(同步),ntf(通知),notify(通知),ack(确认),msg(消息),info(信息),cfg(配置)，括号中为单词对应的中文含义。仍以上述游戏程序的应用场景为例，按以上过滤词汇表对分词后得到的关键词进行过滤后，上行协议名称buy_card_req和下行协议名称buycardres二者对应可得到的核心词均为buy和card。

在步骤430中，基于核心词确定存在对应关系并符合测试对象条件的上行协议和下行协议。

本步骤实际涉及确定上下行协议的对应关系和测试对象条件两个部分，二者之间可以同时进行，也可以任意顺序进行，本发明的实施例对此并无限制。为描述清楚起见，以下将步骤430分为两部分进行描述。

步骤430的第一部分涉及确定上下行协议的对应关系。

在一个实施例中，可基于核心词的准确匹配、相似度匹配和加权后匹配等多种方式择一或组合来确定存在对应关系的上下行协议。

准确匹配

存在对应关系的上下行协议一般有相近的命名规范，基于步骤420得到的核心词，可基于核心词是否完全相同来确认存在对应关系的上下行协议。

以步骤420中所述的游戏程序应用场景为例，由于上行协议名称buy_card_req和下行协议名称buycardres二者对应得到的核心词均为buy和card，也即核心词完全相同，因此可确定二者为存在对应关系的上下行协议。

相似度匹配

上下行协议名称也存在不完全匹配的情况，但可能存在大部分核心词的相同。在一个实施例中，可通过核心词的命中率进行相似度匹配。

例如，对于步骤420得到的核心词，当上行协议和下行协议的核心词中相同部分超过预设命中率(例如50％)时，则可确定二者存在对应关系。

在一个实施例中，相似度匹配可以独立进行，也可以是在准确匹配失败时才进行。

加权后匹配

还有一些上行协议和对应的下行协议之间使用的相同核心词较少，例如下行协议是按照基于上行协议进行的相应操作来进行命名。对于这种情况，在一个实施例中，可对核心词中出现的一些操作名进行加权处理。

以游戏程序的应用场景为例，上行协议例如可包括购买物品道具的协议(例如为buyheroskinreq，表示购买英雄皮肤的请求)，对应的下行协议可能按照添加物品道具的操作来进行命名(例如为addskin，表示添加皮肤)。在对二者进行分词和过滤后，可得到上行协议核心词为buy,hero和skin，下行协议核心词为add和skin。

如果按照前述的相似度匹配结果，可得到核心词的命中率为33％，未超过预设命中率(50％)。但如果预先设置了对于添加操作的名称(add)进行加权(例如加权系数为2倍)，这里由于下行协议核心词中包括add，所以加权后的匹配度为66％，超过了预设命中率(50％)，因此可确定上行协议buyheroskinreq和下行协议addskin之间存在对应关系。

在一个实施例中，加权后匹配可以独立进行，也可以是在准确匹配和相似度匹配失败时才进行。

在本实施例的步骤420中，上述的准确匹配、相似度匹配和加权后匹配都是基于核心词进行的匹配判断，然而本发明的实施例确定上下行协议间的对应关系并不仅限于此。如图3实施例对步骤310的描述可见，还可基于上行协议和下行协议的时间戳来确定二者之间的对应关系。

上下行协议的交互一般都存在时间序列，通过协议的时间戳信息可以辅助判断存在对应关系的上下行协议。进一步，由于在客户端和服务器之间实时有大量的协议交互(心跳包、列表刷新、系统广播事件等)，给上下行协议对应关系的确定带来困难。因此，在一个实施例中，基于时间戳的判断可配合上述基于核心词进行的匹配判断，用来过滤无关协议，以便于更加高效的绑定存在对应关系的上行协议和下行协议。

例如，对于某个特定的上行协议，可在下行协议队列里选择时间戳大于上行协议时间戳的协议，并且时间间隔不超过预设阈值(例如3秒)的下行协议，后续仅针对选择出的下行协议进行上述的名称获取、分词和过滤、以及基于核心词进行匹配判断等操作，从而减轻处理负担，提高处理效率。

步骤430的第二部分涉及确定上下行协议是否符合测试对象条件。

在一个实施例中，可基于核心词的准确识别来确定符合测试对象条件的上下行协议。

准确识别是通过判断核心词是否命中关键词或关键词组合，来识别上下行协议的操作及名称是否符合测试对象条件。这里的关键词和关键词组合的数据例如可源于已有的程序漏洞数据、人工经验总结以及近义词扩展等等。

以游戏程序的应用场景为例，这里的准确识别例如可以用来识别上下行协议的操作及名称是否可能存在风险。

例如，可设置第一关键词集合包括buy,purchase,exchange,bid等涉及内购操作的关键词，如果步骤420得到的协议名称核心词落入第一关键词集合的范围，即包括来自第一关键词集合的任意关键词时，可确定对应的上下行协议可能存在风险，因此符合测试对象条件。

进一步，例如还可设置第二关键词集合包括shop,card等疑似涉及内购操作的关键词，如果步骤420得到的协议名称核心词落入第二关键词集合的组合范围，即包括来自第二关键词集合的多个关键词的组合时，可确定对应的上下行协议存在风险的可能性很大，因此符合测试对象条件。

在一个实施例中，上述第二关键词集合还可支持通配符匹配，例如包括通配符“*”表示任意一个不属于过滤词汇表的单词。当步骤420得到的协议名称核心词落入第二关键词集合的组合范围时，例如第二关键词集合中包括shop和通配符“*”，而协议名称核心词包括shop和card时，其符合第二关键词集合中shop和“*”的组合规则，因此可确定对应的上下行协议符合测试对象条件；反之，如果协议名称核心词仅包括shop，由于其并未包括第二关键词集合中多个关键词的组合，因此可确定对应的上下行协议不符合测试对象条件。

在另一个实施例中，步骤430还可基于协议字段的模糊识别来确定符合测试对象条件的上下行协议。

模糊识别是指通过检查协议字段是否含有关键词集合中的任意关键词，来判断该协议是否符合测试对象条件，而不是仅仅关注协议的名称和操作。

一般而言，每组上行协议或下行协议的数据都由若干字段组成，每个字段可具有字段命名和赋值。模糊识别可通过协议数据中所有字段的命名来判断是否符合测试对象条件。在一个实施例中，字段命名可通过已知的协议文件获取或者在接入本发明实施例的测试工具时动态获取；另外，在使用字段命名进行判断之前，也可参照步骤420进行字段命名的分词和过滤处理，此处不加以赘述。

以游戏程序的应用场景为例，这里的模糊识别例如可以用来识别上下行协议的所有字段是否可能存在风险。例如，可设置关键词集合包括num,number,count,cost,amount,quantity等涉及数目或数值的关键词，如果上下行协议数据中的任一字段命名落入该关键词集合的范围，即包括来自该关键词集合的任意关键词时，可确定对应的上下行协议可能存在风险，因此符合测试对象条件。这里与数目或数值关键词相关的风险例如可包括零值、负值、临界值风险等等。

通过上述的模糊识别，可以极大提升确定测试对象条件的命中率，避免部分程序协议因命名不规范导致前述基于名称核心词的准确识别失效的问题。

在步骤440中，将与上行协议关联的测试数据传送至客户端执行。

对于步骤430确定出的存在对应关系并符合测试对象条件的上行协议和下行协议，本步骤接续将与其中上行协议关联的测试数据传送至客户端执行。

如前文所述，本发明的实施例可根据服务器对测试数据和正常数据的反馈来确定程序是否存在漏洞。相应的，这里的测试数据一般是指异常数据，从而可用来测试服务器对其产生的反馈与对正常数据的反馈是否相同。

在一个实施例中，测试数据可从预先设置的数据库中获取。例如，对于事先被确定为测试对象的协议，可预先构造相应的测试数据并存储于数据库中。一旦从客户端与服务器交互的数据中识别出对应的协议，便可从数据库中提取相应的测试数据发送至客户端执行。

在另一个实施例中，也可直接基于预设规则来构造相应的测试数据。例如，对于步骤430确定出的特定上行协议，本步骤可接续基于预设规则来构造相应的测试数据。

以游戏程序的应用场景为例，可用来构造测试数据的策略例如可包括但不限于：零值盗刷、负值盗刷、数据截断、乘法溢出、加法溢出、协议重发、协议并发、常见值类型漏洞、id规则变化、枚举规则变化等等。测试数据的构造自身并非本发明关注的内容，在此不再赘述。

在步骤450中，基于来自服务器的与下行协议关联的返回数据确定是否存在漏洞。

如前文所述，本发明实施例所使用的测试数据一般是指异常数据，从而可用来测试服务器对其产生的反馈与对正常数据的反馈是否相同。

在一个实施例中，这里服务器对正常数据的反馈可来自步骤430的确定过程。例如，步骤430在确定存在对应关系并符合测试对象条件的上行协议和下行协议的同时，可记录服务器返回的下行协议数据的结构、字段、字段内容等信息，从而作为与测试数据响应的比较基准。

接续，在客户端执行测试数据后，基于对服务器返回的下行协议数据进行分析，如果服务器对前后两组数据(例如步骤430的上行协议数据和步骤440的测试数据)的响应相同，说明服务器无法识别出异常数据，因此确定程序存在漏洞，也即相应的协议存在漏洞；如果服务器的响应不同，则说明服务器可能对异常数据进行了区分处理，因此可确定程序不存在漏洞，也即相应的协议不存在漏洞。

在一个实施例中，本步骤基于来自服务器的与下行协议关联的返回数据确定是否存在漏洞，可通过结构一致性检查、错误码识别、超时校验和错误下行协议识别等判断方式择一或任意组合来实现。

结构一致性检查

结构一致性检查可通过判断返回数据是否符合下行协议的数据结构来确定漏洞，若不符合则可确定不存在漏洞，反之，若是则确定存在漏洞或可继续其他判断。

结构一致性检查例如可包括检查返回数据与正常下行协议的字段个数、字段名称等是否匹配。

错误码识别

错误码识别可通过判断返回数据的协议字段中是否包括错误码来确定漏洞，若包括则确定不存在漏洞，反之，若不包括则确定存在漏洞或可继续其他判断。

错误码识别例如可包括确认错误码的值与正常协议是否相同、确认错误码是否命中预设规则中正常的错误码值等等。错误码识别的具体手段与上述步骤430中所述的准确识别和模糊识别类似。

例如，判断错误码与第一关键词集合中的关键词(例如result，表示结果)是否完全相等，或者与第二关键词集合中的关键词组合(例如表示错误的关键词err和error，与表示码字的关键词id和code组合)是否匹配。为了提高错误码识别的准确率，还可以增加额外的匹配规则。例如，错误码识别中去除通配符的匹配规则，并且要求两个关键词的组合需要满足连续要求，中间不能间隔其他字段。

在一个实施例中，错误码识别可在结构一致性检查确定返回数据符合下行协议的数据结构时进行，或者也可单独进行。

超时校验

部分程序的服务器会被设置为丢弃错误数据的上行协议，而不返回任何下行协议。因此，通过上行协议超时校验，也可用来判断服务器是否识别出异常的测试数据。例如，从客户端发出上行协议开始，如果在预设时间(如3秒)内都未收到返回的下行协议，或者即使收到返回数据但已经超过了预设时间，则可确定不存在漏洞，反之，则可确定存在漏洞或可继续其他判断。

错误通知协议识别

部分程序的下行协议字段中不含错误码，如果服务器识别出异常数据，是通过单独的错误下行协议来通知客户端。因此，在确定返回数据属于错误通知协议时，也能够准确判断当前测试对象没有漏洞，并且还能避免没有对应的返回数据时，进行超时校验会降低检测效率的问题。

在步骤460中，根据确定是否存在漏洞的结果生成并展示测试报告。

基于步骤450得到的测试结果，步骤460可生成相应的测试报告并通过适当的形式展示给测试人员。例如，测试报告可包括本次确定出符合测试对象条件的所有上下行协议名称，以及重点标识出存在漏洞的上下行协议名称，同时还可提示测试人员可能的下一步处理操作。

在一个实施例中，步骤460还可包括将所有测试数据记录到数据库的步骤，以便于后续其他处理或人工审核进行调用。

本发明的实施例提供的识别程序漏洞的方案，基于确定出存在对应关系的上行协议和下行协议，通过发送测试数据给客户端执行，并对服务器的响应进行分析，能够自动执行程序漏洞的检测识别，提高了测试效率。

图5是根据再一示例性实施例示出的一种识别程序漏洞的方法的流程图。本实施例的方法由测试客户端51和测试服务器52配合完成程序的漏洞检测。换言之，本实施例的方法自身也可实施为cs架构的程序。如图5所示，本实施例的方法可包括以下步骤510-580。

在步骤510中，测试客户端51根据客户端发送的上行数据和服务器发送的下行数据，获取并上报上行协议和下行协议的协议名称。

在一个实施例中，测试客户端51与测试对象所在的客户端可以是指同一个移动终端，或者是安装在同一个移动终端上的两个客户端程序。但本发明的实施例也不仅限于此，只要满足测试客户端51与测试对象客户端之间能够实现通信即可。

基于客户端发送的上行协议及接收的下行协议，测试客户端51在步骤510中获取二者的协议名称，并上报给测试服务器52进行处理。在一个实施例中，测试客户端51可通过注入和hook(钩子)技术从客户端获取上下行协议数据。

在一个实施例中，测试服务器52独立于上述测试对象对应的服务器，从而避免对测试对象的服务器造成性能开销，也方便快速接入更多的测试对象。

在步骤520中，测试服务器52基于接收的协议名称确定存在对应关系并符合测试对象条件的上行协议和下行协议。

测试服务器52在步骤520的处理可参考上文图4实施例中步骤420和430的描述，此处不再赘述。

在步骤530中，测试服务器52将与上行协议关联的测试数据下发至测试客户端51。

在步骤540中，测试客户端51将接收的测试数据发送至客户端执行。

测试服务器52在步骤530的处理可参考上文图4实施例中步骤440的描述，但与其不同之处在于，本实施例中测试数据是先由测试服务器52下发至测试客户端51，再由测试客户端51发送至测试对象的客户端进行执行。至于测试数据的生成和获取等可参照步骤440的描述，此处不再赘述。

在一个实施例中，测试客户端51也可通过注入和hook技术控制客户端执行上述测试数据，即，控制客户端将上述测试数据发送至服务器。

在步骤550中，测试客户端51将来自服务器的与下行协议关联的返回数据上报至测试服务器52。

在一个实施例中，作为测试对象的客户端在收到服务器对测试数据的响应时，可将相应的返回数据发送至测试客户端51进行处理。

在另一个实施例中，可由测试客户端51主动监控测试对象客户端的数据交互，在确定其收到服务器针对测试数据的响应时，主动获取相应的返回数据。

对于获取到的返回数据，测试客户端51将其上报至测试服务器52进行处理。

在步骤560中，测试服务器52基于接收的返回数据确定是否存在漏洞。

测试服务器52在步骤560的处理可参考上文图4实施例中步骤450的描述，此处不再赘述。

在步骤570中，测试服务器52将测试结果记录入数据库53。

在步骤580中，测试服务器52通知网络服务器54生成测试报告。

在一个实施例中，测试服务器52可通过调用邮件接口通知网络服务器54，收到通知的网络服务器54访问数据库53获取结果，并生成例如网页形式的测试报告，从而便于展示给访问网络服务器54的测试人员。

从上述实施例步骤510-580的描述可见，在整个测试过程中，测试客户端51仅负责进行数据的获取和转送，至于大量的分析处理都由测试服务器52完成，这种cs架构的分布式处理，能够更加充分利于服务器的处理能力，防止测试客户端51因处理负担过重而影响终端设备的性能。

本发明的实施例提供的识别程序漏洞的方案，基于确定出存在对应关系的上行协议和下行协议，通过发送测试数据给客户端执行，并对服务器的响应进行分析，能够自动执行程序漏洞的检测识别，提高了测试效率。

下述为本发明装置实施例，可以用于执行本发明上述识别程序漏洞的方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明识别程序漏洞的方法实施例。

图6是根据一示例性实施例示出的一种识别程序漏洞的装置的框图。该装置用于对基于客户端和服务器架构的程序进行漏洞检测，可以由任意计算设备实现。如图6所示，本实施例的装置包括绑定模块61、测试模块62和确定模块63。

绑定模块61用于根据所述客户端发送的上行数据和所述服务器发送的下行数据，确定存在对应关系并符合测试对象条件的上行协议和下行协议。

在一个实施例中，绑定模块61基于上行协议和下行协议的协议名称或者时间戳确定上行协议和下行协议之间是否存在所述对应关系。

在一个实施例中，绑定模块61基于上行协议和下行协议的协议名称或协议字段确定上行协议和下行协议是否符合所述测试对象条件。

测试模块62用于将与所述上行协议关联的测试数据传送至所述客户端执行。

确定模块63用于基于来自所述服务器的与所述下行协议关联的返回数据确定是否存在漏洞。

在一个实施例中，确定模块63基于以下所述方式择一或任意组合来确定是否存在漏洞：

判断返回数据是否符合下行协议的数据结构，若不符合则确定不存在漏洞；

判断返回数据是否包括错误码，若是则确定不存在漏洞；

判断返回数据是否超过预设时间才收到，若是则确定不存在漏洞；以及

判断返回数据是否属于错误通知协议，若是则确定不存在漏洞。

本发明的实施例提供的识别程序漏洞的方案，基于确定出存在对应关系的上行协议和下行协议，通过发送测试数据给客户端执行，并对服务器的响应进行分析，能够自动执行程序漏洞的检测识别，提高了测试效率。

图7是根据另一示例性实施例示出的一种识别程序漏洞的装置的框图。如图7所示，在图6所示实施例的基础上，本实施例的装置还包括展示模块64，并且绑定模块61进一步包括分词过滤单元611、对应关系分析单元612以及测试对象分析单元613。

展示模块64用于根据确定模块63的测试结果生成并展示测试报告。

分词过滤单元611用于对获取的上下行协议名称进行分词和过滤处理，分别得到上行协议和所述下行协议的名称核心词。

对应关系分析单元612用于在上行协议的名称核心词与下行协议的名称核心词完全匹配、或者相似度高于预设阈值、或者加权后的相似度高于另一预设阈值时，确定上行协议和下行协议存在所述对应关系。对应关系分析单元612的操作可参见图4实施例步骤430中第一部分的描述。

测试对象分析单元613用于在名称核心词包括来自第一关键词集合的任意关键词时，或者包括来自第二关键词集合的多个关键词的组合时，确定上行协议和下行协议符合测试对象条件。测试对象分析单元613还可用于在协议字段的命名包括来自第一关键词集合的任意关键词时，或者包括来自第二关键词集合的多个关键词的组合时，确定所述上行协议和所述下行协议符合所述测试对象条件。测试对象分析单元613的操作可参见图4实施例步骤430中第二部分的描述。

本发明的实施例提供的识别程序漏洞的方案，基于确定出存在对应关系的上行协议和下行协议，通过发送测试数据给客户端执行，并对服务器的响应进行分析，能够自动执行程序漏洞的检测识别，提高了测试效率。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。

图8示出了可以应用本发明实施例的识别程序漏洞的方法或装置的另一示例性系统架构800的示意图。

如图8所示，系统架构800可以包括测试客户端801、测试服务器802、数据服务器803和网络服务器804。

在一个实施例中，测试客户端801上同时安装有测试客户端程序和作为测试对象的客户端程序，为以示区别，两个程序分别称为测试程序和待测程序，对应的服务器则分别为测试服务器802和待测服务器(未示出)。

下面描述系统架构800的示例性工作流程。

首先，测试客户端801根据待测程序发送的上行数据和待测服务器发送的下行数据，获取并上报上行协议和下行协议的协议名称。

接续，测试服务器802基于接收的协议名称确定存在对应关系并符合测试对象条件的上行协议和下行协议，进而将与上行协议关联的测试数据下发至测试客户端801。

然后，测试客户端801将接收的测试数据交由待测程序执行，进而将来自待测服务器的与下行协议关联的返回数据上报至测试服务器802。

最后，测试服务器802基于接收的返回数据确定是否存在漏洞，并将测试结果记录在数据服务器803中，同时通知网络服务器804访问数据服务器803基于测试结果生成测试报告。

这样一来，测试人员或其他相关人员可基于任意终端设备805访问网络服务器804，从而获取到网络服务器804以适当形式展示的测试报告。

关于上述实施例中的系统架构，其中各个部分执行操作的具体方式已经在有关该方法的实施例(例如可参见图5)中进行了详细描述，此处将不做详细阐述说明。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本发明实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。