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

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

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

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

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

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

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

Проблема маніпуляцій з цінами тісно пов'язана з闪电贷, основні два типи:

1. При розрахунку ціни використовуються дані третьої сторони, але неправильне використання або відсутність перевірки призводять до зловмисної маніпуляції ціною.

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

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

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

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

1. Не лише запобігає проблемі повторного входу для однієї функції

2. Дотримуйтесь моделі Checks-Effects-Interactions під час кодування

3. Використовуйте перевірений часом модифікатор для запобігання повторним викликам

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

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

Поради щодо безпеки команди проекту

1. Розробка контракту дотримується найкращих практик безпеки.

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

3. Використання таймлапсу: якщо є таймлапс, припустимо, що його потрібно завершити протягом 48 годин, у цей час під час таймлапсу багато людей можуть виявити, що творець знову оновив метод mint, який можуть використовувати всі, ті, хто моніторить, знають, що проект може бути зламаний, можуть сповістити команду проекту змінити це, навіть якщо сповістили, ніхто не звертає на це уваги, принаймні, можна спочатку забрати свою частину грошей, щоб забезпечити, що свої доходи не постраждають. Тож якщо у проекту немає таймлапсу, теоретично це підвищує ймовірність виникнення проблем.

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

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

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

7. Безпека залучення третіх сторін: як частина екосистеми, у проєкту завжди є свої постачальники та споживачі. Існує принцип "за замовчуванням, що всі постачальники та споживачі є небезпечними". Як для постачальників, так і для споживачів необхідно проводити перевірку. Щодо третіх сторін, ми важко можемо контролювати, і ризик безпеки насправді є дуже великим, тому потрібно бути дуже обережними з залученням третіх сторін. Контракт є відкритим, його можна залучати, викликати; якщо контракт не є відкритим, його абсолютно не можна використовувати.

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

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

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

2. Чи використовує власник мультипідпис, чи є мультипідпис децентралізованим: якщо мультипідпис не використовується, ми не можемо оцінити бізнес-логіку та зміст проекту, і якщо виникає інцидент безпеки, неможливо визначити, чи це справа хакера. Навіть якщо використовується мультипідпис, необхідно перевірити, чи є мультипідпис децентралізованим.

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

4. Чи є контракт代理сним контрактом, чи можна його оновити, чи є часова блокування: якщо контракт зовсім не можна оновити, це занадто жорстко, все ж рекомендується, щоб контракт проекту можна було оновити. Але оновлення повинно мати свої методи, коли є зміст оновлення, зміни важливих параметрів, має бути часовий блок, потрібно надати всім часове вікно, щоб оцінити, чи є реальне оновлення шкідливим чи вигідним для користувачів, це також є способом відкритості та прозорості.

5. Чи проходив контракт аудит у кількох установах ( Не слід сліпо довіряти аудиторам ), Чи є права Owner надмірними: по-перше, не слід довіряти лише одній аудиторській компанії, оскільки різні аудиторські компанії, різні аудитори мають різні погляди на проблеми. По-друге, слід перевірити, чи є права Owner надмірними. У нормальному проекті права Owner повинні бути контрольованими, щоб уникнути надто багатьох небезпечних операцій, а операції також мають виконуватись з використанням таймлоків, щоб користувачі знали, що саме виконується.

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