Rust смартконтракти养成日记（7）合约安全之权限控制

У цій статті буде розглянуто питання контролю доступу в смартконтрактах Rust з двох точок зору:

• Видимість доступу/виклику методів (функцій) контракту
• Контроль доступу до функцій привілеїв/поділ повноважень

1. Видимість функцій (методів) контракту

Під час написання смартконтрактів, шляхом визначення видимості функцій контракту можна контролювати права доступу до функцій, захищаючи ключові частини контракту від випадкового доступу або маніпуляцій.

Наприклад, на біржі Bancor Network, 18 червня 2020 року відбувся інцидент із безпекою активів, спричинений помилкою в налаштуванні контролю доступу до ключових функцій смартконтракту. Цей смартконтракт був написаний мовою Solidity, а видимість функцій смартконтракту поділяється на public/external та private/internal. Перша дозволяє викликати функції смартконтракту зовнішнім викликачам.

Під час виправлення певної вразливості безпеки, через неуважність, випадково було встановлено, що деякі ключові функції переказу в контракті мають публічний атрибут, що дозволяє будь-кому ззовні викликати ці функції для виконання операцій з переказу, через що активи користувача на суму 590000 доларів США піддаються серйозному ризику.

!

У Rust смартконтрактах також слід звернути увагу на контроль видимості функцій контракту. Функції смартконтракту на Rust, які позначені макросом #[near_bindgen], мають кілька різних властивостей видимості:

• pub fn: вказує на те, що цей метод є публічним, належить до інтерфейсу контракту і може бути викликаний ззовні контракту.
• fn: Якщо не вказано явно pub, це означає, що неможливо викликати його безпосередньо ззовні контракту, його можна викликати лише з інших функцій всередині контракту.
• pub(crate) fn: еквівалентно pub( у crate), обмежуючи виклики методу в межах внутрішнього діапазону crate.

Інший спосіб встановити метод контракту як internal – це визначити окремий кодовий блок impl Contract у контракті, який не позначається #[near_bindgen].

Для функції зворотного виклику (Callbacks) визначення повинно бути встановлено як публічна властивість, але потрібно забезпечити, щоб її міг викликати лише сам контракт. NEAR SDK надає макрос #[private] для реалізації цієї функції.

Слід звернути увагу, що в мові Rust за замовчуванням все є приватним, за винятком підпроєктів у pub Trait та змінних Enum у pub Enum, які за замовчуванням є публічними.

!

2. Контроль доступу до функцій привілейованих(Механізм білої списку)

Окрім контролю видимості функцій, необхідно також з семантичного рівня контракту встановити повноцінний механізм контролю доступу у вигляді білого списку. Деякі привілейовані функції (, такі як ініціалізація контракту, відкриття/призупинення, уніфікований переказ тощо ) можуть бути викликані лише власником контракту ( owner ). Ці функції зазвичай називаються "only owner" функціями.

Хоча ці ключові функції повинні бути встановлені як публічні атрибути, можна визначити правила контролю доступу, за якими лише ті, хто відповідає відповідним правилам, можуть повністю виконати їх. У смартконтрактах Rust можна реалізувати кастомний Trait, аналогічний onlyOwner модифікатору в Solidity:

іржа публічний трейд Власний { 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, можна реалізувати контроль доступу до привілейованих функцій контракту, вимагаючи, щоб викликач був власником контракту. На основі цього принципу, можна за допомогою власних більш складних модифікаторів або traits налаштувати кілька користувачів у білому списку або встановити кілька білого списку для реалізації детального групового контролю доступу.

!

3. Більше методів контролю доступу

Інші методи контролю доступу в Rust смартконтрактах також включають:

• Контроль часу виклику смартконтракту
• Механізм мультипідпису для викликів функцій смартконтрактів
• Управління(DAO) реалізація

Ці матеріали будуть представлені в наступних статтях серії щоденників розвитку смартконтрактів.

!

!

!

!

!

!