У цій статті буде розглянуто два аспекти контролю доступу в смартконтрактах Rust:
Видимість доступу/виклику методів смартконтракту
Контроль доступу до привілейованих функцій/розподіл повноважень та відповідальності
1. Видимість функцій смартконтракту
Налаштування видимості функцій контракту може контролювати права доступу до функцій, захищаючи ключові частини від випадкового доступу. Наприклад, в обміннику Bancor Network у червні 2020 року через помилкове налаштування видимості ключових функцій сталася подія з безпекою активів.
У смартконтрактах на Rust видимість функцій контролюється наступним чином:
pub fn: публічна функція, доступна для виклику ззовні контракту
fn: внутрішня функція, може бути викликана лише всередині смартконтракту
pub(crate) fn: обмежити виклик всередині crate
Інший спосіб налаштування внутрішніх методів – це визначення незалежних кодових блоків impl Contract без використання модифікатора #[near_bindgen].
Функцію зворотного виклику потрібно встановити як pub, але слід переконатися, що вона може бути викликана лише самим контрактом. Можна реалізувати за допомогою макросу #[private].
За замовчуванням Rust все є приватним, але елементи в trait і enum за замовчуванням є публічними.
!
2. Контроль доступу до привілейованих функцій
Крім налаштування видимості функцій, також потрібно встановити механізм контрольного списку доступу. Подібно до модифікатора onlyOwner у Solidity, можна визначити привілейовані функції, які можуть викликати лише власник.
Це дозволяє реалізувати контроль доступу до функцій привілейованого доступу. Можна додатково розширити налаштування для створення багатокористувацького білого списку або кількох груп білого списку.
!
3. Інші методи контролю доступу
Ще можна реалізувати:
Контроль часу виклику смартконтракту
Механізм багатопідпису для викликів функцій смартконтрактів
управління (DAO ) механізм
Конкретну інформацію слід очікувати в подальших повідомленнях.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
20 лайків
Нагородити
20
4
Репост
Поділіться
Прокоментувати
0/400
EthMaximalist
· 08-14 01:11
Ахах, це ж той самий漏洞, через який bancor провалився колись?
Переглянути оригіналвідповісти на0
HalfBuddhaMoney
· 08-12 19:17
Уху, знову час писати баги!
Переглянути оригіналвідповісти на0
GhostAddressMiner
· 08-12 19:17
Ця вразливість контракту просто надто початкова, я випадково підписався на 276 гаманців хакерів, давно вже помітив, що з фінансовими потоками Bancor щось не так.
Переглянути оригіналвідповісти на0
CoconutWaterBoy
· 08-12 18:50
Займаюся контрактами вже кілька років, функція pub fn також багато разів зазнавала невдач.
Практика безпеки смартконтрактів Rust: детальний аналіз видимості функцій та контролю доступу
Rust смартконтракти養成日記(7)合約安全之計算精度
У цій статті буде розглянуто два аспекти контролю доступу в смартконтрактах Rust:
1. Видимість функцій смартконтракту
Налаштування видимості функцій контракту може контролювати права доступу до функцій, захищаючи ключові частини від випадкового доступу. Наприклад, в обміннику Bancor Network у червні 2020 року через помилкове налаштування видимості ключових функцій сталася подія з безпекою активів.
У смартконтрактах на Rust видимість функцій контролюється наступним чином:
Інший спосіб налаштування внутрішніх методів – це визначення незалежних кодових блоків impl Contract без використання модифікатора #[near_bindgen].
Функцію зворотного виклику потрібно встановити як pub, але слід переконатися, що вона може бути викликана лише самим контрактом. Можна реалізувати за допомогою макросу #[private].
За замовчуванням Rust все є приватним, але елементи в trait і enum за замовчуванням є публічними.
!
2. Контроль доступу до привілейованих функцій
Крім налаштування видимості функцій, також потрібно встановити механізм контрольного списку доступу. Подібно до модифікатора onlyOwner у Solidity, можна визначити привілейовані функції, які можуть викликати лише власник.
У Rust можна реалізувати подібний трейт Ownable:
іржа публічний трейд Власний { 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); }
Це дозволяє реалізувати контроль доступу до функцій привілейованого доступу. Можна додатково розширити налаштування для створення багатокористувацького білого списку або кількох груп білого списку.
!
3. Інші методи контролю доступу
Ще можна реалізувати:
Конкретну інформацію слід очікувати в подальших повідомленнях.
!
!
!
!
!
!
!
!