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

Ця стаття розгляне питання контролю доступу в смартконтрактах Rust з двох точок зору:

1. Видимість доступу/виклику методів (функцій) контракту
2. Контроль доступу до функцій з привілегіями/Розподіл прав та обов'язків

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

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

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

Bancor Network під час виправлення певної вразливості безпеки помилково встановив деякі ключові функції переказу в контракті як public, що дозволило будь-кому ззовні викликати ці функції для виконання операцій з переказу. Ця ключова вразливість поставила під серйозний ризик активи користувачів на суму 590 000 доларів.

!

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

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

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

!

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

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

!

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

Окрім видимості функцій, також потрібно з рівня семантики контракту встановити повноцінний механізм контролю доступу за білою списком. Деякі привілейовані функції (, такі як ініціалізація контракту, вмикання/вимикання, об'єднаний переказ тощо ) можуть бути викликані лише власником контракту ( owner ), ці функції зазвичай називаються "only 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, можна реалізувати контроль доступу до привілейованих функцій у контракті, вимагаючи, щоб викликачем був власник контракту. На основі цього принципу можна налаштувати більш складні модифікатори або traits для встановлення декількох користувачів або кількох білого списку, реалізуючи детальний контроль доступу за групами.

!

!

!

!

!

!

!