У цій статті буде розглянуто питання контролю доступу в смартконтрактах Rust з двох точок зору:
Видимість доступу/виклику методів (функцій) контракту
Контроль доступу до функцій привілейованого доступу/розподіл повноважень
1. Видимість функцій (методів) контракту
При написанні смартконтрактів, вказуючи видимість функцій контракту, можна контролювати права доступу до функцій. Це дуже важливо для захисту ключових частин контракту від випадкового доступу або маніпуляцій.
Як приклад біржі Bancor Network, 18 червня 2020 року сталася безпекова подія через неправильне налаштування контролю доступу до ключових функцій смартконтракту. Цей контракт був написаний мовою Solidity, а видимість функцій поділяється на public/external та private/internal.
Bancor під час виправлення вразливості безпеки помилково налаштував частину критичних функцій переказу на властивість public, що дозволило будь-кому ззовні контракту викликати ці функції для виконання переказів, що поставило під серйозний ризик активи користувачів на суму 590 000 доларів.
!
У Rust смартконтрактах контроль видимості функцій так само важливий. Контрактні функції, позначені макросом #[near_bindgen], визначеним NEAR SDK, мають такі видимі властивості:
pub fn: публічна функція, що є частиною інтерфейсу смартконтракту, може бути викликана ззовні контракту.
fn: Функція без вказаного pub може бути викликана лише всередині контракту.
pub(crate) fn: обмеження на виклик у межах crate.
Інший спосіб встановити метод як internal — це визначити його в кодовому блоці impl Contract, який не модифікований #[near_bindgen].
Для функцій зворотного виклику їх необхідно встановити як публічні властивості, щоб їх можна було викликати через виклик функції. Також потрібно впевнитися, що функція зворотного виклику може бути викликана лише самим контрактом, для цього можна використовувати макрос #[private].
!
2. Контроль доступу до функцій з привілеями(механізм білого списку)
Окрім видимості функцій, також необхідно з семантичного рівня встановити повноцінний механізм контролю доступу з білого списку. Деякі привілейовані функції (такі як ініціалізація контракту, запуск/призупинення, єдиний переказ тощо) можуть бути викликані тільки власником контракту (owner).
Можна реалізувати власні Trait для контролю доступу до привілейованих функцій, перевіряючи, чи є викликачем транзакції власник контракту:
На основі цього принципу можна налаштувати декілька користувачів або кілька білого списку за допомогою налаштованих більш складних trait для реалізації детального контролю доступу до груп.
!
3. Більше методів контролю доступу
Інші методи контролю доступу в смартконтрактах Rust також включають:
Контроль часу виклику смартконтракту
Механізм багатопідпису для викликів функцій смартконтрактів
Управління(DAO) реалізація
Ці матеріали будуть детально представлені в наступній серії щоденників розвитку смартконтрактів.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
9 лайків
Нагородити
9
3
Поділіться
Прокоментувати
0/400
SigmaBrain
· 17год тому
Дійсно, уроки Bancor залишили глибокий слід.
Переглянути оригіналвідповісти на0
NewPumpamentals
· 18год тому
Знову говорять про контроль доступу, чому не навчаються на уроках Bancor?
Контроль доступу до смартконтрактів Rust: видимість функцій та управління привілейованим доступом
Rust смартконтракти养成日记(7)合约安全之权限控制
У цій статті буде розглянуто питання контролю доступу в смартконтрактах Rust з двох точок зору:
1. Видимість функцій (методів) контракту
При написанні смартконтрактів, вказуючи видимість функцій контракту, можна контролювати права доступу до функцій. Це дуже важливо для захисту ключових частин контракту від випадкового доступу або маніпуляцій.
Як приклад біржі Bancor Network, 18 червня 2020 року сталася безпекова подія через неправильне налаштування контролю доступу до ключових функцій смартконтракту. Цей контракт був написаний мовою Solidity, а видимість функцій поділяється на public/external та private/internal.
Bancor під час виправлення вразливості безпеки помилково налаштував частину критичних функцій переказу на властивість public, що дозволило будь-кому ззовні контракту викликати ці функції для виконання переказів, що поставило під серйозний ризик активи користувачів на суму 590 000 доларів.
!
У Rust смартконтрактах контроль видимості функцій так само важливий. Контрактні функції, позначені макросом #[near_bindgen], визначеним NEAR SDK, мають такі видимі властивості:
Інший спосіб встановити метод як internal — це визначити його в кодовому блоці impl Contract, який не модифікований #[near_bindgen].
Для функцій зворотного виклику їх необхідно встановити як публічні властивості, щоб їх можна було викликати через виклик функції. Також потрібно впевнитися, що функція зворотного виклику може бути викликана лише самим контрактом, для цього можна використовувати макрос #[private].
!
2. Контроль доступу до функцій з привілеями(механізм білого списку)
Окрім видимості функцій, також необхідно з семантичного рівня встановити повноцінний механізм контролю доступу з білого списку. Деякі привілейовані функції (такі як ініціалізація контракту, запуск/призупинення, єдиний переказ тощо) можуть бути викликані тільки власником контракту (owner).
Можна реалізувати власні Trait для контролю доступу до привілейованих функцій, перевіряючи, чи є викликачем транзакції власник контракту:
іржавчина паб риса Власна { fn assert_owner(&self) { assert_eq!(env::p redecessor_account_id(), self.get_ owner()); } fn get_owner(&self) -> AccountId; fn set_owner(&mut self, власник: AccountId); }
На основі цього принципу можна налаштувати декілька користувачів або кілька білого списку за допомогою налаштованих більш складних trait для реалізації детального контролю доступу до груп.
!
3. Більше методів контролю доступу
Інші методи контролю доступу в смартконтрактах Rust також включають:
Ці матеріали будуть детально представлені в наступній серії щоденників розвитку смартконтрактів.
!
!
!
!
!
!
!