Децентралізовані фінанси Загальні вразливості безпеки та заходи запобігання

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

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

Лендінг

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

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

Маніпуляція цінами

Проблема маніпуляцій з цінами тісно пов'язана з闪电贷, головним чином через те, що деякі параметри під час розрахунку ціни можуть контролюватися користувачами. Існує два основних типи проблем:

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

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

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

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

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

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

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

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

Як користувачам/LP визначити, чи є смарт-контракт безпечним

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

Зосередившись на цих аспектах, користувачі можуть краще оцінити безпеку смарт-контрактів і зменшити ймовірність участі в ризикованих проектах.