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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по безопасности

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

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

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

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

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