Rust智能合約養成日記：拒絕服務攻擊防範

拒絕服務(DoS)攻擊可能會導致智能合約在一段時間內甚至永久無法正常使用。常見原因包括:

1. 合約邏輯中的計算復雜度問題,導致 Gas 消耗超出限制。

2. 跨合約調用時,對外部合約執行狀態的不當依賴,造成本合約被阻塞。

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

下面通過幾個具體例子來分析 DoS 攻擊漏洞及其解決方案。

1. 循環遍歷可被外部更改的大型數據結構

以下是一個簡單的"分紅"合約,存在 DoS 風險:

rust #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub registered: Vec, pub accounts: UnorderedMap<accountid, balance="">, }

impl Contract { 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
        );
    }
}

}

問題在於 registered 數組大小沒有限制,可被惡意用戶操控變得過大,導致 distribute_token 函數執行時 Gas 消耗超出限制。

建議解決方案:

1. 限制 registered 數組的大小。

2. 採用"提現"模式,讓用戶自行提取獎勵,而不是合約主動分發。

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 }

impl Contract { 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");
        }
    };
}

}

問題在於合約狀態更新依賴外部合約調用。如果前一個最高出價者的帳戶已注銷,後續出價者將無法更新狀態。

建議解決方案:

考慮外部調用可能失敗的情況,實現合理的錯誤處理機制。例如,將無法退回的代幣暫存在合約中,後續允許用戶主動提取。

3. 所有者私鑰丟失

許多合約存在僅所有者可執行的特權函數。如果所有者私鑰丟失,這些函數將無法調用,可能導致合約無法正常運作。

建議解決方案:

1. 設置多個合約所有者共同管理。

2. 採用多重籤名機制來替代單一所有者控制。

3. 實現去中心化的合約治理機制。

通過以上措施,可以有效降低智能合約中拒絕服務攻擊的風險,提高合約的安全性和可靠性。

</accountid,balance></accountid,>