# Rustスマートコントラクト中的サービス拒否攻撃サービス拒否攻撃(DoS)は、スマートコントラクトが一定期間、さらには永久に正常に使用できなくなる原因となります。主な原因は以下の通りです:1. コントラクトのロジックには計算の複雑さに関する欠陥があり、Gas消費が制限を超えています。2. クロスコントラクト呼び出し時、コントラクトの実行は外部の信頼できないコントラクトに依存し、ブロックを引き起こす。3. コントラクトの所有者が秘密鍵を失い、特権関数を実行して重要な状態を更新できません。以下の具体的な例を通じてサービス拒否攻撃の脆弱性を分析します。## 1. 外部から制御可能な大規模データ構造を遍歴する以下はユーザーに「分配金」を与えるシンプルなスマートコントラクトです:錆#[near_bindgen]#[derive(BorshDeserialize、BorshSerialize)]pub struct コントラクト { パブ登録:Vec<accountid>、 パブアカウント: UnorderedMap<accountid, balance="">,}pub fn register_account(&mut self) { self.accounts.insert(&env::p redecessor_account_id()、&0).is_の場合 some() { env::panic("アカウントはすでに登録されています".to_string().as_bytes()); } else { self.registered.push(env::p redecessor_account_id()); } log!("登録済みアカウント {}", env::p redecessor_account_id());}pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::p redecessor_account_id(), ディストリビューター, "ERR_NOT_ALLOWED"); for cur_account in self.registered.iter() { バランス= self.accounts.get(&cur_account).expect("ERR_GET"); self.accounts.insert(&cur_account, &balance.checked_add(amount).expect("ERR_ADD" )); log!("アカウント {} に配布を試みる", &cur_account); ext_ft_token::ft_transfer( cur_account.clone()、 量 &FTTOKENや 0, GAS_FOR_SINGLE_CALL ); }}ここではself.registeredのサイズに制限がなく、悪意のあるユーザーによって過度に大きくなる可能性があり、その結果、distribute_tokenを実行する際にGas料金が制限を超えることになります。解決策:外部で制御可能な大規模データ構造を遍歴することはお勧めしません。withdrawalモードを採用し、ユーザーが自分で"分配金"を取り戻すことができます。! [](https://img-cdn.gateio.im/social/moments-b7bbfcf4423b1cf19db56a3af95a7486)## 2. コントラクト間の状態依存によるブロック"入札"契約を考えてみてください:錆#[near_bindgen]#[derive(BorshDeserialize、BorshSerialize)]pub struct コントラクト { パブ登録:Vec<accountid>、 pub bid_price: UnorderedMap<accountid,balance>, 公開current_leader: AccountId, パブhighest_bid:U128、 パブの払い戻し:ブール}pub fn bid(&mut self, sender_id: AccountId, amount: u128) -> PromiseOrValue<u128> { アサート!(amount > self.highest_bid); if self.current_leader == DEFAULT_ACCOUNT { self.current_leader = sender_id; self.highest_bid = 金額; } else { ext_ft_token::account_exist( self.current_leader.clone()、 &FTTOKENや 0, env::p repaid_gas() - GAS_FOR_SINGLE_CALL * 4、 ).then(ext_self::account_resolve( sender_id、 量 &env::current_account_id()、 0, GAS_FOR_SINGLE_CALL*3、 )); } ログ!( "current_leader: {} highest_bid: {}", self.current_leader、 self.highest_bid ); PromiseOrValue::Value(0)}ここで前の最高入札者のトークンを返却することは、状態を更新するための前提条件です。このユーザーアカウントが無効になっている場合、オークションプロセス全体がブロックされます。解決策:外部呼び出しが失敗する可能性を考慮し、エラー処理を追加します。返却できないトークンを一時保管し、その後ユーザーが自分で引き出すことを許可します。## 3. 所有者の秘密鍵を紛失した一部の重要な関数は所有者のみが実行できるように設定されています。所有者が職務を果たせない場合(、例えば秘密鍵が失われた)場合、コントラクトは正常に実行されなくなります。解決策: 複数の所有者による共同ガバナンスを設定するか、単一の所有者による制御の代わりにマルチシグ要求を採用し、分散型ガバナンスを実現する。! [](https://img-cdn.gateio.im/social/moments-7076cf1226a2276d1e4cd994d259841f)</u128></accountid,balance></accountid></accountid,></accountid>
スマートコントラクトDoS攻撃分析:ケース解読と防御戦略
Rustスマートコントラクト中的サービス拒否攻撃
サービス拒否攻撃(DoS)は、スマートコントラクトが一定期間、さらには永久に正常に使用できなくなる原因となります。主な原因は以下の通りです:
コントラクトのロジックには計算の複雑さに関する欠陥があり、Gas消費が制限を超えています。
クロスコントラクト呼び出し時、コントラクトの実行は外部の信頼できないコントラクトに依存し、ブロックを引き起こす。
コントラクトの所有者が秘密鍵を失い、特権関数を実行して重要な状態を更新できません。
以下の具体的な例を通じてサービス拒否攻撃の脆弱性を分析します。
1. 外部から制御可能な大規模データ構造を遍歴する
以下はユーザーに「分配金」を与えるシンプルなスマートコントラクトです:
錆 #[near_bindgen] #[derive(BorshDeserialize、BorshSerialize)] pub struct コントラクト { パブ登録:Vec、 パブアカウント: UnorderedMap<accountid, balance="">, }
pub fn register_account(&mut self) { self.accounts.insert(&env::p redecessor_account_id()、&0).is_の場合 some() { env::panic("アカウントはすでに登録されています".to_string().as_bytes()); } else { self.registered.push(env::p redecessor_account_id()); }
log!("登録済みアカウント {}", env::p redecessor_account_id()); }
pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::p redecessor_account_id(), ディストリビューター, "ERR_NOT_ALLOWED"); for cur_account in self.registered.iter() { バランス= self.accounts.get(&cur_account).expect("ERR_GET"); self.accounts.insert(&cur_account, &balance.checked_add(amount).expect("ERR_ADD" )); log!("アカウント {} に配布を試みる", &cur_account); ext_ft_token::ft_transfer( cur_account.clone()、 量 &FTTOKENや 0, GAS_FOR_SINGLE_CALL ); } }
ここではself.registeredのサイズに制限がなく、悪意のあるユーザーによって過度に大きくなる可能性があり、その結果、distribute_tokenを実行する際にGas料金が制限を超えることになります。
解決策:外部で制御可能な大規模データ構造を遍歴することはお勧めしません。withdrawalモードを採用し、ユーザーが自分で"分配金"を取り戻すことができます。
!
2. コントラクト間の状態依存によるブロック
"入札"契約を考えてみてください:
錆 #[near_bindgen] #[derive(BorshDeserialize、BorshSerialize)] pub struct コントラクト { パブ登録:Vec、 pub bid_price: UnorderedMap<accountid,balance>, 公開current_leader: AccountId, パブhighest_bid:U128、 パブの払い戻し:ブール }
pub fn bid(&mut self, sender_id: AccountId, amount: u128) -> PromiseOrValue { アサート!(amount > self.highest_bid); if self.current_leader == DEFAULT_ACCOUNT { self.current_leader = sender_id; self.highest_bid = 金額; } else { ext_ft_token::account_exist( self.current_leader.clone()、 &FTTOKENや 0, env::p repaid_gas() - GAS_FOR_SINGLE_CALL * 4、 ).then(ext_self::account_resolve( sender_id、 量 &env::current_account_id()、 0, GAS_FOR_SINGLE_CALL*3、 )); } ログ!( "current_leader: {} highest_bid: {}", self.current_leader、 self.highest_bid ); PromiseOrValue::Value(0) }
ここで前の最高入札者のトークンを返却することは、状態を更新するための前提条件です。このユーザーアカウントが無効になっている場合、オークションプロセス全体がブロックされます。
解決策:外部呼び出しが失敗する可能性を考慮し、エラー処理を追加します。返却できないトークンを一時保管し、その後ユーザーが自分で引き出すことを許可します。
3. 所有者の秘密鍵を紛失した
一部の重要な関数は所有者のみが実行できるように設定されています。所有者が職務を果たせない場合(、例えば秘密鍵が失われた)場合、コントラクトは正常に実行されなくなります。
解決策: 複数の所有者による共同ガバナンスを設定するか、単一の所有者による制御の代わりにマルチシグ要求を採用し、分散型ガバナンスを実現する。
! </accountid,balance></accountid,>