深入解析智能合約中的拒絕服務攻擊

拒絕服務攻擊(DoS)可能導致智能合約暫時或永久無法正常使用。主要原因包括:

1. 合約邏輯存在缺陷。如某些公開函數未考慮計算復雜度,可能超出Gas上限導致交易失敗。

2. 跨合約調用中,合約執行依賴外部合約狀態。外部合約執行不可靠可能阻塞本合約運行,如用戶資金被鎖定無法充提。

3. 人爲因素,如合約所有者丟失私鑰,導致某些特權函數無法調用,重要系統狀態無法更新。

下面結合具體例子分析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限制導致交易失敗。

建議採用提款模式改造:不主動對所有用戶分紅,而是記帳並設置withdraw函數讓用戶自行提取獎勵。

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) }

#[private] pub fn account_resolve(&mut self, sender_id: AccountId, amount: u128) { match env::promise_result(0) { PromiseResult::NotReady => unreachable!(), PromiseResult::Successful(_) => { ext_ft_token::ft_transfer( self.current_leader.clone(), self.highest_bid, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, ); self.current_leader = sender_id; self.highest_bid = amount; } PromiseResult::Failed => { ext_ft_token::ft_transfer( sender_id.clone(), amount, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, ); log!("Return Back Now"); } }; }

該合約要求必須退回前一出價最高者代幣才能更新最高出價。若前者在外部合約注銷帳戶,將導致系統無法更新出價最高者。

建議增加錯誤處理機制,如將無法退回的代幣存入合約的lost_found帳戶,後續允許用戶提取。

3. Owner私鑰丟失

部分合約函數設置爲僅owner可執行,用於更改關鍵系統變量。當owner無法履職(如私鑰丟失)時,可能導致資金鎖定或交易暫停。

建議採用多籤機制替代單一owner權限控制,實現去中心化治理。

綜上所述,合約開發中應充分考慮各種潛在的DoS風險,採取相應的防範措施,確保合約長期穩定運行。

</accountid,balance></accountid,>