Анализ распространенных уязвимостей безопасности в Децентрализованных финансах и мер по их предотвращению

В последнее время один из экспертов по безопасности поделился с членами сообщества своими взглядами на безопасность Децентрализованных финансов. Он обсудил значительные инциденты безопасности, с которыми столкнулась индустрия Web3 за последний год, исследовал причины этих событий и способы их предотвращения, обобщил распространенные уязвимости смарт-контрактов и меры по их предотвращению, а также дал некоторые рекомендации по безопасности для проектов и пользователей.

Распространенные типы уязвимостей в области Децентрализованных финансов включают в себя флеш-кредиты, манипуляции с ценами, проблемы с правами функций, произвольные внешние вызовы, проблемы с функцией обратного вызова, уязвимости бизнес-логики, утечки приватных ключей и атаки повторного входа. В этой статье будет уделено особое внимание трем типам: флеш-кредиты, манипуляции с ценами и атаки повторного входа.

Мгновенный кредит

Флеш-займы являются инновацией в области Децентрализованных финансов, но также часто используются хакерами. Злоумышленники берут в займы большие суммы денег через флеш-займы, чтобы манипулировать ценами или атаковать бизнес-логику. Разработчики должны учитывать, приведет ли использование огромных средств к аномалиям в функции контракта или будет ли это использовано для получения необоснованной выгоды через взаимодействие нескольких функций в одной сделке.

За последние два года заемы с использованием Flash Loan вызвали множество проблем. Некоторые, казалось бы, высокодоходные проекты Децентрализованных финансов на самом деле имеют множество угроз безопасности. Например, в некоторых проектах награды выплачиваются в фиксированное время в зависимости от объема держания, что злоумышленники используют, чтобы взять Flash Loan и приобрести большое количество токенов для получения большей части награды. Также некоторые проекты, использующие токены для расчета цен, легко подвергаются влиянию Flash Loan, что может повлиять на цены.

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

Проблема манипуляций с ценами тесно связана с кредитами под залог, существует два основных случая:

1. При расчете цены используются данные третьих лиц, но способ их использования неправильный или отсутствует проверка, что приводит к злонамеренному манипулированию ценами.
2. Используйте баланс токенов определённых адресов в качестве вычислительной переменной, при этом этот баланс может временно увеличиваться или уменьшаться.

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

Основной риск вызова внешних контрактов заключается в том, что они могут перехватить управление потоком и внести неожиданные изменения в данные. Типичный пример атаки повторного входа приведен ниже:

солидность отображение (address => uint) private userBalances;

функция withdrawBalance() публичная { uint amountToWithdraw = 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. Осторожно вводите третьи стороны, следуя принципу "по умолчанию ни один из участников не безопасен".

Как пользователю определить безопасность смарт-контракта

1. Подтвердите, является ли контракт открытым.
2. Проверьте, использует ли владелец децентрализованный механизм мультиподписей.
3. Просмотрите существующую торговую ситуацию по контракту.
4. Узнайте, является ли контракт агентским, можно ли его обновить, есть ли временная блокировка.
5. Подтвердите, что контракт прошел аудит нескольких учреждений, оцените, не слишком ли велики права Owner.
6. Обратите внимание на тип и безопасность оракула, используемого в проекте.

В общем, в области Децентрализованные финансы безопасность всегда является первоочередным фактором. Проектам следует всесторонне повышать осведомленность о безопасности и меры защиты, а пользователи должны оставаться бдительными, тщательно оценивая безопасность проекта перед принятием решения.