Децентрализованные финансы Общие уязвимости безопасности и меры предосторожности
В последнее время один из экспертов по безопасности провел для участников сообщества урок по безопасности в Децентрализованных финансах. Эксперт рассмотрел значительные инциденты безопасности, с которыми столкнулась индустрия Web3 за последний год, обсудил причины этих инцидентов и способы их предотвращения, обобщил распространенные уязвимости смарт-контрактов и меры по их предотвращению, а также дал некоторые рекомендации по безопасности для проектов и обычных пользователей.
Распространенные типы уязвимостей DeFi обычно включают в себя флеш-кредиты, манипуляции с ценами, проблемы с правами доступа к функциям, произвольные внешние вызовы, проблемы с функцией fallback, уязвимости бизнес-логики, утечку приватных ключей и повторные атаки. Ниже особое внимание уделяется флеш-кредитам, манипуляциям с ценами и повторным атакам.
Мгновенный заем
Флэш-кредиты сами по себе являются инновацией в области Децентрализованные финансы, но когда их используют хакеры, они могут занять крупные суммы денег без каких-либо затрат, выполнить весь процесс арбитража и вернуть средства, заплатив лишь небольшую сумму за Gas, чтобы получить огромную прибыль.
За последние два года в займ на платформе Lightning возникло много проблем. Некоторые проекты Децентрализованных финансов выглядят очень прибыльными, но фактический уровень разработчиков проектов варьируется. В некоторых проектах код может быть куплен, и даже если сам код не содержит уязвимостей, логически могут возникнуть проблемы. Например, был проект, который в фиксированное время выдавал вознаграждение в зависимости от количества токенов, принадлежащих держателям, но злоумышленники использовали займ на платформе Lightning для покупки большого количества токенов, в результате чего большая часть вознаграждения ушла злоумышленникам. Кроме того, есть проекты, которые рассчитывают цену на основе токенов и могут влиять на цену через займ на платформе Lightning. Разработчики проектов должны быть настороже относительно этих проблем.
Манипуляция ценами
Проблема манипуляции ценами тесно связана с闪电贷, эта проблема в основном возникает из-за того, что некоторые параметры, используемые для расчета цены, могут контролироваться пользователями. Чаще всего возникают два типа проблем:
При расчете цены используются данные третьих лиц, но неправильное использование или отсутствие проверки приводит к манипуляции ценой.
Использовалось количество токенов с некоторых адресов в качестве расчетных переменных, при этом баланс токенов на этих адресах может временно увеличиваться или уменьшаться.
Атака повторного входа
Одной из основных опасностей вызова внешних контрактов является то, что они могут захватить управление потоком и внести неожиданные изменения в ваши данные, вызывая функции.
Поскольку баланс пользователя устанавливается в 0 только в конце функции, второй вызов ( и последующие вызовы ) все равно будут успешными и будут многократно извлекать баланс.
Существуют различные способы осуществления повторного входа для разных контрактов, которые могут сочетаться с различными функциями контракта или функциями нескольких различных контрактов для выполнения атаки повторного входа. Поэтому при решении проблемы повторного входа необходимо обратить внимание на следующие моменты:
Не только предотвращение проблемы повторного входа для одной функции;
Следуйте модели Checks-Effects-Interactions при кодировании;
Используйте проверенный временем модификатор для защиты от повторных входов.
На самом деле самое страшное — это повторное изобретение колеса, когда нужно что-то писать самостоятельно. В этой сфере есть много лучших практик безопасности, которые мы можем использовать, и совершенно нет необходимости повторно изобретать колесо. Когда вы создаете колесо, оно не прошло достаточной проверки, и вероятность возникновения проблем в этом случае, очевидно, гораздо выше, чем у очень зрелого и проверенного решения.
Рекомендации по безопасности
Советы по безопасности для проекта
Разработка контрактов должна соответствовать лучшим практикам безопасности.
Контракты могут быть обновлены и приостановлены: многие атаки не являются однократными, когда все монеты переводятся сразу, а выполняются через несколько транзакций. Если есть относительно надежный механизм мониторинга, это может быть обнаружено. Если после обнаружения контракт можно приостановить, это может эффективно снизить потери.
Использование временной блокировки: если есть временная блокировка, предположим, она составляет 48 часов, в это время многие могут обнаружить, что создатель обновил метод mint, которым может воспользоваться любой. Наблюдатели смогут понять, что проект, вероятно, был взломан, и смогут уведомить команду проекта о необходимости изменений. Даже если уведомление было отправлено, и никто не реагирует, по крайней мере, можно сначала вывести свою часть средств, чтобы гарантировать, что свои доходы не пострадают. Таким образом, можно сказать, что если у проекта нет временной блокировки, теоретически это увеличивает вероятность возникновения проблем.
Увеличить инвестиции в безопасность, создать完善ную систему безопасности: безопасность — это не точка, и не линия, безопасность — это система. Не думайте, что как проектная сторона, если контракт прошел аудит нескольких компаний, то с ним все в порядке. Необходимо стремиться к моделированию рисков, а затем постепенно минимизировать большинство рисков, оставшиеся риски также должны быть приемлемыми, в пределах допустимого. Безопасность и эффективность несовместимы, нужно делать определенные компромиссы. Но если полностью игнорировать безопасность и не вкладываться в нее, то атаки будут вполне обычным делом.
Повышение безопасности всех сотрудников: Повышение осведомленности о безопасности не требует много технологий. В этой обстановке, достаточно немного больше спрашивать «почему» и немного больше думать, чтобы избежать многих проблем.
Предотвращение внутреннего злоупотребления, одновременно повышая эффективность и усиливая риск-менеджмент.
Безопасность сторонних участников: в качестве элемента экосистемы, у проекта всегда есть свои контрагенты. В безопасности существует принцип "по умолчанию все контрагенты являются небезопасными". Необходимо проводить проверку как для контрагентов сверху, так и для контрагентов снизу. Контролировать третьих сторон сложно, фактически риск безопасности очень велик, поэтому следует уделять особое внимание привлечению третьих сторон. Контракт является открытым исходным кодом, его можно использовать и вызывать; если контракт не является открытым, его абсолютно нельзя использовать.
Как пользователю/LP определить, безопасен ли смарт-контракт?
Для обычных пользователей, мы оцениваем безопасность проекта, в первую очередь, по следующим шести пунктам:
Является ли контракт открытым: проекты, контракты которых не являются открытыми, мы решительно не рассматриваем, поскольку мы не можем узнать, что написано в контракте.
Использует ли владелец мультиподпись, и является ли мультиподпись децентрализованной: если мультиподпись не используется, мы не можем оценить бизнес-логику и содержание проекта; в случае возникновения инцидента безопасности невозможно определить, является ли он результатом действий хакеров. Даже если используется мультиподпись, необходимо проверить, является ли она децентрализованной.
Существующее состояние торгов по контракту: особенно на рынке есть много проектов с фишингом, которые могут создать довольно похожий контракт. В этом случае нам следует обратить внимание на время развертывания контракта, количество взаимодействий и так далее. Эти факторы являются критериями для оценки безопасности контракта.
Является ли контракт агентским контрактом, можно ли его обновить, есть ли временная блокировка: если контракт полностью не может быть обновлён, он слишком жесткий, поэтому я всё же рекомендую контракты проектов, которые можно обновлять. Однако обновление должно быть продуманным, когда есть содержание обновления или изменения важных параметров, необходимо установить временную блокировку, чтобы предоставить всем временной интервал для оценки, является ли настоящее обновление вредным или полезным для пользователей, что также является способом открытости и прозрачности.
Принимал ли контракт аудит от нескольких организаций ( не стоит слепо доверять аудиторским компаниям ), является ли полномочия владельца чрезмерными: во-первых, не стоит доверять только одной аудиторской компании, так как разные аудиторские компании и разные аудиторы смотрят на проблемы с разных точек зрения. Во-вторых, нужно проверить, не слишком ли велики полномочия владельца. У нормального проекта полномочия владельца должны быть контролируемыми, так не будет слишком много высокорисковых операций, и операции будут выполняться с помощью временных замков, чтобы пользователи знали, какие операции проводятся.
Обратите внимание на оракулы: если проект использует ведущие оракулы на рынке, в основном не будет больших проблем, но если используется собственный оракул или оракул, который может быть использован для подачи цен с некоторыми случайно заложенными токенами, тогда следует быть осторожным. Если обнаруживается, что у оракула могут быть некоторые проблемы или существует вероятность манипуляций, даже если доход проекта очень высок, участвовать в нем нельзя.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Децентрализованные финансы безопасность: анализ распространенных уязвимостей и меры предосторожности
Децентрализованные финансы Общие уязвимости безопасности и меры предосторожности
В последнее время один из экспертов по безопасности провел для участников сообщества урок по безопасности в Децентрализованных финансах. Эксперт рассмотрел значительные инциденты безопасности, с которыми столкнулась индустрия Web3 за последний год, обсудил причины этих инцидентов и способы их предотвращения, обобщил распространенные уязвимости смарт-контрактов и меры по их предотвращению, а также дал некоторые рекомендации по безопасности для проектов и обычных пользователей.
Распространенные типы уязвимостей DeFi обычно включают в себя флеш-кредиты, манипуляции с ценами, проблемы с правами доступа к функциям, произвольные внешние вызовы, проблемы с функцией fallback, уязвимости бизнес-логики, утечку приватных ключей и повторные атаки. Ниже особое внимание уделяется флеш-кредитам, манипуляциям с ценами и повторным атакам.
Мгновенный заем
Флэш-кредиты сами по себе являются инновацией в области Децентрализованные финансы, но когда их используют хакеры, они могут занять крупные суммы денег без каких-либо затрат, выполнить весь процесс арбитража и вернуть средства, заплатив лишь небольшую сумму за Gas, чтобы получить огромную прибыль.
За последние два года в займ на платформе Lightning возникло много проблем. Некоторые проекты Децентрализованных финансов выглядят очень прибыльными, но фактический уровень разработчиков проектов варьируется. В некоторых проектах код может быть куплен, и даже если сам код не содержит уязвимостей, логически могут возникнуть проблемы. Например, был проект, который в фиксированное время выдавал вознаграждение в зависимости от количества токенов, принадлежащих держателям, но злоумышленники использовали займ на платформе Lightning для покупки большого количества токенов, в результате чего большая часть вознаграждения ушла злоумышленникам. Кроме того, есть проекты, которые рассчитывают цену на основе токенов и могут влиять на цену через займ на платформе Lightning. Разработчики проектов должны быть настороже относительно этих проблем.
Манипуляция ценами
Проблема манипуляции ценами тесно связана с闪电贷, эта проблема в основном возникает из-за того, что некоторые параметры, используемые для расчета цены, могут контролироваться пользователями. Чаще всего возникают два типа проблем:
При расчете цены используются данные третьих лиц, но неправильное использование или отсутствие проверки приводит к манипуляции ценой.
Использовалось количество токенов с некоторых адресов в качестве расчетных переменных, при этом баланс токенов на этих адресах может временно увеличиваться или уменьшаться.
Атака повторного входа
Одной из основных опасностей вызова внешних контрактов является то, что они могут захватить управление потоком и внести неожиданные изменения в ваши данные, вызывая функции.
Поскольку баланс пользователя устанавливается в 0 только в конце функции, второй вызов ( и последующие вызовы ) все равно будут успешными и будут многократно извлекать баланс.
Существуют различные способы осуществления повторного входа для разных контрактов, которые могут сочетаться с различными функциями контракта или функциями нескольких различных контрактов для выполнения атаки повторного входа. Поэтому при решении проблемы повторного входа необходимо обратить внимание на следующие моменты:
Не только предотвращение проблемы повторного входа для одной функции;
Следуйте модели Checks-Effects-Interactions при кодировании;
Используйте проверенный временем модификатор для защиты от повторных входов.
На самом деле самое страшное — это повторное изобретение колеса, когда нужно что-то писать самостоятельно. В этой сфере есть много лучших практик безопасности, которые мы можем использовать, и совершенно нет необходимости повторно изобретать колесо. Когда вы создаете колесо, оно не прошло достаточной проверки, и вероятность возникновения проблем в этом случае, очевидно, гораздо выше, чем у очень зрелого и проверенного решения.
Рекомендации по безопасности
Советы по безопасности для проекта
Разработка контрактов должна соответствовать лучшим практикам безопасности.
Контракты могут быть обновлены и приостановлены: многие атаки не являются однократными, когда все монеты переводятся сразу, а выполняются через несколько транзакций. Если есть относительно надежный механизм мониторинга, это может быть обнаружено. Если после обнаружения контракт можно приостановить, это может эффективно снизить потери.
Использование временной блокировки: если есть временная блокировка, предположим, она составляет 48 часов, в это время многие могут обнаружить, что создатель обновил метод mint, которым может воспользоваться любой. Наблюдатели смогут понять, что проект, вероятно, был взломан, и смогут уведомить команду проекта о необходимости изменений. Даже если уведомление было отправлено, и никто не реагирует, по крайней мере, можно сначала вывести свою часть средств, чтобы гарантировать, что свои доходы не пострадают. Таким образом, можно сказать, что если у проекта нет временной блокировки, теоретически это увеличивает вероятность возникновения проблем.
Увеличить инвестиции в безопасность, создать完善ную систему безопасности: безопасность — это не точка, и не линия, безопасность — это система. Не думайте, что как проектная сторона, если контракт прошел аудит нескольких компаний, то с ним все в порядке. Необходимо стремиться к моделированию рисков, а затем постепенно минимизировать большинство рисков, оставшиеся риски также должны быть приемлемыми, в пределах допустимого. Безопасность и эффективность несовместимы, нужно делать определенные компромиссы. Но если полностью игнорировать безопасность и не вкладываться в нее, то атаки будут вполне обычным делом.
Повышение безопасности всех сотрудников: Повышение осведомленности о безопасности не требует много технологий. В этой обстановке, достаточно немного больше спрашивать «почему» и немного больше думать, чтобы избежать многих проблем.
Предотвращение внутреннего злоупотребления, одновременно повышая эффективность и усиливая риск-менеджмент.
Безопасность сторонних участников: в качестве элемента экосистемы, у проекта всегда есть свои контрагенты. В безопасности существует принцип "по умолчанию все контрагенты являются небезопасными". Необходимо проводить проверку как для контрагентов сверху, так и для контрагентов снизу. Контролировать третьих сторон сложно, фактически риск безопасности очень велик, поэтому следует уделять особое внимание привлечению третьих сторон. Контракт является открытым исходным кодом, его можно использовать и вызывать; если контракт не является открытым, его абсолютно нельзя использовать.
Как пользователю/LP определить, безопасен ли смарт-контракт?
Для обычных пользователей, мы оцениваем безопасность проекта, в первую очередь, по следующим шести пунктам:
Является ли контракт открытым: проекты, контракты которых не являются открытыми, мы решительно не рассматриваем, поскольку мы не можем узнать, что написано в контракте.
Использует ли владелец мультиподпись, и является ли мультиподпись децентрализованной: если мультиподпись не используется, мы не можем оценить бизнес-логику и содержание проекта; в случае возникновения инцидента безопасности невозможно определить, является ли он результатом действий хакеров. Даже если используется мультиподпись, необходимо проверить, является ли она децентрализованной.
Существующее состояние торгов по контракту: особенно на рынке есть много проектов с фишингом, которые могут создать довольно похожий контракт. В этом случае нам следует обратить внимание на время развертывания контракта, количество взаимодействий и так далее. Эти факторы являются критериями для оценки безопасности контракта.
Является ли контракт агентским контрактом, можно ли его обновить, есть ли временная блокировка: если контракт полностью не может быть обновлён, он слишком жесткий, поэтому я всё же рекомендую контракты проектов, которые можно обновлять. Однако обновление должно быть продуманным, когда есть содержание обновления или изменения важных параметров, необходимо установить временную блокировку, чтобы предоставить всем временной интервал для оценки, является ли настоящее обновление вредным или полезным для пользователей, что также является способом открытости и прозрачности.
Принимал ли контракт аудит от нескольких организаций ( не стоит слепо доверять аудиторским компаниям ), является ли полномочия владельца чрезмерными: во-первых, не стоит доверять только одной аудиторской компании, так как разные аудиторские компании и разные аудиторы смотрят на проблемы с разных точек зрения. Во-вторых, нужно проверить, не слишком ли велики полномочия владельца. У нормального проекта полномочия владельца должны быть контролируемыми, так не будет слишком много высокорисковых операций, и операции будут выполняться с помощью временных замков, чтобы пользователи знали, какие операции проводятся.
Обратите внимание на оракулы: если проект использует ведущие оракулы на рынке, в основном не будет больших проблем, но если используется собственный оракул или оракул, который может быть использован для подачи цен с некоторыми случайно заложенными токенами, тогда следует быть осторожным. Если обнаруживается, что у оракула могут быть некоторые проблемы или существует вероятность манипуляций, даже если доход проекта очень высок, участвовать в нем нельзя.