今日塊訊(www.cppcns.com) 7 月 11 日訊息7 月 9 日，「慢霧區」發布以太坊代幣「假充值」漏洞攻擊預警，今天慢霧安全團隊正式披露以太坊代幣「假充值」漏洞細節及修復方案。
根據慢霧區訊息，以太坊代幣「假充值」漏洞影響了相關中心化交易所、中心化錢包、代幣合約等，其中 3619 份代幣合約存在「假充值」漏洞風險。
根據其披露以太坊代幣「假充值」漏洞細節，攻擊者可以程式設計客棧利用存在缺陷的代幣合約向中心化交易所、錢包等服務平台發起充值操作，如果交易所誤判充幣成功，就可能程式設計客棧存在「假充值」漏洞。具體細節如下：
以程式設計客棧太坊代幣交易回執中 status 欄位是 0xjtfvlbif1(true) 還是 0x0(false)，取決於交易事務執行過程中是否丟擲了異常(比如使用了 require/assert/revert/throw 等機制)。當使用者呼叫代幣合約的 transfer 函式進行轉賬時，如果 transfer 函式正常執行未丟擲異常，該交易的 status 即是 0x1(true)。
如圖**，某些代幣合約的 transfer 函式對轉賬發起人(msg.sender)的餘額檢查用的是 if 判斷方式，當 balances[msg.sender] < _value 時進入 else 邏輯部分並 return falsejtfvlbif，最終沒有丟擲異常，我們認為僅 if/else 這種溫和的判斷方式在 transfer 這類敏感函式場景中是一種不嚴謹的編碼方式。而大多數代幣合約的 transfer 函式會採用 require/assert 方式，如圖：
當不滿足條件時會直接丟擲異常，中斷合約後續指令的執行，或者也可以使用 eip 20 推薦的 if/else + revert/throw 函式組合機制來顯現丟擲異常，如圖：
我們很難要求所有程式設計師都能寫出最佳安全實踐的**，這種不嚴謹的編碼方式是一種安全缺陷，這種安全缺陷可能會導致特殊場景下的安全問題。攻擊者可以利用存在該缺陷的代幣合約向中心化交易所、錢包等服務平台發起充值操作，如果交易所僅判斷如 txreceipt status 是 success(即上文提的 status 為 0x1(true) 的情況) 就以為充幣成功，就可能存在「假充值」漏洞。如圖：
此外，慢霧區還公布了修復方案，內容如下
除了判斷交易事務 success 之外，還應二次判斷充值錢包位址的 balance 是否準確的增加。其實這個二次判斷可以通過 event 事件日誌來進行，很多中心化交易所、錢包等服務平台會通過 event 事件日誌來獲取轉賬額度，以此判斷轉賬的準確性。但這裡就需要特別注意合約作惡情況，因為 event 是可以任意編寫的，不是強制預設不可篡改的選項：
emit transfer(from， to， value); // value 等引數可以任意定義
作為平台方，在對接新上線的代幣合約之前，應該做好嚴格的安全審計，這種安全審計必須強制代幣合約方執行最佳安全實踐。
作為代幣合約方，在編碼上，應該嚴格執行最佳安全實踐，並請第三方職業安全審計機構完成嚴謹完備的安全審計。
本文標題: 慢霧區披露以太坊代幣「假充值」漏洞細節和修復方案
本文位址:
慢霧出品 EOS超級節點安全執行指南
安全加固方案 致謝保護出塊伺服器正常通訊與執行 增強初始主網整體抗攻擊能力 保護節點安全 對初始狀態主網進行 ddos rpc 功能濫用 通訊故障 bp 伺服器隔離 多跳轉節點 小節點流量 大節點高防護 多鏈路高可用 預設關閉 rpc。必須開啟時,混淆埠,並架設高防等保護 bp 通訊多鏈路設計 架構...
FileWriter為什麼有緩衝區還是慢
緩衝和非緩衝的區別我就不想說了，除了什麼緩衝比較快用車子拖和你乙個人搬，下面是我研究的一些i問題 在使用filewriter時，證明 非緩衝流也有緩衝區，在單個位元組讀取時，m2緩衝m1非緩衝 相同的輸出流，in是緩衝流，in1是非緩衝 m2 in,f1 m1 in1,f1 相同的輸出流，顯然m2一...
20180717 區塊鏈相關學習 以太坊錢包
重置以太坊私有鏈的方法 1.刪除根目錄下隱藏的檔案.ethash，在mac系統中該資料夾 下 2.刪除以太坊私有鏈下面的geth keystore兩個資料夾 當前區塊數 在以太坊的底層眼中，智慧型合約也是部署在以太坊條鏈上乙個特殊賬戶，因此對智慧型合約的呼叫，也就是對智慧型合約賬戶的一次send t...