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

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

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

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

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

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

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

!

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

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

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

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

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

!

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

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

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

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

!

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

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

!

!

!

!

!

!

!