Fuzzing(模糊测试)

go fuzz文档

对于软件开发者而言，一项重要的任务就是确保程序的安全性。而其中一种风险就是软件中可能存在的漏洞。传统的测试方法往往需要耗费大量的时间和人力，而使用Fuzzing技术则可在短时间内大规模发现潜在的漏洞。

那什么是Fuzzing技术呢？简单说，它就是让程序自动生成大量随机的输入数据，然后运行被测试的程序，观察是否会出现异常行为。通过这种方式，Fuzzing技术可以快速发现和定位程序中的漏洞，帮助开发者提高程序的安全性。

那在Go语言中，如何使用Fuzzing技术呢？下面就让我们一起来了解一下。

Fuzzing，又叫fuzz testing，中文叫做模糊测试或随机测试。其本质上是一种自动化测试技术，更具体一点，它是一种基于随机输入的自动化测试技术，常被用于发现处理用户输入的代码中存在的bug和问题。

在具体实现上，Fuzzing不需要像单元测试那样使用预先定义好的数据集作为程序输入，而是会通过数据构造引擎自行构造或基于开发人员提供的初始数据构造一些随机数据，并作为输入提供给我们的程序，然后监测程序是否出现panic、断言失败、无限循环等。这些构造出来的随机数据被称为语料(corpus)。另外Fuzz testing不是一次性执行的测试，如果不限制执行次数和执行时间，Fuzz testing会一直执行下去，因此它也是一种持续测试的技术。

Fuzzing是对其他形式的测试、代码审查和静态分析的补充，它通过生成一个有趣的输入语料库，而这些输入几乎不可能用手去想去写出来，因此极易被传统类型的测试所遗漏。Fuzzing可以帮助开发人员发现难以发现的稳定性、逻辑性甚至是安全性方面的错误，特别是当被测系统变得更加复杂时。

Go 1.18版本正式接受了原生支持Fuzzing这个特性，Fuzzing成为Go的“一等公民”。

要求

Go Fuzz结构如图:

模糊测试必须遵循下⾯的规则：

模糊测试函数名必须是 FuzzXxx ,参数是 *testing.F ，没返回值 ,如 func FuzzXxx(f
*testing.F)
模糊测试必须放在以 *_test.go 后缀的⽂件中
fuzz target 必须是调⽤ (*testing.F).Fuzz ,第⼀个参数 *testing.T , 后⾯是模糊测试的参数
⼀个模糊测试只能有⼀个fuzz target
种⼦语料(seed corpus )的数据类型必须和 fuzzing arguments⼀样，顺序⼀致。包括调⽤ (*testing.F).Add 增加种⼦语料，以及写在testdata/fuzz⽂件夹下语料
fuzzing arguments 只能是下⾯的类型。如果你要测试复杂的struct,需要使⽤这些参数组装你的struct,然后进⼀步测试:
- string , []byte
- int , int8 , int16 , int32 / rune , int64
- uint , uint8 / byte , uint16 , uint32 , uint64
- float32 , float64
- bool

示例

下面我们使用Fuzz对DNP3协议进行测试

func FuzzDnp3(f *testing.F) {
	f.Add([]byte{
		0x05, 0x64, 0x20, 0x44, 0x03, 0x00, 0x04, 0x00, 0x95, 0xe3, 0x85, 0x00, 0x01, 0x00, 0x00, 0x00,
		0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0xef, 0xdc, 0x00, 0x01, 0x00, 0x00,
		0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x9b, 0x1f,
	})
	f.Fuzz(func(t *testing.T, data []byte) {
		Decode(data)
	})
}

可以使用命令运行

go test -v -fuzz  .

在Goland中也可以直接运行点击函数旁边的运行符号选择Fuzz进行运行,

D:\dev\Go\go1.20.1\bin\go.exe test -json app_go/pkg/dnp3 -fuzz ^\QFuzzDnp3\E$ -run ^$ #gosetup
kg/dnp3"}
=== RUN   FuzzDnp3
fuzz: elapsed: 0s, gathering baseline coverage: 0/23 completed
fuzz: elapsed: 0s, gathering baseline coverage: 23/23 completed, now fuzzing with 8 workers
fuzz: elapsed: 3s, execs: 99037 (32828/sec), new interesting: 1 (total: 24)
fuzz: elapsed: 6s, execs: 133383 (11479/sec), new interesting: 1 (total: 24)
fuzz: elapsed: 8s, execs: 133383 (0/sec), new interesting: 1 (total: 24)
--- PASS: FuzzDnp3 (8.02s)
PASS
ok  	app_go/pkg/dnp3	8.530s

