Rust智能合約中的DoS攻擊漏洞分析

DoS (Denial of Service)攻擊會導致智能合約在一段時間內甚至永久無法被正常使用。主要原因包括:

1. 合約邏輯中存在缺陷。如某些public函數實現未考慮計算復雜度,導致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)

}

該合約邏輯依賴退回前一出價最高者代幣才能更新新的最高出價。如果前者帳戶已注銷,新的出價將被阻塞。

解決方法:考慮外部調用可能失敗的情況,增加錯誤處理。可將無法退回的代幣暫存,之後用戶自行提取。

3. Owner私鑰丟失

部分合約函數被設置爲僅owner可執行,用於更改關鍵系統變量。如果owner無法履行職能(如私鑰丟失),這些功能將無法使用,可能導致合約癱瘓。

解決方法:

• 設置多個owner共同治理
• 採用多籤方案替代單一owner權限控制
• 實現去中心化治理機制

合理的權限設計和治理機制可以有效降低單點故障風險,提高合約的魯棒性。

</accountid,balance></accountid,>