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

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

Звичайні типи вразливостей DeFi, як правило, включають в себе флеш-кредити, маніпуляції цінами, проблеми з правами функцій, будь-які зовнішні виклики, проблеми з функцією 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. Обережно впроваджуйте третіх осіб: необхідно проводити безпекову перевірку для всіх учасників, особливо для закритих контрактів.

Методи оцінки безпеки смарт-контрактів для користувачів/LP

1. Перевірте, чи є контракт з відкритим вихідним кодом: не беріть участі в проектах без відкритого вихідного коду.

2. Підтвердьте, чи використовує власник децентралізований мультипідпис.

3. Перегляньте існуючу торгову ситуацію по контракту: час розгортання, кількість взаємодій тощо

4. Перевірте, чи є контракт代理契约, чи можна його оновити, чи є у ньому таймер.

5. Підтвердіть, чи контракт проходив аудит у кількох організацій, чи не є права Owner занадто великими

6. Зверніть увагу на надійність оракулів: провідні оракули є досить безпечними, самостійно створені або оракули з низьким бар'єром входу потребують обережності.

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