fuzz testing默认会一直执行下去，直到遇到crash。如果要限制fuzz testing的执行时间，可以使用-fuzztime，比如下面的命令允许fuzz testing只执行10

go test -v  -fuzztime 10s -fuzz .

在上面fuzz执行过程中，Go fuzzing会将其缓存在cache路径下：

go fuzzing会为每个FuzzXxx函数建立对应的语料缓存。目前fuzz cache的默认路径为$GOCACHE/fuzz/包路径/FuzzXxx，后续可能会提供环境变量或cmd option，以允许开发人员自定义fuzzing语料的缓存路径。

fuzzing test默认会一直执行下去，如果不限制执行次数和执行时间，执行Fuzzing test的机器要有足够的存储才行。而要想清理过多的fuzz缓存，用gotip clean -cache是不行的，需要为clean加上**-fuzzcache**才可以清除fuzz的cache。

模拟crash

当我们在代码中模拟一个crash的产生来看看：fuzzing test过程中发现代码bug时

我们看到go fuzzing在执行测试时就发生crash，fuzzing将crash输出了crash报告，并将引发这一crash的语料放入了testdata/fuzz/FuzzSubmit目录下：

=== RUN   FuzzDnp3
fuzz: elapsed: 0s, gathering baseline coverage: 0/24 completed
failure while testing seed corpus entry: FuzzDnp3/seed#13
fuzz: elapsed: 0s, gathering baseline coverage: 12/24 completed
--- FAIL: FuzzDnp3 (0.22s)
    --- FAIL: FuzzDnp3 (0.00s)
        testing.go:1485: panic: interface conversion: cache.Value is nil, not *dnp3.DNP3
            goroutine 28 [running]:
            runtime/debug.Stack()
            	D:/dev/Go/go1.20.1/src/runtime/debug/stack.go:24 +0x9e
            testing.tRunner.func1()
            	D:/dev/Go/go1.20.1/src/testing/testing.go:1485 +0x1f6
            panic({0xec5240, 0xc0001149c0})
            	D:/dev/Go/go1.20.1/src/runtime/panic.go:884 +0x213
            app_go/pkg/dnp3.Decode({0xc00017e140, 0x124, 0x140})
            	D:/workspace/project/**/pkg/dnp3/dnp3.go:137 +0xf49
            app_go/pkg/dnp3.FuzzDnp3.func1(0x0?, {0xc00017e140?, 0x0?, 0xc182f9?})
            	D:/workspace/project/**/pkg/dnp3/dnp3_test.go:254 +0x45
            reflect.Value.call({0xeba2c0?, 0xf2f248?, 0xbff076?}, {0xf00b82, 0x4}, {0xc000114960, 0x2, 0x2?})
            	D:/dev/Go/go1.20.1/src/reflect/value.go:586 +0xb07
            reflect.Value.Call({0xeba2c0?, 0xf2f248?, 0x107dd00?}, {0xc000114960?, 0xf00080?, 0xc000112678?})
            	D:/dev/Go/go1.20.1/src/reflect/value.go:370 +0xbc
            testing.(*F).Fuzz.func1.1(0x0?)
            	D:/dev/Go/go1.20.1/src/testing/fuzz.go:335 +0x3f3
            testing.tRunner(0xc0001249c0, 0xc00012a630)
            	D:/dev/Go/go1.20.1/src/testing/testing.go:1576 +0x10b
            created by testing.(*F).Fuzz.func1
            	D:/dev/Go/go1.20.1/src/testing/fuzz.go:322 +0x5b9
        
  

FAIL
exit status 1
FAIL	**/dnp3	0.597s

进程 已完成，退出代码为 1

如果是真实的fuzz测试引发了crash，我们可以将该语料提取出来，建立针对它的TestXxx或为现有TestXxx添加一条测试数据来验证目标方法是否真实存在缺陷，如果的确存在缺陷，我们就需要修复它，并在修复后再次运行TestXxx，以保证我们的修复是有效的。