Аналіз поширених вразливостей безпеки DeFi та заходів їх запобігання

Нещодавно один з експертів з безпеки поділився з членами спільноти своїми поглядами на безпеку Децентралізованих фінансів. Він оглянув основні інциденти безпеки в індустрії Web3 за останній рік, обговорив причини їх виникнення та способи їх уникнення, узагальнив поширені вразливості смарт-контрактів та запобіжні заходи, а також дав кілька рекомендацій щодо безпеки для проектів та користувачів.

Типові вразливості в області Децентралізовані фінанси включають в себе миттєві позики, маніпуляцію цінами, проблеми з правами функцій, довільні зовнішні виклики, проблеми з функцією fallback, вразливості бізнес-логіки, витік приватних ключів та атаки повторного входу. У цій статті основна увага буде приділена трьом типам: миттєвим позикам, маніпуляції цінами та атакам повторного входу.

Швидкі позики

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

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

Контроль цін

Проблема маніпуляцій з цінами тісно пов'язана з блискавичними позиками, існує дві основні ситуації:

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

Атака повторного входу

Основний ризик виклику зовнішніх контрактів полягає в тому, що вони можуть захопити контрольний потік і внести непередбачувані зміни до даних. Типовий приклад атаки повторного входу наведено нижче:

солідність відображення (address => uint) private userBalances;

функція withdrawBalance() публічна { uint amountToRemove = userBalances[msg.sender]; (bool успіху ) = msg.sender.call.value(amountToWithdraw)("" ); require(успіх); userBalances[msg.sender] = 0; }

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

Для вирішення проблеми повторного входу необхідно звернути увагу на наступні пункти:

1. Не тільки запобігти повторному входу в одну функцію, а й врахувати повторний вхід між функціями та між контрактами.
2. Дотримуйтесь моделі Checks-Effects-Interactions при кодуванні.
3. Використовуйте перевірений модифікатор захисту від повторного входження.

Важливо уникати повторного створення колеса, слід використовувати найкращі практики безпеки, вже перевірені в галузі.

Рекомендації щодо безпеки від проекту

1. Дотримуйтесь найкращих практик безпеки при розробці смарт-контрактів.
2. Реалізувати можливість оновлення та призупинення контракту.
3. Використання механізму таймлок.
4. Збільшити інвестиції в безпеку, створити вдосконалену систему безпеки.
5. Підвищити обізнаність усіх працівників щодо безпеки.
6. Запобігання внутрішнім зловживанням, одночасно підвищуючи ефективність та посилюючи управління ризиками.
7. Обережно залучайте третіх осіб, дотримуючись принципу "за замовчуванням, як верхні, так і нижні ланки не є безпечними".

Як користувачам визначити безпеку смарт-контрактів

1. Підтвердіть, чи є контракт відкритим.
2. Перевірте, чи власник використовує децентралізований мультипідпис.
3. Перегляньте вже існуючі торгові ситуації контракту.
4. Досліджте, чи є контракт代理-контрактом, чи можна його оновити, чи має він часовий замок.
5. Підтвердьте, чи контракт проходив аудит у кількох установ, оцініть, чи не є повноваження власника занадто великими.
6. Зверніть увагу на тип оракулів, що використовуються в проєкті, та їхню безпеку.

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