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

Нещодавно один експерт з безпеки поділився з членами спільноти уроком з безпеки 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. Використовуйте перевірений часом модифікатор для запобігання повторним викликам.

Типовим випадком атаки повторного входу є інцидент з Omni Protocol. У цій атаці угоди, подані зловмисником, який виявив вразливість, були перехоплені іншими хакерами та виконані раніше, що призвело до того, що первісний зловмисник отримав лише частину прибутку. Це підкреслює характеристику "темного лісу" в екосистемі Web3, де зловмисники можуть бути один для одного здобиччю.

Рекомендації з безпеки

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

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

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

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

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