🎉 親愛的廣場小夥伴們,福利不停,精彩不斷!目前廣場上這些熱門發帖贏獎活動火熱進行中,發帖越多,獎勵越多,快來 GET 你的專屬好禮吧!🚀
🆘 #Gate 2025年中社区盛典# |廣場十強內容達人評選
決戰時刻到!距離【2025年中社區盛典】廣場達人評選只剩 1 天,你喜愛的達人,就差你這一票衝進 C 位!在廣場發帖、點讚、評論就能攢助力值,幫 Ta 上榜的同時,你自己還能抽大獎!iPhone 16 Pro Max、金牛雕塑、潮流套裝、合約體驗券 等你抱走!
詳情 👉 https://www.gate.com/activities/community-vote
1️⃣ #晒出我的Alpha积分# |曬出 Alpha 積分&收益
Alpha 積分黨集合!帶話題曬出你的 Alpha 積分圖、空投中獎圖,即可瓜分 $200 Alpha 代幣盲盒,積分最高直接抱走 $100!分享攢分祕籍 / 兌換經驗,中獎率直線上升!
詳情 👉 https://www.gate.com/post/status/12763074
2️⃣ #ETH百万矿王争霸赛# |ETH 鏈上挖礦曬收益
礦工集結!帶話題曬出你的 Gate ETH 鏈上挖礦收益圖,瓜分 $400 曬圖獎池,收益榜第一獨享 $200!誰才是真 ETH 礦王?開曬見分曉!
詳情 👉 https://www.gate.com/pos
智能合約DoS攻擊分析:案例解讀及防御策略
Rust智能合約中的拒絕服務攻擊
拒絕服務攻擊(DoS)會使智能合約在一段時間內甚至永久無法正常使用。主要原因包括:
合約邏輯存在計算復雜度高的缺陷,導致Gas消耗超出限制。
跨合約調用時,合約執行依賴外部不可靠合約,造成阻塞。
合約所有者丟失私鑰,無法執行特權函數更新重要狀態。
下面通過具體例子分析DoS攻擊漏洞。
1. 遍歷外部可控的大型數據結構
以下是一個給用戶"分紅"的簡單合約:
rust #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub registered: Vec, pub accounts: UnorderedMap<accountid, balance="">, }
pub fn register_account(&mut self) { if self.accounts.insert(&env::predecessor_account_id(), &0).is_some() { env::panic("The account is already registered".to_string().as_bytes()); } else { self.registered.push(env::predecessor_account_id()); }
log!("Registered account {}", env::predecessor_account_id()); }
pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::predecessor_account_id(), DISTRIBUTOR, "ERR_NOT_ALLOWED"); for cur_account in self.registered.iter() { let balance = self.accounts.get(&cur_account).expect("ERR_GET"); self.accounts.insert(&cur_account, &balance.checked_add(amount).expect("ERR_ADD")); log!("Try distribute to account {}", &cur_account); ext_ft_token::ft_transfer( cur_account.clone(), amount, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL ); } }
這裏self.registered大小無限制,可被惡意用戶操控變得過大,導致distribute_token執行時Gas費用超出限制。
解決方案:不建議遍歷外部可控的大型數據結構。可採用withdrawal模式,讓用戶自行取回"分紅"。
2. 跨合約狀態依賴導致阻塞
考慮一個"競價"合約:
rust #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub registered: Vec, pub bid_price: UnorderedMap<accountid,balance>, pub current_leader: AccountId, pub highest_bid: u128, pub refund: bool }
pub fn bid(&mut self, sender_id: AccountId, amount: u128) -> PromiseOrValue { assert!(amount > self.highest_bid); if self.current_leader == DEFAULT_ACCOUNT { self.current_leader = sender_id; self.highest_bid = amount; } else { ext_ft_token::account_exist( self.current_leader.clone(), &FTTOKEN, 0, env::prepaid_gas() - GAS_FOR_SINGLE_CALL * 4, ).then(ext_self::account_resolve( sender_id, amount, &env::current_account_id(), 0, GAS_FOR_SINGLE_CALL * 3, )); } log!( "current_leader: {} highest_bid: {}", self.current_leader, self.highest_bid ); PromiseOrValue::Value(0) }
這裏退回前一個最高出價者的代幣是更新狀態的前提。如果該用戶帳戶已注銷,將導致整個競拍過程阻塞。
解決方法:考慮外部調用可能失敗,增加錯誤處理。可將無法退回的代幣暫存,後續允許用戶自行提取。
3. 所有者私鑰丟失
部分關鍵函數設置爲僅所有者可執行。所有者無法履職時(如私鑰丟失),將導致合約無法正常運行。
解決方法:設置多個所有者共同治理,或採用多籤請求替代單一所有者控制,實現去中心化治理。