基于灰盒模糊技术的QUIC协议测试方法与流程

基于灰盒模糊技术的quic协议测试方法
技术领域
1.本发明属于网络协议测试领域，涉及基于灰盒模糊技术的quic 协议测试方法；具体地，涉及基于并改进模糊测试领域中的灰盒模糊测试技术以检测新型互联网传输协议，即quic协议中潜在的设计漏洞。


背景技术：

2.在这个智能网络、万物互联的时代，互联网需要承载并处理海量的连接，在不牺牲安全性和可靠性的前提下，对低延迟的需求也在不断增长。当前互联网广泛使用的传输协议是传输控制协议(transmission control protocol,tcp)。然而，tcp作为传输层协议，提供尽力而为的服务能力，使得应用程序的性能难以得到保障。tcp 主要存在以下问题：(1)在实际的传输过程中，tcp握手会引入一个往返时间(rtt)的延迟，若要提供安全传输，还需引入安全传输层协议(transport layer security,tls)，此时将引入更大的往返时间延迟；(2)当数据包丢失或重传时，tcp性能将会降低；(3)tcp协议是在系统内核中构建的，使得协议的更新存在诸多困难。因此，为了解决tcp存在的各种问题，谷歌提出了快速udp互联网连接 (quick udp internet connections,quic)协议，quic是一种新型网络安全传输协议，目前正在进行ietf标准化。quic是基于udp定义的，目标是通过在最佳情况下建立连接时直接发送数据来减少连接延迟。quic旨在替代tls/tcp堆栈，以便通过有序通道进行安全的、经过身份验证的通信，并将作为http/3(超文本传输协议的下一个正式版本)的基础。目前，quic协议在互联网上承载超过5％的流量，作为http/3的基础，在其标准化之后，quic将承载大部分流量，可以预测，quic协议将变得越来越重要。quic通过集成tls 安全功能并强制对所有连接数据进行加密来提供安全的传输，但是， quic中的0
‑
rtt恢复也可能带来新的安全威胁。因此，为了保障互联网传输的安全和可靠性，设计一种检测quic协议中潜在漏洞的方法具有重要意义。
3.安全漏洞是网络安全威胁的重要来源，而漏洞挖掘技术可以帮助提前检测并修复漏洞，其中模糊测试(fuzzing)是使用最为广泛的漏洞挖掘技术之一，与其他漏洞挖掘技术相比，模糊测试的适用性和可扩展性较好、准确率高、操作简便，无论有无源代码均可执行模糊测试。模糊测试的工作原理是利用计算机和某些变异策略生成大量的常规和非常规的测试用例，将其输入至目标程序并监视其执行状态，当程序出现异常时，模糊器将保存相应的输入文件，待测试结束时进行重现，分析该漏洞的产生原因。
4.根据生成策略的不同，模糊测试分为基于生成规则的模糊和基于变异的模糊。基于生成规则的模糊器利用相应的格式规范来构造输入，以提高测试到目标程序深层代码的可能性，但在构造合适的输入时，分析相应的文件格式是一项艰难的工作；而基于变异的模糊器更容易使用且适用性好，此类模糊器首先需要一个初始测试用例集，通过随机变异现有输入来生成大量的测试用例，随后输入至待测程序中以检测潜在漏洞。
5.根据对源程序的依赖程度，模糊测试分为白盒模糊测试、黑盒模糊测试和灰盒模糊测试。白盒模糊测试利用源码分析获取关于测试用例如何影响程序执行状态的信息；黑
和模糊测试只需要访问程序，其并不知道任何目标程序内部的信息；灰盒模糊测试是介于白盒与黑盒之间的一种测试方法，其采用一些方法从待测程序中获取反馈信息，并利用此信息来引导模糊策略。与其他两种模糊方法相比，灰盒模糊测试通过编译插桩来获取程序信息，既解决了黑盒模糊测试的盲目性，又避免了白盒测试所需的源码分析，节省了人力，提高了效率。
6.当前有很多模糊器，其中afl(american fuzzing loop)是一种基于变异的灰盒模糊测试器。本发明拟应用并优化afl以检测quic 协议中的潜在漏洞。


技术实现要素：

