可重入（Reentrancy）或整數(shù)溢出漏洞，是大多數(shù)開發(fā)人員知道或者至少聽說過的，關于智能合約當中容易出現(xiàn)的安全問題。另一方面，在考慮智能合約的安全性時，你可能不會立即想到針對密碼簽名實現(xiàn)的攻擊方式。它們通常是與網(wǎng)絡協(xié)議相關聯(lián)的。例如，簽名重放攻擊（signature replay attacks），一個惡意用戶可竊聽包含有效簽名的協(xié)議序列，并針對目標進行重放攻擊，以期獲得益處。

本文將解釋智能合約處理DAPP生成簽名時可能存在的兩種類型的漏洞。我們將通過Diligence團隊在今年早些時候完成的現(xiàn)實例子審計結果進行分析。此外，我們將討論如何設計智能合約，以避免這類漏洞的出現(xiàn)。

協(xié)議層

簽名是以太坊網(wǎng)絡中的基礎，發(fā)送至網(wǎng)絡的每筆交易都必須具有有效的簽名。下圖顯示了這種交易的一個例子。除了交易標準屬性，例如 from、to、gas、value 或input在全局命名空間中可用，并且經(jīng)常出現(xiàn)在智能合約代碼中，字段v，r以及s共同組成了交易簽名。

以太坊網(wǎng)絡確保只有具有有效簽名的交易可被納入新的區(qū)塊當中。這為交易提供了以下安全屬性：

1．身份驗證：以太坊節(jié)點使用簽名來驗證交易簽名者是否具有與公共地址相關聯(lián)的私鑰。開發(fā)者因此可以信任這個msg．sender是真實的；

2．完整性：交易在簽名后不會發(fā)生更改，否則簽名就是無效的；

3．不可否認性：交易是由from字段中公共地址對應的私鑰簽名的，這是不可否認的，并且擁有私鑰的簽名方已經(jīng)進行了任何狀態(tài)更改。

合約層

協(xié)議層并不是簽名發(fā)揮作用的唯一場地。簽名也越來越多地被用于智能合約本身。隨著gas價格的上漲，而擴容解決方案仍在進程當中，則避免鏈上（on－chain）交易便凸顯出了越來越多的重要性。當談到鏈外的交易時，簽名也是非常有用的，EIP－191以及EIP－712，都是有關于如何處理智能合約中簽名數(shù)據(jù)的通證標準。而后者旨在改善鏈外消息簽名的可用性。那么，為什么它是有用的，以及它是如何節(jié)省鏈上交易的？

讓我們來查看一個簡單的例子。愛麗絲為鮑伯創(chuàng)建了一個命題，她將其編碼成了一條消息。她還用自己的私鑰創(chuàng)建了消息的簽名，并通過協(xié)商好的通道發(fā)送給鮑伯。鮑伯可以驗證愛麗絲是否簽署了該消息，如果鮑伯認為該命題是合適的，那么他可以創(chuàng)建新的交易，將他自己的消息、愛麗絲的消息及簽名共同納入到一個智能合約當中。通過數(shù)據(jù)，這個智能合約可以證實：

1．鮑伯已簽署了自己的信息（或者在這種情況下，交易會是更具體的）。而網(wǎng)絡保證了身份驗證、完整性以及不可否認性。

2．整個過程只需要一筆鏈上交易，其可提供明顯更好的用戶體驗，同時可節(jié)省gas。需要注意的是，智能合約需要確保愛麗絲發(fā)送給鮑伯的消息，能夠保持所有三個安全屬性的完整性。

讓我們分析現(xiàn)實世界中存在的兩種簽名驗證漏洞，并探討如何修復它們。

缺少針對簽名重放攻擊的保護（SWC－121）

第一個例子，是由Consensys的Diligence部門在審計去中心化新聞應用Civil時發(fā)現(xiàn)的一個漏洞例子，與此案例相關的系統(tǒng)的第一部分，被Civil稱之為Newsroom（新聞編輯室），而內(nèi)容編輯可以把自己的文章發(fā)布到這個Newsroom，他們還可以為自己的內(nèi)存創(chuàng)作進行加密簽名，以此證明內(nèi)容實際上是由他們創(chuàng)造的。pushRevision（） 函數(shù)對現(xiàn)有內(nèi)容進行更新或修訂。參數(shù)內(nèi)容哈希、內(nèi)容URI、時間戳以及簽名，為內(nèi)容創(chuàng)建新的修訂。之后，verifiyRevisionSignature（）函數(shù)會調(diào)用提議修訂，以及最初創(chuàng)建第一個簽名修訂的內(nèi)容作者。根據(jù)設計，新修訂的簽署者，只能是創(chuàng)建初始簽名內(nèi)容版本的作者。

verifiyRevisionSignature（） 函數(shù)會根據(jù)DApp生成的內(nèi)容哈希，以及Newsroom合約的地址，創(chuàng)建一個已簽名的消息哈希。然后，調(diào)用recover（）函數(shù)（來自OpenZeppelin 的ECRecovery庫）。隨后，調(diào)用ecrecover（）函數(shù)，并驗證作者是否真正簽署了消息。已討論過的兩個函數(shù)代碼是沒有問題的，因為只有最初創(chuàng)建內(nèi)容的作者才能為它創(chuàng)建新的版本，所以實際上它們不存在什么安全問題。

