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

В этой статье будут рассмотрены аспекты контроля доступа в смарт-контрактах на Rust с двух точек зрения:

• Видимость доступа/вызова методов (функций) смарт-контрактов
• Контроль доступа к функциям привилегий / Распределение полномочий и ответственности

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

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

В качестве примера биржи Bancor Network, 18 июня 2020 года на этой бирже произошел инцидент с безопасностью активов, вызванный неправильной настройкой контроля доступа к ключевым функциям смарт-контракта. Этот контракт был написан на языке Solidity, видимость функций контракта делится на public/external и private/internal. Первые позволяют вызывать функции контракта внешними вызывающими.

При исправлении одной из уязвимостей безопасности, по недосмотру, некоторые ключевые функции перевода в смарт-контракте были установлены как public, что позволило любому вызывать эти функции из вне для выполнения операций перевода, что поставило под серьезный риск активы пользователей на сумму 590000 долларов.

!

В смарт-контрактах Rust также необходимо уделять внимание контролю видимости функций контракта. В смарт-контрактных функциях Rust, помеченных макросом #[near_bindgen], определенных NEAR SDK, существуют следующие различные свойства видимости:

• 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 ), эти функции обычно называются "только для владельца".

Хотя эти ключевые функции должны быть установлены как публичные свойства, можно определить правила контроля доступа, которые должны быть выполнены для полного выполнения. В смарт-контрактах Rust можно реализовать пользовательский Trait, аналогичный модификатору onlyOwner в Solidity:

русть pub trait 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); }

!

Используя этот trait, можно реализовать контроль доступа к привилегированным функциям в смарт-контрактах, требуя, чтобы вызывающий был владельцем контракта. Исходя из этого принципа, можно создать более сложные модификаторы или trait для установки нескольких пользователей в белый список или установить несколько белых списков для реализации детализированного контроля доступа по группам.

!

3. Более методы управления доступом

Другие методы контроля доступа в Rust смарт-контрактах также включают:

• Управление временем вызова смарт-контрактов
• Механизм многофакторного вызова функций смарт-контрактов
• Управление(DAO) реализации

Эти материалы будут представлены в последующих статьях серии дневников по развитию смарт-контрактов.

!

!

!

!

!

!