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

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

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

Мгновенный заем

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

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

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

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

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

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

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

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

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

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

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

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

1. Не только предотвращает повторный вход в единственную функцию
2. Соблюдение модели Проверки-Эффекты-Взаимодействия
3. Используйте проверенный модификатор для предотвращения повторного входа

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

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

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

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

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

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