問題在于，合約是不會跟蹤內(nèi)容哈希的，因此，已提交的一個內(nèi)容哈希及其用戶簽名，實際是有可能被提交多次的。而惡意的內(nèi)容作者就可以利用這個漏洞，從其他作者那里獲取有效的簽名和內(nèi)容哈希，并在他們不知情的情況下為他們創(chuàng)建新的有效修訂。

Civil 已通過跟蹤這些內(nèi)容哈希，并拒絕已是先前修訂部分的哈希，來解決這個問題。

缺乏正確的簽名驗證（SWC－122）

在上一次審計去中心化協(xié)議0x的過程當中，Diligence發(fā)現(xiàn)了這種漏洞類型的一個實例。以下解釋，是這次審計報告當中3－2節(jié)內(nèi)容中描述的問題總結。0x協(xié)議具有不同簽名類型的各種簽名驗證器，包括Web3以及EIP712。另一個存在的驗證器稱為SignatureType．Caller，如果order．makerAddress等于msg．sender（order．makerAddress是創(chuàng)建order的用戶），則允許order有效。如果設置了SignatureType．Caller，則沒有實際簽名驗證是由交易合約執(zhí)行的。現(xiàn)在還不清楚為什么這會導致漏洞，因為已經(jīng)證實msg．sender以及order的創(chuàng)建者是相同的，至少從理論上看是這樣的。

除了交易合約之外，0x系統(tǒng)還有另一部分稱為Forwarder的合約，有了這個合約，用戶可以簡單地發(fā)送以太幣，以及他們想要填寫的 order，而這個Forwarder合約會在同一筆交易中執(zhí)行所有的order；

想要用以太幣交易其他通證的用戶，可以向其他用戶發(fā)送order，而Forwarder合約將代表他們進行交易。這個交易合約會驗證每個order，以確保order簽名的有效性，并確保其他用戶已實際簽署了order。讓我們再次查看上面的圖，并重新評估以下假設：如果order．makerAddress等于msg．sender，則我們不需要在這個交易合約當中進行適當?shù)暮灻炞C，因為發(fā)送交易的用戶也是order的創(chuàng)建者。如果用戶直接向交易合約發(fā)送order，則該假設成立。但是，如果我們通過Forwarder合約發(fā)送這個order，將order．makerAddress設置為 Forwarder合約的地址，并使用SignatureType．Caller簽名驗證器呢？

在交易執(zhí)行處理結算個別order的過程中，F(xiàn)orwarder合約會調(diào)用這個交易合約。這個交易合約會驗證這個order．makerAddress中的地址，就是msg．sender，在這種情況下，可以將其設置為Forwarder地址。由于合約在交易雙方之間起到了中介作用，所以order．takerAddress通常被設置為Forwarder地址。因此，惡意用戶可以使用Forwarder處理order，其中合約會與其本身進行交易，因為它既是接受者又是制造者。這是因為以下的原因：

1．在 Forwarder當中，沒有邏輯可以阻止合約成為一個 order的制造者；

2．用于transferFrom（（address ＿from， address ＿to， uint256 ＿value） ）的ERC20規(guī)范，不會阻止用戶進行“空傳輸”。而 ＿from和＿to可以是相同的地址；

3．這個交易合約允許基于以下事實來處理order：如果用戶實際上已經(jīng)簽署了order，則msg．sender沒有發(fā)送order。

在交易合約解決了order之后，這個Forwarder合約將得到完全相同的 balance，并且Forwarder合約將takerAmount轉移給自己，而把makerAmount轉移給一個惡意用戶，而惡意用戶可以使用這個場景，來創(chuàng)建“惡意order”，以便用1 Wei（以太幣最低單位）的價格從 Forwarder合約中換取到所有的ZRX通證；

綜上所述，假設消息的發(fā)送者也是其創(chuàng)建者，而不去驗證其簽名，這可能是不安全的，尤其是在通過代理轉發(fā)交易的情況下。在合約處理消息簽名的任何時候，都需要執(zhí)行正確的簽名恢復及驗證。0x通過刪除了 SignatureType．Caller簽名驗證器修復了這個問題。

總結

鏈外消息簽名的方式，對于節(jié)省 gas以及改善用戶體驗方面，的確是一個好的方法。但從安全性的角度來看，這無疑增加了復雜性，并使得智能合約在處理已簽名消息的情況下成為了一個更具挑戰(zhàn)性的任務。如果你對針對基于簽名的攻擊，或其它智能合約漏洞示例感興趣，你可以查看SWC－registry在Github的內(nèi)容，里面擁有大量易受攻擊的合約示例，此外還有關于智能合約弱點分類（SWC）計劃的更多信息，我們一直在與社會各界合作。如果你想了解更多關于SWC的信息，或者有其他好的想法，那么歡迎你在ethereum／EIPs以及Ethereum Magicians里面參加關于EIP－1470的討論；