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

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

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

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

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

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

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

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

Проблема манипуляции ценами тесно связана с.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. Обратите внимание на оракулы: проекты, использующие известные оракулы, относительно безопаснее; будьте особенно осторожны с самостроенными или легко поддающимися манипуляциям оракулами.

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