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 漏洞作為測試套件的一部分。

不過遺憾的是，這並不是一勞永逸的靈丹妙藥。您可以把它作為您項目的一部分開始，然後最好聯繫您的安全合作夥伴，以進一步增強這種測試方法。

原文連結