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

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

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

Швидкий кредит

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

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

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

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

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

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

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

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

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

У сфері Web3 доцільніше використовувати перевірені практики безпеки, ніж повторно винаходити колесо. Використання добре перевірених рішень може суттєво знизити ймовірність виникнення проблем.

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

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

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

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

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