Децентралізовані фінанси 常见安全漏洞及预防措施

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

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

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

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

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

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

Контроль цін

Проблема маніпуляцій цінами тісно пов'язана з.flash loans, існує два основних типи:

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

Отже, у середовищі Web3, зберігаючи пильність і ставлячи кілька запитань «чому», можна уникнути багатьох потенційних ризиків. Як команди проекту, так і звичайні користувачі повинні приділяти увагу питанням безпеки, створюючи розгорнуту свідомість безпеки та механізми захисту.