Децентралізовані фінанси Загальні вразливості безпеки та заходи запобігання
Нещодавно один із експертів з безпеки провів урок з безпеки DeFi для членів спільноти. Експерт оглянув значні інциденти безпеки, які сталися в індустрії Web3 за останній рік, обговорив причини виникнення цих інцидентів безпеки та як їх уникнути, підсумував поширені вразливості смарт-контрактів та заходи запобігання, а також дав деякі рекомендації з безпеки для проектів та звичайних користувачів.
Звичайні типи вразливостей DeFi зазвичай включають миттєвий кредит, маніпуляцію цінами, проблеми з функціональними правами, довільні зовнішні виклики, проблеми з функцією fallback, вразливості бізнес-логіки, витік приватних ключів, повторний вхід тощо. Далі ми зосередимося на трьох типах: миттєвий кредит, маніпуляція цінами та атака повторного входу.
Швидкі кредити
Швидкі кредити самі по собі є інновацією в Децентралізованих фінансах, але коли їх використовують хакери, вони можуть отримати великі суми грошей без жодних витрат, виконати весь процес арбітражу, а потім повернути кошти, сплативши лише невелику частину Gas витрат, щоб отримати величезний прибуток.
Протягом останніх двох років у Flash Loan виникло багато проблем. Деякі проекти DeFi виглядають дуже прибутковими, але насправді рівень команди проекту варіюється. Деякі проекти можуть мати код, який був куплений, і навіть якщо сам код не має вразливостей, логічно все ще можуть виникати проблеми. Наприклад, був проект, який розподіляв нагороди у фіксований час на основі кількості токенів, що утримуються власниками, але зловмисники скористалися Flash Loan, щоб придбати велику кількість токенів, і під час розподілу нагород більшість нагород потрапила до зловмисників. Крім того, є деякі проекти, які розраховують ціну через токени, і їх можна впливати через Flash Loan. Як команда проекту, слід підвищити обізнаність щодо цих проблем.
Маніпуляція цінами
Проблема маніпулювання цінами тісно пов'язана з миттєвими кредитами, ця проблема в основному виникає через те, що під час розрахунку ціни деякі параметри можуть контролюватися користувачами, часто виникають два типи проблем:
Використання даних третіх сторін для розрахунку ціни, але неправильне використання або відсутність перевірки призводить до зловмисного маніпулювання ціною.
Використовувалася кількість токенів з деяких адрес як змінна для обчислень, а баланс токенів цих адрес може бути тимчасово збільшений або зменшений.
Атака повторного входу
Однією з основних небезпек виклику зовнішніх контрактів є те, що вони можуть перехоплювати контрольний потік і вносити непередбачувані зміни у ваші дані.
Оскільки баланс користувача встановлюється на 0 лише в кінці функції, другий виклик ( та подальші виклики ) все ще будуть успішними і знову і знову знімуть баланс.
Що стосується різних контрактів, існує багато способів повторного входу, які можуть бути реалізовані через різні функції контракту або функції кількох різних контрактів для виконання атаки повторного входу, тому при вирішенні проблеми повторного входу нам слід звернути увагу на такі моменти:
Не тільки запобігання проблемі повторного входу одного функції;
Дотримуйтесь моделі Checks-Effects-Interactions під час кодування;
Використовуйте модифікатор захисту від повторних викликів, перевірений часом.
Насправді, найстрашніше - це повторне створення колеса, коли потрібно все писати самому. У цьому колі існує багато найкращих практик безпеки, які ми можемо використовувати, і зовсім немає необхідності повторно створювати колесо. Коли ви створюєте колесо, воно не пройшло достатньої перевірки, тому ймовірність виникнення проблем у цей момент, очевидно, набагато вища, ніж у випадку використання дуже зрілого, перевіреного рішення.
Рекомендації з безпеки
Поради щодо безпеки проекту
Розробка контрактів відповідає найкращим практикам безпеки.
Контракти можуть бути оновлені та призупинені: багато атак не є одноразовими, коли всі монети переводяться, а виконуються через кілька транзакцій. Якщо є відносно надійний механізм моніторингу, це можна виявити, і якщо контракт може бути призупинений після виявлення, це може ефективно зменшити втрати.
Використання тимчасового замка: якщо є тимчасовий замок, припустимо, що він може бути завершений протягом 48 годин, в цей момент багато людей, які мають доступ до тимчасового замка, можуть виявити, що творець оновив метод mint, і будь-хто може його використовувати, спостерігачі знатимуть, що проект, ймовірно, був зламаний, і можуть повідомити проекту про необхідність змін. Навіть якщо, припустимо, повідомили, ніхто не реагує, принаймні можна спочатку забрати свою частину грошей, щоб гарантувати, що їхній прибуток не постраждає. Отже, якщо проект не має тимчасового замка, теоретично це збільшує ймовірність виникнення проблем.
Збільшити інвестиції в безпеку, створити комплексну систему безпеки: безпека - це не точка і не лінія, безпека є системною. Не думайте, що як проектна сторона, якщо контракт пройшов аудит кількома компаніями, то все в порядку. Слід максимально проводити моделювання ризиків, а потім поступово усувати більшість ризиків, залишкові ризики повинні бути прийнятними, в межах допустимого. Безпека та ефективність не можуть бути досягнуті одночасно, потрібно робити певні компроміси. Але якщо повністю ігнорувати безпеку та не вкладати в неї, то атака є цілком нормальною.
Підвищення безпеки всіх співробітників: підвищення обізнаності про безпеку не потребує багато технологій. У цьому великому середовищі, якщо просто задати трохи більше запитань "чому" і трохи більше подумати, можна уникнути багатьох проблем.
Запобігання внутрішнім зловживанням, підвищуючи ефективність, водночас зміцнюючи контроль ризиків.
Безпека залучення третіх сторін: як частина екосистеми, проекти завжди мають своїх підрядників і постачальників. Існує принцип, що "за замовчуванням всі підрядники та постачальники є небезпечними". Для підрядників і постачальників потрібно проводити перевірку. Контролювати третіх сторін дуже складно, фактично ризик безпеки є надзвичайно великим, тому потрібно бути дуже обережними з залученням третіх сторін. Контракт є відкритим вихідним кодом, його можна використовувати та викликати; якщо контракт не є відкритим, його абсолютно не можна використовувати.
Як користувачеві/LP визначити, чи є смарт-контракт безпечним?
Для звичайних користувачів ми оцінюємо безпеку проекту, в основному, за такими шістьма пунктами:
Чи є контракт з відкритим кодом: усі проекти з закритими контрактами категорично не торкаємо, оскільки ми не можемо знати, що написано в контракті.
Чи використовує власник мультипідпис, чи є мультипідпис децентралізованим: якщо не використовувати мультипідпис, ми не можемо оцінити бізнес-логіку та зміст проєкту, і якщо виникає проблема безпеки, ми не можемо визначити, чи це справа хакера. Навіть якщо використовується мультипідпис, потрібно перевірити, чи є мультипідпис децентралізованим.
Існуюча ситуація з торгівлею контрактом: особливо на ринку є багато проектів, які займаються фішингом і шахрайством, вони можуть створити досить схожий контракт, тому в цей момент ми повинні звернути увагу на час розгортання контракту, кількість взаємодій тощо. Усі ці фактори є критеріями для оцінки безпеки контракту.
Чи є контракт агентським контрактом, чи можна його оновлювати, чи є часовий замок: якщо контракт абсолютно не підлягає оновленню, то він занадто жорсткий, все ж рекомендується, щоб контракт проекту можна було оновити. Але оновлення має бути проведене обдумано, коли в оновленні є важливі зміни або зміни параметрів, має бути встановлений часовий замок, щоб дати всім час для оцінки, чи є справжнє оновлення шкідливим чи корисним для користувачів, це також спосіб забезпечення відкритості та прозорості.
Чи проходив контракт аудит від кількох установ ( не варто сліпо довіряти аудиторським компаніям ), чи є повноваження власника занадто великими: по-перше, не варто довіряти лише одній аудиторській компанії, оскільки різні аудиторські компанії, різні аудитори дивляться на проблему з різних точок зору. По-друге, слід звернути увагу на те, чи є повноваження власника занадто великими. У нормальному проекті повноваження власника повинні бути контрольованими, так що не буде занадто багато небезпечних операцій, а операції також виконуватимуться у вигляді тайм-локів, щоб користувачі знали, що саме робиться.
Зверніть увагу на оракул: якщо проект використовує провідні оракули на ринку, в основному не буде великих проблем, але якщо використовуються оракули, створені самостійно, або оракули, які дозволяють просто закласти певні токени для подачі цін, то слід бути обережними. Коли ви виявите, що оракул може мати деякі проблеми або є можливість маніпуляцій, навіть якщо прибутковість проекту дуже висока, не слід брати участь.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
4
Поділіться
Прокоментувати
0/400
MetaverseHobo
· 13год тому
Необхідно бути обережним проведіть власне дослідження (DYOR)
Децентралізовані фінанси безпеки: аналіз поширених вразливостей та запобіжних заходів
Децентралізовані фінанси Загальні вразливості безпеки та заходи запобігання
Нещодавно один із експертів з безпеки провів урок з безпеки DeFi для членів спільноти. Експерт оглянув значні інциденти безпеки, які сталися в індустрії Web3 за останній рік, обговорив причини виникнення цих інцидентів безпеки та як їх уникнути, підсумував поширені вразливості смарт-контрактів та заходи запобігання, а також дав деякі рекомендації з безпеки для проектів та звичайних користувачів.
Звичайні типи вразливостей DeFi зазвичай включають миттєвий кредит, маніпуляцію цінами, проблеми з функціональними правами, довільні зовнішні виклики, проблеми з функцією fallback, вразливості бізнес-логіки, витік приватних ключів, повторний вхід тощо. Далі ми зосередимося на трьох типах: миттєвий кредит, маніпуляція цінами та атака повторного входу.
Швидкі кредити
Швидкі кредити самі по собі є інновацією в Децентралізованих фінансах, але коли їх використовують хакери, вони можуть отримати великі суми грошей без жодних витрат, виконати весь процес арбітражу, а потім повернути кошти, сплативши лише невелику частину Gas витрат, щоб отримати величезний прибуток.
Протягом останніх двох років у Flash Loan виникло багато проблем. Деякі проекти DeFi виглядають дуже прибутковими, але насправді рівень команди проекту варіюється. Деякі проекти можуть мати код, який був куплений, і навіть якщо сам код не має вразливостей, логічно все ще можуть виникати проблеми. Наприклад, був проект, який розподіляв нагороди у фіксований час на основі кількості токенів, що утримуються власниками, але зловмисники скористалися Flash Loan, щоб придбати велику кількість токенів, і під час розподілу нагород більшість нагород потрапила до зловмисників. Крім того, є деякі проекти, які розраховують ціну через токени, і їх можна впливати через Flash Loan. Як команда проекту, слід підвищити обізнаність щодо цих проблем.
Маніпуляція цінами
Проблема маніпулювання цінами тісно пов'язана з миттєвими кредитами, ця проблема в основному виникає через те, що під час розрахунку ціни деякі параметри можуть контролюватися користувачами, часто виникають два типи проблем:
Використання даних третіх сторін для розрахунку ціни, але неправильне використання або відсутність перевірки призводить до зловмисного маніпулювання ціною.
Використовувалася кількість токенів з деяких адрес як змінна для обчислень, а баланс токенів цих адрес може бути тимчасово збільшений або зменшений.
Атака повторного входу
Однією з основних небезпек виклику зовнішніх контрактів є те, що вони можуть перехоплювати контрольний потік і вносити непередбачувані зміни у ваші дані.
Оскільки баланс користувача встановлюється на 0 лише в кінці функції, другий виклик ( та подальші виклики ) все ще будуть успішними і знову і знову знімуть баланс.
Що стосується різних контрактів, існує багато способів повторного входу, які можуть бути реалізовані через різні функції контракту або функції кількох різних контрактів для виконання атаки повторного входу, тому при вирішенні проблеми повторного входу нам слід звернути увагу на такі моменти:
Не тільки запобігання проблемі повторного входу одного функції;
Дотримуйтесь моделі Checks-Effects-Interactions під час кодування;
Використовуйте модифікатор захисту від повторних викликів, перевірений часом.
Насправді, найстрашніше - це повторне створення колеса, коли потрібно все писати самому. У цьому колі існує багато найкращих практик безпеки, які ми можемо використовувати, і зовсім немає необхідності повторно створювати колесо. Коли ви створюєте колесо, воно не пройшло достатньої перевірки, тому ймовірність виникнення проблем у цей момент, очевидно, набагато вища, ніж у випадку використання дуже зрілого, перевіреного рішення.
Рекомендації з безпеки
Поради щодо безпеки проекту
Розробка контрактів відповідає найкращим практикам безпеки.
Контракти можуть бути оновлені та призупинені: багато атак не є одноразовими, коли всі монети переводяться, а виконуються через кілька транзакцій. Якщо є відносно надійний механізм моніторингу, це можна виявити, і якщо контракт може бути призупинений після виявлення, це може ефективно зменшити втрати.
Використання тимчасового замка: якщо є тимчасовий замок, припустимо, що він може бути завершений протягом 48 годин, в цей момент багато людей, які мають доступ до тимчасового замка, можуть виявити, що творець оновив метод mint, і будь-хто може його використовувати, спостерігачі знатимуть, що проект, ймовірно, був зламаний, і можуть повідомити проекту про необхідність змін. Навіть якщо, припустимо, повідомили, ніхто не реагує, принаймні можна спочатку забрати свою частину грошей, щоб гарантувати, що їхній прибуток не постраждає. Отже, якщо проект не має тимчасового замка, теоретично це збільшує ймовірність виникнення проблем.
Збільшити інвестиції в безпеку, створити комплексну систему безпеки: безпека - це не точка і не лінія, безпека є системною. Не думайте, що як проектна сторона, якщо контракт пройшов аудит кількома компаніями, то все в порядку. Слід максимально проводити моделювання ризиків, а потім поступово усувати більшість ризиків, залишкові ризики повинні бути прийнятними, в межах допустимого. Безпека та ефективність не можуть бути досягнуті одночасно, потрібно робити певні компроміси. Але якщо повністю ігнорувати безпеку та не вкладати в неї, то атака є цілком нормальною.
Підвищення безпеки всіх співробітників: підвищення обізнаності про безпеку не потребує багато технологій. У цьому великому середовищі, якщо просто задати трохи більше запитань "чому" і трохи більше подумати, можна уникнути багатьох проблем.
Запобігання внутрішнім зловживанням, підвищуючи ефективність, водночас зміцнюючи контроль ризиків.
Безпека залучення третіх сторін: як частина екосистеми, проекти завжди мають своїх підрядників і постачальників. Існує принцип, що "за замовчуванням всі підрядники та постачальники є небезпечними". Для підрядників і постачальників потрібно проводити перевірку. Контролювати третіх сторін дуже складно, фактично ризик безпеки є надзвичайно великим, тому потрібно бути дуже обережними з залученням третіх сторін. Контракт є відкритим вихідним кодом, його можна використовувати та викликати; якщо контракт не є відкритим, його абсолютно не можна використовувати.
Як користувачеві/LP визначити, чи є смарт-контракт безпечним?
Для звичайних користувачів ми оцінюємо безпеку проекту, в основному, за такими шістьма пунктами:
Чи є контракт з відкритим кодом: усі проекти з закритими контрактами категорично не торкаємо, оскільки ми не можемо знати, що написано в контракті.
Чи використовує власник мультипідпис, чи є мультипідпис децентралізованим: якщо не використовувати мультипідпис, ми не можемо оцінити бізнес-логіку та зміст проєкту, і якщо виникає проблема безпеки, ми не можемо визначити, чи це справа хакера. Навіть якщо використовується мультипідпис, потрібно перевірити, чи є мультипідпис децентралізованим.
Існуюча ситуація з торгівлею контрактом: особливо на ринку є багато проектів, які займаються фішингом і шахрайством, вони можуть створити досить схожий контракт, тому в цей момент ми повинні звернути увагу на час розгортання контракту, кількість взаємодій тощо. Усі ці фактори є критеріями для оцінки безпеки контракту.
Чи є контракт агентським контрактом, чи можна його оновлювати, чи є часовий замок: якщо контракт абсолютно не підлягає оновленню, то він занадто жорсткий, все ж рекомендується, щоб контракт проекту можна було оновити. Але оновлення має бути проведене обдумано, коли в оновленні є важливі зміни або зміни параметрів, має бути встановлений часовий замок, щоб дати всім час для оцінки, чи є справжнє оновлення шкідливим чи корисним для користувачів, це також спосіб забезпечення відкритості та прозорості.
Чи проходив контракт аудит від кількох установ ( не варто сліпо довіряти аудиторським компаніям ), чи є повноваження власника занадто великими: по-перше, не варто довіряти лише одній аудиторській компанії, оскільки різні аудиторські компанії, різні аудитори дивляться на проблему з різних точок зору. По-друге, слід звернути увагу на те, чи є повноваження власника занадто великими. У нормальному проекті повноваження власника повинні бути контрольованими, так що не буде занадто багато небезпечних операцій, а операції також виконуватимуться у вигляді тайм-локів, щоб користувачі знали, що саме робиться.
Зверніть увагу на оракул: якщо проект використовує провідні оракули на ринку, в основному не буде великих проблем, але якщо використовуються оракули, створені самостійно, або оракули, які дозволяють просто закласти певні токени для подачі цін, то слід бути обережними. Коли ви виявите, що оракул може мати деякі проблеми або є можливість маніпуляцій, навіть якщо прибутковість проекту дуже висока, не слід брати участь.