Serangan penolakan layanan dalam kontrak pintar Rust

denial-of-service attack(DoS) dapat membuat smart contract tidak dapat digunakan dengan normal untuk jangka waktu tertentu bahkan secara permanen. Alasan utamanya termasuk:

1. Logika kontrak memiliki cacat dengan kompleksitas perhitungan yang tinggi, menyebabkan konsumsi Gas melebihi batas.

2. Saat memanggil kontrak lintas, pelaksanaan kontrak tergantung pada kontrak eksternal yang tidak dapat diandalkan, menyebabkan terhambat.

3. Pemilik kontrak kehilangan kunci pribadi, tidak dapat menjalankan fungsi privilese untuk memperbarui status penting.

Berikut adalah analisis kerentanan serangan denial-of-service (DoS) melalui contoh konkret.

1. Menelusuri struktur data besar yang dapat dikendalikan dari luar

Berikut adalah kontrak sederhana untuk memberikan "dividen" kepada pengguna:

karat #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub terdaftar: Vec, pub accounts: UnorderedMap\u003caccountid, balance=""\u003e, }

pub fn register_account(&mut self) { jika self.accounts.insert(&env::predecessor_account_id(), &0).is_some() { env::panic("Akun sudah terdaftar".to_string().as_bytes()); } else { self.registered.push(env::predecessor_account_id()); }
log!("Akun terdaftar {}", env::predecessor_account_id()); }

pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::predecessor_account_id(), DISTRIBUTOR, "ERR_NOT_ALLOWED"); untuk cur_account di self.registered.iter() { let balance = self.accounts.get(&cur_account).expect("ERR_GET"); self.accounts.insert(\u0026cur_account, \u0026balance.checked_add(amount).expect("ERR_ADD")); log!("Coba distribusikan ke akun {}", &cur_account); ext_ft_token::ft_transfer( cur_account.clone(), jumlah, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL ); } }

Di sini, ukuran self.registered tidak terbatas, dapat dikendalikan oleh pengguna jahat menjadi terlalu besar, menyebabkan biaya Gas saat mengeksekusi distribute_token melebihi batas.

Solusi: Tidak disarankan untuk menjelajahi struktur data besar yang dapat dikendalikan dari luar. Dapat menggunakan mode penarikan, membiarkan pengguna mengambil kembali "dividen".

2. Ketergantungan Status Antar Kontrak Mengakibatkan Terblokir

Pertimbangkan sebuah kontrak "tender:"

karat #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub terdaftar: Vec, pub bid_price: UnorderedMap\u003caccountid,balance\u003e, pub current_leader: AccountId, pub highest_bid: u128, pub refund: bool }

PromiseOrValue { assert!(jumlah > self.highest_bid); jika 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, jumlah, &env::current_account_id((, 0, GAS_FOR_SINGLE_CALL * 3, (); } log!) "pemimpin_saat_ini: {} tawaran_tertinggi: {}", self.current_leader, self.highest_bid ); PromiseOrValue::Value(0) }

Di sini, mengembalikan token kepada penawar tertinggi sebelumnya adalah syarat untuk memperbarui status. Jika akun pengguna tersebut telah dibatalkan, itu akan menyebabkan seluruh proses lelang terhambat.

Solusi: Pertimbangkan kemungkinan kegagalan panggilan eksternal, tambah penanganan kesalahan. Token yang tidak dapat dikembalikan dapat disimpan sementara, kemudian memungkinkan pengguna untuk menariknya sendiri.

3. Kunci pribadi pemilik hilang

Beberapa fungsi kunci diatur agar hanya dapat dijalankan oleh pemilik. Jika pemilik tidak dapat menjalankan tugasnya, ( seperti kehilangan kunci pribadi ), akan menyebabkan kontrak tidak dapat berfungsi dengan baik.

Solusi: mengatur beberapa pemilik untuk pemerintahan bersama, atau menggunakan permintaan multi-tanda tangan sebagai pengganti kontrol pemilik tunggal, untuk mencapai pemerintahan terdesentralisasi.

</accountid,balance></accountid,>