# 智能合约中的拒绝服务攻击分析拒绝服务攻击(DoS)可能导致智能合约在一段时间内甚至永久无法正常使用。主要原因包括:1. 合约逻辑中的缺陷,如某些公开函数的计算复杂度过高,导致Gas消耗超出限制。2. 跨合约调用时对外部合约执行状态的依赖,外部合约执行不可靠可能阻塞本合约的正常运行。3. 人为因素,如合约所有者丢失私钥导致某些特权函数无法调用。下面通过具体例子分析智能合约中的DoS攻击漏洞。## 1. 循环遍历可被外部修改的大型数据结构以下是一个用于给注册用户"分红"的简单合约:rust#[near_bindgen]#[derive(BorshDeserialize, BorshSerialize)]pub struct Contract { pub registered: Vec<accountid>, 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消耗超出限制。推荐解决方案:1. 限制self.registered数组的最大长度2. 采用提款模式,不主动遍历分发奖励,而是让用户自行调用提款函数## 2. 跨合约状态依赖导致合约阻塞 考虑一个"竞价"合约:rust#[near_bindgen]#[derive(BorshDeserialize, BorshSerialize)]pub struct Contract { pub registered: Vec<accountid>, 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<u128> { 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. 实现去中心化的合约治理方案</u128></accountid,balance></accountid></accountid,></accountid>
深度剖析智能合约中的DoS攻击漏洞及防范策略
智能合约中的拒绝服务攻击分析
拒绝服务攻击(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消耗超出限制。
推荐解决方案:
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'); } }; }
该合约的问题在于,如果当前出价最高用户的账户在外部代币合约中被注销,新的更高出价将无法退回前者代币,导致竞拍过程阻塞。
解决方法:
考虑外部合约调用可能失败的情况,实现合理的错误处理。例如将无法退回的代币暂存在合约中,后续允许用户自行提取。
3. 合约所有者私钥丢失
智能合约中往往存在只有所有者可执行的特权函数。如果所有者私钥丢失,这些函数将无法调用,可能导致合约无法正常运行。
解决方法: