OpenZeppelin谈安全：如何用黑客思维，让安全测试变得更有趣？

在巴黎这周火热展开的加密盛事中，除了备受瞩目的以太坊 EthCC，同样吸引眼球的还有 2023 年度 DeFi 安全峰会。在这次峰会上，OpenZeppelin EMEA 地区安全服务经理 Felix 在 2023 年度 DeFi 安全峰会上发表的演讲，BlockBeats 为您整理翻译如下：

大家好，我是 OpenZeppelin 的 Felix。您可能知道我们为智能合约提供了一份安全库，但我们的服务领域远不止于此，还包括审计、监控以及许多其他方面。今天我想与您探讨的主题是——测试。

这是当前摆在我们面前的一个重要问题：如果我们实现了 100% 的测试覆盖率，那么我们是否真正获得了安全性？如果获得了，那么是有限的安全性还是大量的安全性？我将在今天的演讲中尝试回答这个问题。然而在深入讨论这个问题之前，不如让我们先退一步，回答我们为什么要进行测试？

一般来说测试的目的有：您可能想验证自己的代码库是否实现了特定的功能，也可能是 您期望它具备这个功能。

这就是测试的初衷，但如果深挖一层，您会发现测试还有其他的目的。您可能不仅仅想做单元测试，您可能还想做一些集成测试或端到端的测试，这些测试其实拥有「描述性」的属性。因此，您可以清晰地看到您的代码库的正常运行路径是什么样的，潜在的最终用户将如何与您的代码库进行交互。这种「描述性」的属性也是其中一部分。然而，它是否真正有助于安全性呢？

我们希望它能够增强安全性。然而，对于这个问题，我们在当前这张幻灯片上还无法得出答案。因此，让我们先继续探讨，稍后再返回这个问题。现在，我们来谈谈测试的质量。随着时间的推移，您可能希望完成测试。因此，我们有各种不同的质量指标。

首个指标是「功能性」，也就是代码库的测试覆盖率。这通常表示为行覆盖率或分支覆盖率。这是一个很好的参考数值。我们假设在我们的测试样本中，这个数字达到了 100%，在这方面我们做得很好。

「描述性」意味着您有一些有趣的测试用例，不仅仅是非常小的单元测试，而是一些非常有趣的端到端测试用例。现在问题又来了，我们是否需要一个额外的指标，或者我们已经偶然实现了完美的安全性？让我们看一个小例子：这是我写的一个非常小的 ERC20 代币：

在幻灯片上半部分可以看到，100% 的测试覆盖率由 Foundry（Solidity 框架）保证。从幻灯片下半部分看到，这个代币有三个用例：铸造、销毁和转移。它们都能工作，并在这个测试用例中被覆盖。基本上我们在「功能性」和「描述性」方面做得很好，那么我们安全吗？

不，这有一个公开的销毁漏洞，您可以销毁任何用户的代币。这是一个关键的漏洞，安全性几乎是 0%。您需要修复这个，不能以这种形式进行部署。那么到底缺少了什么？

上面的这个测试用例是缺少的。在 Foundry 语法中，如果某个函数名以「test fail」开头，差不多意味着它用于检查特定的失败案例。典型的测试可能检查一个任意地址是否能够销毁另一个用户的 1000 枚代币。显然，您希望这样的情况不会发生，所以编写了这种负面测试。这只是一个简单的示例，让我们来看看总体原则。

当人们说他们在进行测试时，我们通常看到的大部分都属于左边的范畴。他们进行功能测试，关注覆盖率。这的确是测试的一部分，且做得非常好，但其实与安全性的关联并不直接。如果您想进行安全测试，您需要向右看。

您需要问自己，我是否充分测试了应用的功能？例如，对于未授权的函数，我是否真的测试了任意一个地址不能以特定方式与合约进行交互的情况？因此，应用感知测试就是我们这里所说的安全测试。

现在我想再退一步，思考另一个问题，测试在理论和实践中是如何进行的？

IBM 提供的理论数字表明我们应该大力投资于测试，因为这会带来实际回报。如果您在设计阶段、实现阶段或专门的测试阶段提前发现问题，成本相对较低。然而在部署阶段，成本可能会急剧升高。这并非只适用于区块链系统，在此情况下，您看到的「100」这个数字可能会因为协议所带的 TVL 进一步提升。

这一原则适用于任何软件系统。因此，在理论上，每个人都应尽可能做好测试，因为经济学原理明确告诉我们这将带来回报。但是在实践中，测试并不是一件充满魅力的事情。测试并不「酷」。没有人会说，「我对 QA 测试真的很热衷，我是一个测试人员」。所有「酷」的事情基本上都与黑客有关。当然，对于您的协议来说，被黑客攻击是一件坏事。但黑客很「酷」，而测试则是必须做的、却不受欢迎的任务。

那么我们应该如何解决这个问题呢？这是我使测试变得有吸引力的秘诀：将黑客视为测试的一部分。

要做真正好的安全测试，我们需要从「while true」开始，因为您可以永远地迭代这个循环。您的目标是创造出一个全新的 POC 漏洞，尝试攻击您正在开发的协议。您也许会验证它不起作用，或者发现一些需要修复的东西。然后您可以把它作为一个测试用例集成到您的安全测试套件中。

通过将黑客思维应用到日常活动中，可以提高测试的吸引力。这不仅仅是您所知道的单元测试或者无聊的测试，那是典型的大学课程。这个安全测试，更像是现代的黑客思维的应用，只是将其应用到一个可以并入您的测试套件的工件上。

这是个很好的理论，但现在我们需要增加一些实践的角度。让我们看一下今年有哪些项目在代码级别存在漏洞。我在这里谈论的不是私钥泄漏这种低级的错误，而是因为在代码中存在 Bug。如果用上面的测试方法，本来或许会阻止被盗事件的发生。今年被盗的资金已经达到了 2.5 亿美元，我认为这是一个有力的论据，可能会推动将这种安全测试集成到测试套件中。

如果您是一个决策者，您可能不想记住所有的细节，而只想要一个简单的标准。根据概念漏洞证明，统计你的测试套件中有趣的测试用例的数量，并将此作为安全测试的度量标准。总的来说，100% 的测试覆盖率是针对功能性的测试。它与安全性无关。如果您想做安全测试，您应该测试那些不存在的部分。想以一种好的方式做安全测试，需要采用黑客的思维，并且真的把 POC 漏洞作为测试套件的一部分。

不过遗憾的是，这并不是一劳永逸的灵丹妙药。您可以把它作为您项目的一部分开始，然后最好联系您的安全合作伙伴，以进一步增强这种测试方法。

黑客

安全

OpenZeppelin

项目动态

前沿动态，一手掌握

—-

编译者/作者：区块律动BlockBeat

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。