Децентрализованные финансы Часто встречающиеся уязвимости безопасности и меры предосторожности

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

Распространенные типы уязвимостей DeFi в основном включают в себя кредитование через Flash Loan, манипуляции с ценами, проблемы с функцией прав доступа, произвольные вызовы внешних функций, проблемы с fallback-функцией, уязвимости бизнес-логики, утечку приватных ключей и атаки повторного входа. Ниже мы подробнее рассмотрим три типа: кредитование через Flash Loan, манипуляции с ценами и атаки повторного входа.

Флеш-кредит

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

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

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

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

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. Проходил ли контракт аудит у нескольких учреждений, нет ли у владельца слишком больших полномочий?
6. Обратите внимание на безопасность оракулов

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