7.未来quic协议将取代tcp，作为互联网中的新型传输协议，因此，检测quic协议中潜在的漏洞至关重要，为解决改技术问题，本发明提供了一种基于灰盒模糊技术的quic协议测试方法。
8.本发明的技术方案：一种基于灰盒模糊技术的quic协议测试方法，包括初始测试用例的构建、请求消息解析模块、请求消息序列变异模块和模糊测试模块。其主要步骤包括：
9.步骤1：构建初始测试用例集；
10.步骤2：通过请求消息解析模块解析步骤1中构建的初始测试用例集，以得到分解后的小测试用例；具体地，步骤2采用请求消息分解算法，将步骤1中构建的初始测试用例集依次解析为单个小测试用例，随后将小测试用例输入至请求消息序列变异模块；
11.步骤3：通过请求消息序列变异模块变异输入的步骤2获得的小测试用例；具体地，利用afl中的确定性变异策略和随机性变异策略来变异小测试用例，随后将生成的变异后的小测试用例输入至模糊测试模块；
12.步骤4：将步骤3中获得的变异后的小测试用例输入至被测程序中，开始执行模糊测试，当程序出现异常时，直接输出导致程序异常的测试用例。
13.进一步地，所述步骤1中，构建初始测试用例集具体包括以下步骤：
14.步骤1.1：由于quic协议为被广泛应用，所以，当前需要通过编译quic协议的开源项目来获取quic数据包。在此，将编译完成获得的服务器和客户端分别称为示例服务器和示例客户端。首先，使示例服务器与示例客户端进行模拟通信，在模拟通信过程中，使用网络嗅探器抓取quic数据包；
15.步骤1.2：获取到quic数据包之后，使用数据包分析器过滤出 quic数据包中服务器的相关信息，仅保留其中的客户端请求消息作为初始测试用例集。
16.进一步地，所述步骤2中的请求消息解析模块中采用请求消息分解算法，利用该请求消息分解算法将步骤1得到的初始测试用例分解为多个小测试用例。针对应用原始afl模糊测试quic协议时，初始测试用例即为步骤1中得到的quic数据包。对于本发明中的优化 afl模糊测试quic协议时，初始测试用例选择为解析后的小测试用例。详细步骤包括：
17.步骤2.1：准备工作。请求消息分解算法将整个quic协议请求消息分解出多条请求消息，每条请求消息即为每个quic数据包。因此，首先通过获取到的quic数据包了解其主要格式，至此准备工作完成；
18.步骤2.2：设计请求消息分解算法。此步骤主要通过了解quic 数据包格式来设计
算法，使其能够将初始测试用例集中的测试用例以此分解为小测试用例；
19.步骤2.3：执行请求消息分解分解算法。从存放整个初始测试用例的缓冲区中逐字节读取，并根据步骤2.1对quic数据包的了解，当读取到每个quic数据包的结尾时停止读取，此时一个quic数据包分解完成。随后重复此步骤，直至所有quic数据包分解完成；
20.步骤2.4：获取小测试用例。当所有quic数据包均分解完成时，将获得模糊测试需要的小测试用例，随后将其发送至请求消息变异模块执行变异操作。至此，请求消息分解模块完成。
21.进一步地，所述步骤3中，具体包括以下步骤：
22.步骤3.1：读取步骤2中解析出的小测试用例，并加入至输入队列，等待执行变异；
23.步骤3.2：从宏观上看，afl中主要包含两类变异策略，即确定性变异策略和随机性变异策略。其中确定性变异策略包括位翻转、字节翻转、简单算数，随机性变异策略包括拼接、大破坏、插入请求消息、删除请求消息、替换请求消息和复制请求消息；
24.步骤3.3：通过利用步骤3.2中的变异策略来变异输入的小测试用例，以生成变异后的小测试用例，并将其发送至模糊测试模块。
25.进一步地，所述步骤4中，具体包括以下步骤：
26.步骤4.1：将步骤3.3中生成的变异后请求消息发送至待测服务器的源程序中进行测试；
27.步骤4.2：若某一变异后的测试用例执行了新的程序路径，则说明该测试用例为有效的测试用例，将其标记为“有趣的”测试用例，并再次加入至输入队列，等待执行下一轮变异；若某一变异后的测试用例使待测服务器的源程序中出现异常，则说明该测试用例为异常测试用例，并将其输出。
28.本发明是首次将灰盒模糊测试技术应用至quic协议中，通过对现存的灰盒模糊测试器进行改进，以提高模糊测试的有效性。
附图说明
29.图1为基于灰盒模糊技术的quic协议测试方法的整体框架。
30.图2为请求消息解析模块的实现方案。
31.图3为请求消息变异模块的实现方案。
32.图4为模糊测试模块的实现方案。
33.图5为总路径数对比图。
34.图6为执行速度对比图。
35.图7为检测漏洞数对比图。
具体实施方式
36.以下结合附图和技术方案，进一步说明本发明的具体实施方式。
37.1整体框架
38.quic协议旨在替代现阶段使用的tcp协议，同时其也是http/3 的基础，因此，检测quic协议中潜在的漏洞具有重要意义。本发明中首次使用灰盒模糊工具afl进行quic协议测试，同时为了提高测试的有效性，针对afl进行了优化，设计了一种请求消息分解算法和
添加了几种基于请求消息的变异策略。
39.基于灰盒模糊技术的quic协议测试方法的整体框架如图1所示。在整体框架中，共具有三个主要功能模块，即请求消息解析模块、请求消息变异模块和模糊测试模块。在进行测试之前，利用数据包分析器获取quic模拟服务器与客户端间通信的数据包，并过滤出服务器的响应信息，仅保留客户端的请求信息，将该请求信息作为初始测试用例发送至下一模块。在请求消息解析模块中，设计一种请求消息分解算法，利用该分解算法将输入的初始测试用例分解为单个的小测试用例。当分解完成后，将单个的小测试用例发送至消息变异模块。在消息序列变异模块中，主要负责变异输入的小测试用例，从而生成变异后的小测试用例。将变异后的小测试用例发送至待测服务器的源代码中，此时开始正式的模糊测试。当某一变异后的小测试用例执行了新的程序路径，则将其标记为“有趣的”测试用例，并重新加入至输入行列，等待进行下一轮的变异。当某一变异后的小测试用例导致源程序崩溃，则将其标记为“有误的”测试用例，将其输出即可。
40.2请求消息解析模块实现方案的设计
41.在请求消息解析模块中，主要负责将初始测试用例依次分解为多个小测试用例，其目的是构建出更加有效的测试用例。因此，为了得到小测试用例，设计一种请求消息分解算法。该算法的实现主要是通过了解分析quic数据包格式来确定其中包括的主要内容，以及其占用的具体字节数，据此来完成请求消息的提取。因此，在请求消息解析模块开展工作之前，需要根据模拟的quic协议服务器和客户端之间的相互通信来获取其中的quic数据包，并应用数据包分析器过滤出服务器的响应信息，仅保留客户端的请求信息。将该请求信息作为请求消息解析模块的输入。
42.请求消息解析模块实现方案如图2所示。该模块主要设计一种请求消息分解算法，在执行该算法之前，需要详细了解并分析quic数据包格式，以便正确提取出请求消息。其次，定义该算法所需要的变量，并利用这些变量开始执行请求消息分解算法。
43.2.1分析quic数据包格式
44.消息序列解析模块通过识别头部和尾部实现，执行该模块的首要工作是了解分析quic数据包的相关内容，即quic数据包的组成、 quic数据包的头部等相关信息。quic数据包由quic头部和有效载荷组成，其中头部包括long header和short header两种。区分两种头部的方法是数据包中的第一个字节中的第一位，当第一位置为1 时，标识为long header；当第一位置为0时，标识为short header。当为long header时，quic数据包头部共占用45字节；当为shortheader时，quic数据包头部共占用19字节。首先，从消息序列的第一个字节依次读取，并创建一个变量用于存储读取的字节，当读取到有效负载的最后一个字节时，提取出单个的消息序列，至此，消息序列解析模块完成。
45.2.2分解算法中变量定义
46.该算法所定义的变量如表1所示。主要从宏观和微观两个角度定义该算法所需的变量。从宏观上来看，需要定义一个缓冲区用于存放初始测试用例，并指明其长度大小。对于被分解后的单个的小测试用例，同样需要定义一个缓冲区来存放，并定义一个变量用于表示已完成分解的单个小测试用例的数量。
47.从微观的角度来分析，对于初始测试用例，即quic请求数据包，其均由数据包头和有效载荷组成，而该分解算法主要将quic请求数据包提取出来，即从存储quic请求数据包
的缓冲区中的第一个字节开始，直至有效载荷的最后一个字节结束，以此得到分解后的单个数据包，即小测试用例。根据以上描述，首先，同样需要定义一个缓冲区用于存放已提取到的字节，并指明其长度的大小。每当从整个请求数据包中提取一个字节，就需要定义一个变量用于表示该分解算法已经从quic请求数据包中提取到的字节数，同时需要定义一个变量用于存储目前已提取到的字节数，每当一个quic请求数据包提取完成，该变量将被重置为0，以便开始下一个quic请求数据包的提取。每当一个quic请求数据包分解完成，其对应的一个用于存放已完成分解的quic请求数据包数量的变量值即可加一，最后再定义一个缓冲区用于存放已完成提取的单个数据包，即小测试用例，该缓冲区也是该算法最后的返回值。
48.表1分解算法变量定义
[0049][0050]
2.3分解算法
[0051]
算法1.分解算法
[0052]
input:buffer1、buffer1_size；output:single request packets,packet1、 packet2...packet
n
[0053]
1:char*buffer2,*buffer3；
[0054]
2:int buffer3_size＝1024,read_num＝0,read_pkt_num＝0,mess_num ＝0；
[0055]
3:buffer3＝malloc(buffer3_size)；
[0056]
4:int start＝0,end＝0；
[0057]
5:if从quic请求数据包提取出的字节数小于其总字节数
[0058]
6:开始逐字节提取，并将提取出的字节存放至缓冲区buffer3；
[0059]
7:if从单个quic数据包中提取的字节数read_pkt_num>＝数据包头部
[0060]
8:int payload＝buffer3[read_pkt_num]；
[0061]
9:if read_num<buffer1_size&&cur_num<payload；
[0062]
10:此时依然进行逐字节提取，即read_num ，cur_num ， end ；
[0063]
11:end if
[0064]
12:随着提取完成，变量mess_num逐步增加，即mess_num ；
[0065]
13:if提取至该数据包的最后一个字节
[0066]
14:read_pkt_num＝0；start＝end 1；end＝start；
[0067]
15:end if
[0068]
16:end if
[0069]
17:else
[0070]
18:此时，read_pkt_num ，end ，同时判断是否提取至最后一个字节；
[0071]
19:若此时read_pkt_num大于缓冲区buffer1的大小，则需要动态扩大缓冲区的长度；
[0072]
20:end if
[0073]
21:free(buffer3)；
[0074]
22:packet_num＝mess_num；
[0075]
23:return packet1,packet2,...,packetn；
[0076]
2.4分解算法工作过程
[0077]
(1)开始执行。该算法执行的前提条件是从quic请求数据包中已提取的字节数量始终小于其总字节数，即read_num<buffer1_size。当满足此前提条件后，开始分解数据包，并逐字节提取，将提取后的字节存放至缓冲区buffer3；
[0078]
(2)判断条件。首先需要确保从单个请求数据包中提取的字节数不少于quic协议请求数据包的头部大小，即read_pkt_num不小于数据包的头部大小。随着逐字节地提取，为数据包头部中表示有效载荷长度的变量进行赋值，该值表示有效载荷的字节数量；
[0079]
(3)定义一个变量cur_num表示已从有效载荷中提取的字节数量，当已提取出的字节数小于quic请求数据包的总字节数，并且从有效载荷中提取的字节数小于有效载荷的大小时，此时说明仍未提取完成，因此，依然逐字节进行提取；
[0080]
(4)提取小测试用例。随着逐字节的提取，直到某一个quic 数据包提取完成，即单个小测试用例提取完成。此时，需要将其存放在缓冲区buffer2中，同时表示已提取的单个数据包数量的变量 mess_num也将随着提取的完成逐步增加；
[0081]
(5)判断是否提取至最后一个字节。当其已提取至最后一个字节时，则重置变量read_pkt_num，并将该数据包的尾部字节赋值给下一个数据包的头部；
[0082]
(6)当已提取的字节数read_pkt_num少于数据包头部字节数，此时执行逐字节提取即可，同时也需要判断其是否读取至最后一个字节。随着字节的提取，若提取出的字节数多于缓冲区的大小，即 read_pkt_num>buffer1_size，此时需要动态扩大该缓冲区大小；
[0083]
(7)当提取完成时，释放缓冲区buffer3，此时表示该quic请求数据包中的单个数据包数量的变量packet_num的值与表示已从整个数据包提取的单个数据包数量mess_num的值相等，最后返回存放单个请求数据包packet1、packet2...packet
n
的缓冲区，此时分解算法完成。
[0084]
3请求消息变异模块实现方案的设计
[0085]
请求消息变异模块实现方案如图3所示。该模块主要负责变异分解后得到的小测
试用例，以便生成变异后的小测试用例。本模块中，主要添加了几种针对请求消息的变异策略，包括替换、插入、删除、复制消息序列。在实现这几种变异策略时，首先需要随机地从任意一个小测试用例中生成一段请求消息，并将这段请求消息作为备用消息执行插入和替换变异策略，从而生成变异后的小测试用例。
[0086]
3.1随机选取请求消息
[0087]
在执行几种变异策略之前，需要随机的选取一段消息序列进行替换、插入等变异策略。
[0088]
步骤1：在等待变异的输入队列中，随机地选取一个小测试用例 (请求消息)；
[0089]
步骤2：在选取的这个测试用例中，再次从中随机选取一段请求消息，并利用该请求消息实现具体的替换、插入变异策略。
[0090]
3.2替换请求消息
[0091]
在当前的小测试用例中同样随机选择一段请求消息，并将3.1中生成的随机请求消息替换成原来的请求消息，以此生成全新的小测试用例。至此，替换变异策略完成。
[0092]
3.3插入请求消息
[0093]
将3.1中生成的请求消息分别插入至当前请求消息中的头部和尾部。
[0094]
步骤1：在正式执行插入操作之前，首先需要判断插入后的请求消息长度是否超过允许的最大范围，若超过，则不执行插入变异策略；
[0095]
步骤2：当步骤1判断出插入后的请求消息长度未超过允许的最大范围后，开始将3.1中随机生成的请求消息插入至现有消息序列的头部或尾部，以此生成新的请求消息。至此，插入变异策略完成。
[0096]
3.4删除请求消息
[0097]
在当前的小测试用例中随机选取一段请求消息，将其作为需要删除的请求消息。随后在当前的请求消息中随机选取需要删除的请求消息数据量，将一定量的数据删除后生成一个新的小测试用例。至此，删除变异策略完成。
[0098]
3.5复制请求消息
[0099]
复制请求消息操作与插入类似。同样需要判断复制后的请求消息长度是否符合允许的最大范围。当符合允许的最大范围时，将执行复制操作，以生成新的小测试用例。至此，复制变异策略完成。
[0100]
4模糊测试模块实现方案的设计
[0101]
模糊测试模块实现方案如图4所示。该模块主要负责将请求消息变异模块中变异生成的小测试用例发送至待测源程序中，随后执行模糊测试。在此过程中将区分出两类测试用例，即“有趣的”测试用例和“错误的”测试用例。
[0102]
当某一个小测试用例输入至待测源程序中开始执行时，若其执行了新的程序路径，即执行总路径数增加，则将其标记为“有趣的”测试用例，并将其重新加入至输入队列，等待下一轮的变异。
[0103]
当某一个小测试用例输入至待测源程序中开始执行时，若其导致程序异常，则将其标记为“错误的”测试用例，并输出至文件夹中。至此。模糊测试模块完成。
[0104]
5性能评价
[0105]
当该方法的理论设计完成后，将其与原始afl分别用于测试 quic协议。执行实验，
并对该实验进行性能评价。在性能评价的过程中，主要选取三种评价指标，即执行总路径数、执行速度及检测到的漏洞数。
[0106]
执行程序的总路径数性能对比如图5所示。由图可知，在规定的 12个小时内，本文测试方法共执行了130条总路径，而原始afl共执行了45条总路径。当应用afl测试quic协议时，初始测试用例选择的是quic服务器与客户端通信过程中的quic数据包，直接利用其进行模糊测试。本发明的测试方法在测试quic协议时，初始测试用例为分解后的小测试用例，分解后的小测试用例更容易满足 quic服务器端的源代码要求。因此，其能够以更大的可能性来通过源代码验证，从而执行更多的程序路径。相比于原始afl，其模糊测试的性能更好。
[0107]
执行速度的对比如图6所示。由图可知，在相同的时间内，测试初期时中，本发明中的测试方法的执行速度稍低于原始afl，但随着测试的进行，期执行速度相比原始afl更快。当利用afl开始执行模糊测试时，从输入文件夹中读取初始测试用例后，开始执行变异操作，随后再执行模糊测试。当利用本发明中的测试方法执行模糊测试时，首先，从输入文件夹中读取初始测试用例；之后，为了生成更有效的初始测试用例，开始执行本文提出的分解算法；最后，执行变异操作与后续的模糊测试。因此，由于需要执行分解算法，导致在测试初期其执行速度会稍微低于原始afl。但随着测试的进行，其产生的测试用例更加有效，能够更快地通过源代码验证，从而进一步提高了执行速度。
[0108]
检测到的漏洞数对比如图7所示。由图可知，在同等时间内，原始afl检测到2个漏洞，本文测试方法检测到11个漏洞。本文在测试用例生成阶段添加了几类请求消息变异策略，其可以变异生成更多的有效测试用例，能够运行更多的程序路径，从而能够检测到更多的漏洞。
[0109]
以上示例性实施方式所呈现的描述仅用以说明本发明的技术方案，并不想要成为毫无遗漏的，也不想要把本发明限制为所描述的精确形式。显然，本领域的普通技术人员根据上述教导做出很多改变和变化都是可能的。选择示例性实施方式并进行描述是为了解释本发明的特定原理及其实际应用，从而使得本领域的其它技术人员便于理解、实现并利用本发明的各种示例性实施方式及其各种选择形式和修改形式。本发明的保护范围意在由所附权利要求书及其等效形式所限定。