Распространенные уязвимости безопасности в Децентрализованных финансах и меры предосторожности

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

Займ под залог

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

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

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

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

Манипуляции с ценами тесно связаны с флеш-кредитами, существует две основные проблемы:

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

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

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

Типичный пример повторного входа: солидность отображение (address => uint) private userBalances;

функция withdrawBalance() публичная { uint amountToWithdraw = userBalances[msg.sender]; (bool успех, ) = msg.sender.call.value(amountToWithdraw)("" ); require(успех); userBalances[msg.sender] = 0; }

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

Решение проблемы повторного входа требует внимания:

1. Не только предотвращает повторный ввод одной функции
2. Следуйте модели Checks-Effects-Interactions
3. Используйте проверенный модификатор для предотвращения повторных вызовов

Рекомендуется использовать зрелые практики безопасности, избегая изобретения колеса заново.

Рекомендации по безопасности для проектной стороны

1. Следуйте лучшим практикам безопасности при разработке контрактов
2. Реализовать возможность обновления контрактов и их приостановки
3. Использование временной блокировки
4. Создание完善ной системы безопасности
5. Повышение безопасности для всех сотрудников
6. Предотвращение внутренних злоупотреблений, повышение эффективности и усиление контроля рисков
7. Осторожно вводите третьи стороны, по умолчанию считайте их небезопасными и проведите проверку.

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

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

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