追回詐騙集團USDT,請聯絡我們!
TON(The Open Network) 是一個由 Telegram 團隊最初設計和開發的去中心化區塊鏈平臺,一經上線就獲得了關註。TON 的目標是提供一個高性能和可擴展的區塊鏈平臺,以支援大規模的去中心化應用(DApps) 和智能契約,關於 TON 的基礎知識可查閱初識 TON:賬號、Token、交易與資產安全。
值得註意的是,TON 與其他區塊鏈有著截然不同的架構,TON 的智能契約除了主要使用 FunC 語言來編程,也有使用更高級的 Tact,或者更底層的 Fift。這些都是原創程度很高的語言,因此,確保智能契約的安全性很關鍵。
Hackgo安全團隊整合吸收了 TON 社區分享的安全開發實踐,併結合自身多年積纍的安全審計經驗,PO「Toncoin 智能契約安全最佳實踐」,旨在幫助開發者更好地理解 Toncoin 智能契約的安全風險,併提供實用的解決方案,以降低潛在的安全威脅。
由於篇幅限制,本文僅羅列「Toncoin 智能契約安全最佳實踐」的部分內容,歡迎大家在 GitHub 上 Watch、Fork 及 Star:https://github.com/slowmist/Toncoin-Smart-Contract-Security-Best-Practices。
Toncoin 智能契約常見陷阱
1. 缺少 impure 修飾符
嚴重性:高
描述:攻擊者可能會發現 "authorize" 函數未標記為 "impure"。缺少此修飾符將允許編譯器在函數沒有返回值或返回值未使用時跳過該函數的調用。
攻擊場景:

建議:確保函數使用 "impure" 修飾符。
2. 錯誤使用修改/非修改方法
嚴重性:高
描述:"udict_delete_get?" 被錯誤地用 "." 而不是 "~" 調用,因此實際的字典未被修改。
攻擊場景:

建議:始終檢查方法是否為修改/非修改方法。
3. 錯誤使用有符號/無符號整數
嚴重性:高
描述:投票權被以整數形式存儲在消息中。因此攻擊者可以在權力轉移期間發送負值併獲得無限投票權。
攻擊場景:

建議:在一些場景下,無符號整數更安全,因為它們在發生溢出時會拋出錯誤。僅在確實需要時使用有符號整數。
4. 不安全的隨機數
嚴重性:高
描述:種子來源於交易的邏輯時間,攻擊者可以通過暴力破解當前區塊中的邏輯時間來獲勝(因為邏輯時間在一個區塊的邊界內是連續的)。
攻擊場景:

建議:在進行 "rand()" 之前始終隨機化種子,最好是永遠不要使用鏈上隨機數,因為驗證者可以控制或影響種子。
5. 在鏈上發送私人數據
嚴重性:高
描述:請記住,所有數據都會被存儲在區塊鏈上。
攻擊場景:錢包受密碼保護,其哈希值被存儲在契約數據中。然而,區塊鏈會記錄一切 —— 密碼會出現在交易歴史中。
建議:不要在鏈上發送私人數據。
6. 漏掉對退回消息的檢查
嚴重性:高
描述:用戶發送 "check" 請求時,Vault 沒有退回處理程式或代理消息至數據庫。我們可以在數據庫中將 "msg_addr_none" 設定為獎勵地址,因為 "load_msg_address" 允許這樣做。我們請求 Vault 檢查,數據庫嘗試使用 "parse_std_addr" 解析 "msg_addr_none",但解析失敗。消息從數據庫退回到 Vault,且操作不是 "op_not_winner"。
攻擊場景:Vault 在數據庫消息處理器中包含以下代碼:

建議:始終檢查退回的消息,不要忘記標准函數引起的錯誤,使您的條件盡可能嚴格。
7. 在競爭條件下銷毀賬戶的風險
嚴重性:高
描述:不要輕易銷毀賬戶。
攻擊場景:妳可以存錢,然後嘗試在併發消息中兩次提款。由於無法保證保留資金的消息會被處理,因此契約賬號可以在第二次提款後關閉。攻擊者之後可以重新部署契約,然後任何人都可以提取未擁有的資金。

建議:使用 "raw_reserve" 而不是嚮自己發送資金。考慮可能的競爭條件。小心使用 hashmap 的氣體消耗。
8. 避免執行第三方代碼
嚴重性:高
描述:開發者沒有辦法在契約中安全地執行第三方代碼,因為 CATCH 不能處理 gas 不足的問題,而攻擊者只需提交契約的任何狀態併引發氣體不足即可實現攻擊。
攻擊場景:

