2019年09月13日 AirSwap 團隊公佈了一個 AirSwap 智慧合約中存在致命的漏洞，這一漏洞可以使得使用者的資產在某些情況下被對手惡意吃單『偷盜』，PeckShield 安全人員獨立分析了該漏洞，並與AirSwap團隊溝通了細節和修復方案。
漏洞影響概述
PeckShield 安全人員深入分析 AirSwap 智慧合約後發現，這一漏洞只對最近上線的 Wrapper 有影響，AirSwap 團隊在發現該問題後第一時間下線當前合約，並將 AirSwap 網站回退到之前使用的合約，從合約上線到問題修復整個過程僅持續了 24小時，可見 AirSwap 團隊對於合約安全的重視程度之高。
PeckShield 安全人員獨立分析了漏洞細節，並與 AirSwap 團隊溝通細節和修復的方案， 同時將該漏洞命名為“ ItchySwap”。
PeckShield 在此提醒，由於這一漏洞可使使用者的資產被攻擊者惡意偷盜，受此次影響的賬號一共有 18 個，其中有部分賬號有數萬至數十萬美元的資產，這些賬號需要儘快完成升級，或與 AirSwap 團隊聯絡。
ItchySwap 漏洞詳解
一、AirSwap 合約
在分析之前，為方便起見，我們先定義幾個概念：
1. maker：出售資產的一方；
2. taker：購買資產的一方；
3. order: maker 與 taker 之間發生資產交割的訂單；
4. Indexer: AirSwap 中的訂單簿，匯聚了當前正在出售及需要購買的資產資訊。
下圖說明了maker、taker 和 Indexer 之間的互動流程：
AirSwap 是一個基於 Ethereum 的點對點去中心化交易所，它整合了 Swap Protocol ，在其中作為一個自動託管服務，允許交易的雙方（即 maker 和 taker）在以太坊上安全地交易任何資產。與許多去中心化交易所不同，AirSwap 雖然沒有對資金進行託管控制，但仍然有一個用於匹配目的的集中式訂單簿，它實現了一個用於交易和訂單匹配的完全對等模型。
特別值得一提的是，有一個名為 Indexer 的鏈下服務，可以聚合來自 maker 和 taker 的交易意圖，然後為他們提供匹配的服務。特別是，一旦 taker 找到了合適的 maker，他們就會開始進行場外價格的談判。一旦達成協議，訂單將由 Taker 透過 Swap Protocol 在鏈上進行填充和資產交割。
在 AirSwap 智慧合約中， taker 將訂單上鍊及資產交割的過程在 AirSwap swap(Types.Order calldata _order) 函式之中，這一函式實現如下所示：
1）驗證訂單有效性
訂單 order 引數有效性檢查，這些資訊均由 taker 上鍊的時候指定的，也意味著這些資訊都可以由 taker 篡改，具體包含：
1. 訂單還在有效期內；
2. 訂單還沒有被其它的 taker 吃單；
3. 訂單還沒有被取消；
4. 訂單的 nonce 大於最小值；
5. 設定訂單狀態為 TAKEN 狀態。
2）驗證 taker 資訊
確立有效的 taker，根據 order 中指定或者等同於合約的呼叫方 msg.sender。
3）驗證 maker 資訊
驗證 maker 的有效性，這裡的驗證分為兩種情況考慮：
1. 沒有 maker 簽名的訂單：需要保證 msg.sender 有許可權操作這個 maker 地址即可，即這筆 order 發起者有許可權操作 maker 的資產；
2. order 中指定了 maker 的簽名資訊：驗證簽名的有效性。
4） 資產交割
如果上述的驗證流程沒有問題，那麼直接執行 maker 和 taker 的資產交割。
二、Wrapper 合約
在上述的 AirSwap 合約中，使用者透過 swap() 函式執行資產互換，這一流程非常清晰，沒有問題。但是這一合約存在一點不完美的地方，使用者只能透過 Token 進行資產互換，無法直接用 ETH 平臺幣參與其中。使用者可以先把 ETH 轉換成 WETH, 再用 WETH 參與互換，但無論如何，使用者使用體驗上多了一步。
為了降低使用者使用體驗上的摩擦，AirSwap 團隊與 2019年09月12日 推出了 Wrapper 合約，其使用是自動將使用者轉入的 ETH 轉換成 WETH 之後再參與資產互換的過程，其關鍵流程如下：
1. 驗證 swap() 發起方與 taker 是相同的；
2. 如果使用者發起 swap() 有攜帶了 ETH 資產，並且需要轉換的 token 為 WETH, 那麼就自動將 ETH 轉換成 WETH；
3. 直接呼叫 AirSwap 合約的 swap() 操作。
考慮到一種特殊的場景，Alice 希望透過 Wrapper 合約執行 AirSwap 資產互換，這一過程需要先由 Alice 自行在 AirSwap 合約中授權 Wrapper 合約，以允許 Wrapper 合約可以執行各自的資產交割流程。
由於區塊鏈的透明性，Eve 看到了 Alice 的授權操作，那麼他就可以向 Wrapper 合約發起一筆惡意的訂單，其包含的內容如下：
1. order 中的有效時間、nonce 為一個非常大的數值；
2. order 中的 maker 對應的賬號為 Alice 的賬號；
3. order 中的 taker 為空；
4. order 的 signature 為空。
將上述構造好的 order 代入AirSwap 的 swap() 函式，其中 1，2 兩步的驗證由於是 taker 控制的，不會有問題，我們重點看下第三步驗證 maker 資訊：
由於此時 AirSwap 合約是由 Wrapper 合約呼叫的，那麼 msg.sender 即 Wrapper 合約的地址，前文講到，Wrapper 合約是經過 Alice 授權可直接控制 Alice 的資產，此時雖然 Eve 沒有許可權操作 Alice 的資產，但此時可以透過 Wrapper 控制，也就間接地控制了 Alice 的資產。
安全規避
PeckShield 安全人員分析發現，截止至 2019年09月28日為止，共有 6 個賬號執行了 revoke() 操作，以解除對 Wrapper 合約的授權，還有 12 個賬號存在安全風險，這剩下的所有賬號應當立即執行 revoke() 操作，或者將賬號中的資產轉移至未對 Wrapper 授權過的安全賬號。
任何的程式碼在上線生產環境之前都應當得到充分的測試和驗證，特別是承載著使用者價值的 DEX 平臺。在產品增加新特性之時，一定要考慮到舊特性的相容性與安全，新特性的引入不應該觸發舊產品中設計不完備的地方。
附錄
備註：AirSwap 官方漏洞細節（原文）連結：https://medium.com/fluidity/critical-vulnerability-in-a-new-airswap-smart-contract-c1204e04d7d3