建議:避免在您的契約中執行第三方代碼。
9. 名稱沖突
嚴重性:中
描述:Func 變數和函數可能包含幾乎任何合法字符。
攻擊場景:"var++"、"~bits"、"foo-bar+baz" 及逗號 "," 都是有效的變數和函數名稱。
建議:編寫和檢查 Func 代碼時,應該使用 Linter 工具。
10. 檢查 throw 的值
嚴重性:中
描述:每次 TVM 執行正常停止時,它會以退出代碼 "0" 或 "1" 停止。雖然它是自動完成的,但如果 "throw(0)" 或 "throw(1)" 命令直接拋出退出代碼 "0" 和 "1",TVM 執行可以在意外方式下直接中斷。
攻擊
建議:不要使用 "0" 或 "1" 作為 throw 的值。
11. 讀/寫正確類型數據
嚴重性:中
描述:讀取意外變數的值,併在不應有此類方法的數據類型上調用方法(或者其返回值未正確存儲)是錯誤的,不會作為“警告”或“通知”被跳過,而是導致無法取到代碼。
攻擊場景:請記住,存儲意外值可能是可以的,但是讀取它可能會導致問題。例如,對於整數變數,錯誤代碼 5(整數超出預期範圍)可能被拋出。
建議:密切跟蹤代碼的操作和它可能的返回值。請記住,編譯器僅關心代碼及其初始狀態。
12. 契約代碼可以更新
嚴重性:中
描述:TON 完全實現了 Actor 模型,這意味著契約的代碼可以更改。代碼可以通過 "SETCODE" TVM 指令永久更改,或者在運行時設定 TVM 代碼寄存器為新的單元值,直到執行結束。
攻擊場景:不道德的開發者可能會惡意更新代碼以竊取資金。
建議:註意契約代碼是可以更新的,確保任何更新都遵循安全實踐,併使用例如治理模型或多簽名批准等機制進行更改。
13. 交易和階段
嚴重性:中
描述:計算階段執行智能契約代碼,然後執行操作(如發送消息、修改代碼、更改庫等)。與基於以太坊的區塊鏈不同,如果妳預計發送的消息會失敗,妳將看不到計算階段的退出代碼,因為消息併不是在計算階段執行的,而是在稍後的操作階段執行。
攻擊場景:在操作階段消息失敗時產生意外行為,導致對交易狀態的錯誤假設。
建議:了解每個交易最多包含五個階段:存儲階段、信用階段、計算階段、操作階段和反彈階段。
14. 不能從其他契約中拉取數據
嚴重性:中
描述:區塊鏈上的契約可以駐留在不同的分片上,併由不同的驗證者處理。因此,開發者無法按需從其他契約中拉取數據。通信是異步的,通過發送消息進行。
攻擊場景:
建議:圍繞異步消息設計契約邏輯,避免對同步數據可用性的假設。
15. 兩個預定義的 method_id
嚴重性:中
描述:有兩個預定義的 method_id:一個用於接收區塊鏈內的消息 "(0)",通常命名為 "recv_internal",另一個用於接收來自外部的消息 "(-1)",命名為 "recv_external"。
攻擊場景:
建議:使用如 "force_chain(to_address)" 的方法來驗證地址是否在正確的鏈上。
16. 使用可反彈消息
嚴重性:高
描述:TON 區塊鏈是異步的,消息不必按順序到達。失敗的消息應得到正確處理。
攻擊場景:

建議:始終使用可反彈消息("0x18")來正確處理消息失敗。
17. 重放保護
嚴重性:高
描述:為錢包(存儲用戶資金的契約)實現重放保護,可以使用序列號("seqno")來確保消息不被重復處理,或使用帶有到期的唯一交易標識符。
攻擊場景:

建議:使用類似序列號或消息唯一標識符的重放保護方法,以防止重放攻擊。
18. 消息的競態條件
嚴重性:高
描述:消息級聯可以跨多個區塊處理,攻擊者可能會啟動一個併行流,從而導致競態條件。
攻擊場景:攻擊者可能會利用時間差異操縱契約行為。
建議:通過在每個步驟驗證狀態併不假設消息流中的狀態一致性來預防競態條件。
19. 使用攜帶值模式
嚴重性:高
描述:在代幣轉賬(例如 TON Jetton)中,余額應使用攜帶值模式進行轉賬。發送方扣減余額,接收方將其加回或反彈回去。
攻擊場景:如果處理不當,Jetton 余額可能被操縱。
建議:使用攜帶值模式以確保正確的值轉移。
20. 小心退還多余的燃料費
嚴重性:高
描述:如果未將多余的燃料費退還給發送者,資金可能會隨著時間的推移在契約中積纍。原則上,這併不可怕,但這是一種次優的做法。可以添加一個功能來清除多余的費用,但像 TON Jetton 這樣的流行契約仍然會嚮發送者返回多余的費用消息 "op::excesses"。
21. 檢查函數返回值
嚴重性:高
描述:函數總是會返回值或錯誤,如果忽略對返回值的檢查,可能會導致邏輯上的致命錯誤。
攻擊場景:
建議:始終檢查函數的返回值。
22. 檢查假冒的 Jetton 代幣
嚴重性:高
描述:Jetton 代幣由兩部分組成:"jetton-minter" 和 "jetton-wallet"。如果保險庫契約沒有正確驗證,攻擊者可能會通過存入假代幣併提取有價值的代幣來耗盡保險庫中的資金。
攻擊場景:
建議:通過計算用戶的 jetton 錢包地址,檢查發送者是否發送了假冒的 Jetton 代幣。
寫在最後
對開發者而言,遵循這些最佳實踐,可以有效提升智能契約的安全性,減少潛在的安全風險。在區塊鏈技術日新月異的今天,安全永遠是重中之重。希望這一最佳實踐可以幫助更多的開發者打造安全可靠的智能契約,推動區塊鏈技術的健康發展。Hackgo駭客團隊專業追回被騙USDT,請聯絡我們!