Децентрализованные финансы Общие уязвимости безопасности и меры предосторожности
В последнее время один из экспертов по безопасности провел урок безопасности DeFi для членов сообщества. Он обсудил крупные инциденты безопасности, произошедшие в индустрии Web3 за последний год, исследовал причины этих событий и способы их предотвращения, суммировал распространенные уязвимости смарт-контрактов и меры предосторожности, а также дал некоторые советы по безопасности для проектировщиков и обычных пользователей.
Распространенные типы уязвимостей в Децентрализованных финансах включают в себя флеш-кредиты, манипуляции с ценами, проблемы с правами доступа в функциях, произвольные внешние вызовы, проблемы с функцией обратного вызова, уязвимости бизнес-логики, утечку приватных ключей, повторные атаки и т.д. Ниже мы подробно рассмотрим три типа: флеш-кредиты, манипуляции с ценами и повторные атаки.
Долгосрочный займ
Флеш-займ сам по себе является инновацией в области Децентрализованных финансов, но когда его используют хакеры, они могут занять большие суммы денег без затрат, вернуть их после завершения арбитража, заплатив только небольшую сумму за Gas, чтобы получить огромную прибыль.
В последние два года проблемы с займом на один день стали частыми. Некоторые проекты выглядят так, словно они приносят высокую доходность, но на самом деле уровень команд проекта сильно варьируется. Даже если код сам по себе не содержит уязвимостей, логически все равно могут быть проблемы. Например, некоторые проекты будут выдавать вознаграждения в фиксированное время на основе количества токенов, удерживаемых держателями, но злоумышленники могут использовать займ на один день, чтобы приобрести большое количество токенов и получить большую часть вознаграждения, когда выдаются награды. Есть также проекты, которые рассчитывают цену на основе токенов, и их можно повлиять с помощью займа на один день. Команды проекта должны быть бдительны к этим проблемам.
Манипуляции с ценами
Проблема манипуляции ценами тесно связана с займами под мгновенные кредиты, которые делятся на два основных типа:
При расчете цены используются данные третьих сторон, но неправильное использование или отсутствие проверки приводят к мошенническому манипулированию ценами.
Используйте количество токенов на некоторых адресах в качестве вычисляемой переменной, при этом баланс токенов на этих адресах может временно увеличиваться или уменьшаться.
Атака повторного входа
Одной из основных опасностей вызова внешних контрактов является то, что они могут захватить управление потоком и внести неожиданные изменения в данные, вызывая функции.
Существует множество способов повторного входа для различных контрактов, которые могут быть выполнены с использованием различных функций контракта или функций нескольких различных контрактов, поэтому при решении проблемы повторного входа необходимо обратить внимание на следующее:
Не только предотвращает проблемы повторного входа для одной функции
Следуйте модели Checks-Effects-Interactions при кодировании
Используйте проверенный временем модификатор защиты от повторного входа
Больше всего боюсь повторного изобретения колеса, когда нужно что-то писать самостоятельно. В этой сфере существует множество лучших практик безопасности, которые мы можем использовать, и совершенно нет необходимости изобретать колесо заново. Когда вы создаете колесо, оно не прошло достаточную проверку, и вероятность возникновения проблем в этот момент, очевидно, гораздо выше, чем у очень зрелого, проверенного временем решения.
Рекомендации по безопасности
Советы по безопасности для проектной команды
Разработка контрактов должна соответствовать лучшим практикам безопасности.
Контракты могут быть обновлены и приостановлены: многие атаки не происходят за один раз, когда все монеты переводятся, а выполняются в несколько транзакций. Если есть относительно надежный механизм мониторинга, это можно обнаружить. Если контракт может быть приостановлен после обнаружения, это может эффективно снизить потери.
Использование временного замка: если есть временной замок, предположим, что он должен быть завершен в течение 48 часов, в это время многие смогут заметить, что создатель обновил метод mint, который могут использовать все. Наблюдатели поймут, что проект может быть взломан, и могут уведомить команду проекта о необходимости изменений. Даже если уведомили, никто ничего не делает, по крайней мере, можно сначала вывести свою часть денег, чтобы гарантировать, что свои доходы не понесут убытки. Таким образом, если у проекта нет временного замка, теоретически это увеличивает вероятность возникновения проблем.
Увеличьте инвестиции в безопасность, создайте完善ную систему безопасности: безопасность не является одной точкой или одной линией, безопасность — это система. Не думайте, что если проект прошел аудит несколькими компаниями, то с ним все в порядке, нужно учитывать различные риски, которые могут привести к потерям средств. Необходимо постараться провести моделирование рисков, а затем постепенно минимизировать большинство рисков, оставшиеся риски также должны быть приемлемыми, в пределах допустимого. Безопасность и эффективность невозможно совместить, необходимо делать определенные компромиссы. Но если полностью игнорировать безопасность и не вкладывать в нее ресурсы, то атака будет вполне нормальным явлением.
Повышение уровня безопасности среди всех сотрудников: повышение осведомленности о безопасности не требует много технологий. В этой ситуации, если просто немного больше спрашивать "почему" и немного больше думать, можно избежать многих проблем.
Предотвращение внутренних злоупотреблений, одновременно повышая эффективность и улучшая управление рисками: например, необходимо учитывать, является ли владелец контракта одиночным или множественным, используется ли временная блокировка и т.д.
Безопасность третьих сторон: как часть экосистемы, у проектов всегда есть свои подрядчики и заказчики. В безопасности существует принцип "по умолчанию все подрядчики и заказчики небезопасны". Необходимо проводить проверки как для подрядчиков, так и для заказчиков. Мы с трудом можем контролировать третьи стороны, фактически риск безопасности здесь особенно велик, поэтому нужно очень внимательно относиться к привлечению третьих сторон. Контракт является открытым исходным кодом, его можно использовать и вызывать; если контракт не является открытым исходным кодом, его абсолютно нельзя использовать.
Как пользователю/пулю ликвидности определить, безопасен ли смарт-контракт?
Для обычных пользователей, определение безопасности проекта в основном основывается на следующих шести пунктах:
Является ли контракт открытым: мы решительно не касаемся проектов с закрытыми контрактами, потому что мы не можем знать, что написано в контракте.
Является ли владелец многофакторным, децентрализован ли многофакторный подход: если не используется многофакторный подход, мы не можем оценить бизнес-логику и содержание проекта, и в случае возникновения инцидента безопасности невозможно определить, был ли он вызван хакером. Даже если используется многофакторный подход, необходимо проверить, является ли он децентрализованным.
Существующая торговая ситуация по контракту: особенно на рынке много проектов, занимающихся фишингом, которые могут создать довольно похожий контракт. В этом случае нам нужно обратить внимание на время развертывания контракта, количество взаимодействий и т. д. Все эти факторы являются критериями для оценки безопасности контракта.
Является ли контракт代理ным, можно ли его обновлять, есть ли временная блокировка: если контракт полностью не подлежит обновлению, он слишком жесткий, поэтому я все же рекомендую, чтобы контракты проектов можно было обновлять. Однако обновление должно быть обоснованным: когда обновление содержит важные изменения или изменения ключевых параметров, необходимо установить временную блокировку, чтобы дать всем время оценить, действительно ли обновление вредно или полезно для пользователей, это также является способом обеспечения открытости и прозрачности.
Принимал ли контракт аудит от нескольких организаций ( не стоит слепо доверять аудиторским компаниям ), слишком ли велики права владельца: во-первых, не следует доверять только одной аудиторской компании, так как разные аудиторские компании и разные аудиторы смотрят на проблему с разных точек зрения. Во-вторых, нужно проверить, не слишком ли велики права владельца. У нормального проекта права владельца должны быть контролируемыми, чтобы не было слишком много опасных операций, а операции также должны осуществляться с помощью временной блокировки, чтобы пользователи знали, какие операции выполняются.
Обратите внимание на оракулы: если проект использует ведущие оракулы на рынке, в основном не будет больших проблем, но если используется созданный собственный оракул или оракул, в который можно просто внести некоторые токены для подачи цен, тогда стоит насторожиться. Если вы обнаружите, что оракул может иметь некоторые проблемы или существует вероятность манипуляции, даже если доходность проекта очень высокая, участвовать нельзя.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
9 Лайков
Награда
9
5
Поделиться
комментарий
0/400
BrokeBeans
· 07-22 12:06
Да, эти Срочные займы очень прибыльные, жаль, что я не умею...
Посмотреть ОригиналОтветить0
LayerZeroHero
· 07-22 06:59
Снова Срочные займы оказались под прицелом? Неудивительно.
Посмотреть ОригиналОтветить0
P2ENotWorking
· 07-19 19:46
Чтобы зарабатывать деньги, нужно знать, как защититься от уязвимостей.
Посмотреть ОригиналОтветить0
ConsensusBot
· 07-19 19:42
Кошелек сначала установите, а затем Торговля криптовалютой
Посмотреть ОригиналОтветить0
LiquidityWizard
· 07-19 19:27
Старый пес в индустрии, профессионал в белых шляпах
Анализ распространенных уязвимостей безопасности в Децентрализованных финансах: предотвращение Срочных займов, манипуляций с ценами и повторных атак.
Децентрализованные финансы Общие уязвимости безопасности и меры предосторожности
В последнее время один из экспертов по безопасности провел урок безопасности DeFi для членов сообщества. Он обсудил крупные инциденты безопасности, произошедшие в индустрии Web3 за последний год, исследовал причины этих событий и способы их предотвращения, суммировал распространенные уязвимости смарт-контрактов и меры предосторожности, а также дал некоторые советы по безопасности для проектировщиков и обычных пользователей.
Распространенные типы уязвимостей в Децентрализованных финансах включают в себя флеш-кредиты, манипуляции с ценами, проблемы с правами доступа в функциях, произвольные внешние вызовы, проблемы с функцией обратного вызова, уязвимости бизнес-логики, утечку приватных ключей, повторные атаки и т.д. Ниже мы подробно рассмотрим три типа: флеш-кредиты, манипуляции с ценами и повторные атаки.
Долгосрочный займ
Флеш-займ сам по себе является инновацией в области Децентрализованных финансов, но когда его используют хакеры, они могут занять большие суммы денег без затрат, вернуть их после завершения арбитража, заплатив только небольшую сумму за Gas, чтобы получить огромную прибыль.
В последние два года проблемы с займом на один день стали частыми. Некоторые проекты выглядят так, словно они приносят высокую доходность, но на самом деле уровень команд проекта сильно варьируется. Даже если код сам по себе не содержит уязвимостей, логически все равно могут быть проблемы. Например, некоторые проекты будут выдавать вознаграждения в фиксированное время на основе количества токенов, удерживаемых держателями, но злоумышленники могут использовать займ на один день, чтобы приобрести большое количество токенов и получить большую часть вознаграждения, когда выдаются награды. Есть также проекты, которые рассчитывают цену на основе токенов, и их можно повлиять с помощью займа на один день. Команды проекта должны быть бдительны к этим проблемам.
Манипуляции с ценами
Проблема манипуляции ценами тесно связана с займами под мгновенные кредиты, которые делятся на два основных типа:
При расчете цены используются данные третьих сторон, но неправильное использование или отсутствие проверки приводят к мошенническому манипулированию ценами.
Используйте количество токенов на некоторых адресах в качестве вычисляемой переменной, при этом баланс токенов на этих адресах может временно увеличиваться или уменьшаться.
Атака повторного входа
Одной из основных опасностей вызова внешних контрактов является то, что они могут захватить управление потоком и внести неожиданные изменения в данные, вызывая функции.
Существует множество способов повторного входа для различных контрактов, которые могут быть выполнены с использованием различных функций контракта или функций нескольких различных контрактов, поэтому при решении проблемы повторного входа необходимо обратить внимание на следующее:
Не только предотвращает проблемы повторного входа для одной функции
Следуйте модели Checks-Effects-Interactions при кодировании
Используйте проверенный временем модификатор защиты от повторного входа
Больше всего боюсь повторного изобретения колеса, когда нужно что-то писать самостоятельно. В этой сфере существует множество лучших практик безопасности, которые мы можем использовать, и совершенно нет необходимости изобретать колесо заново. Когда вы создаете колесо, оно не прошло достаточную проверку, и вероятность возникновения проблем в этот момент, очевидно, гораздо выше, чем у очень зрелого, проверенного временем решения.
Рекомендации по безопасности
Советы по безопасности для проектной команды
Разработка контрактов должна соответствовать лучшим практикам безопасности.
Контракты могут быть обновлены и приостановлены: многие атаки не происходят за один раз, когда все монеты переводятся, а выполняются в несколько транзакций. Если есть относительно надежный механизм мониторинга, это можно обнаружить. Если контракт может быть приостановлен после обнаружения, это может эффективно снизить потери.
Использование временного замка: если есть временной замок, предположим, что он должен быть завершен в течение 48 часов, в это время многие смогут заметить, что создатель обновил метод mint, который могут использовать все. Наблюдатели поймут, что проект может быть взломан, и могут уведомить команду проекта о необходимости изменений. Даже если уведомили, никто ничего не делает, по крайней мере, можно сначала вывести свою часть денег, чтобы гарантировать, что свои доходы не понесут убытки. Таким образом, если у проекта нет временного замка, теоретически это увеличивает вероятность возникновения проблем.
Увеличьте инвестиции в безопасность, создайте完善ную систему безопасности: безопасность не является одной точкой или одной линией, безопасность — это система. Не думайте, что если проект прошел аудит несколькими компаниями, то с ним все в порядке, нужно учитывать различные риски, которые могут привести к потерям средств. Необходимо постараться провести моделирование рисков, а затем постепенно минимизировать большинство рисков, оставшиеся риски также должны быть приемлемыми, в пределах допустимого. Безопасность и эффективность невозможно совместить, необходимо делать определенные компромиссы. Но если полностью игнорировать безопасность и не вкладывать в нее ресурсы, то атака будет вполне нормальным явлением.
Повышение уровня безопасности среди всех сотрудников: повышение осведомленности о безопасности не требует много технологий. В этой ситуации, если просто немного больше спрашивать "почему" и немного больше думать, можно избежать многих проблем.
Предотвращение внутренних злоупотреблений, одновременно повышая эффективность и улучшая управление рисками: например, необходимо учитывать, является ли владелец контракта одиночным или множественным, используется ли временная блокировка и т.д.
Безопасность третьих сторон: как часть экосистемы, у проектов всегда есть свои подрядчики и заказчики. В безопасности существует принцип "по умолчанию все подрядчики и заказчики небезопасны". Необходимо проводить проверки как для подрядчиков, так и для заказчиков. Мы с трудом можем контролировать третьи стороны, фактически риск безопасности здесь особенно велик, поэтому нужно очень внимательно относиться к привлечению третьих сторон. Контракт является открытым исходным кодом, его можно использовать и вызывать; если контракт не является открытым исходным кодом, его абсолютно нельзя использовать.
Как пользователю/пулю ликвидности определить, безопасен ли смарт-контракт?
Для обычных пользователей, определение безопасности проекта в основном основывается на следующих шести пунктах:
Является ли контракт открытым: мы решительно не касаемся проектов с закрытыми контрактами, потому что мы не можем знать, что написано в контракте.
Является ли владелец многофакторным, децентрализован ли многофакторный подход: если не используется многофакторный подход, мы не можем оценить бизнес-логику и содержание проекта, и в случае возникновения инцидента безопасности невозможно определить, был ли он вызван хакером. Даже если используется многофакторный подход, необходимо проверить, является ли он децентрализованным.
Существующая торговая ситуация по контракту: особенно на рынке много проектов, занимающихся фишингом, которые могут создать довольно похожий контракт. В этом случае нам нужно обратить внимание на время развертывания контракта, количество взаимодействий и т. д. Все эти факторы являются критериями для оценки безопасности контракта.
Является ли контракт代理ным, можно ли его обновлять, есть ли временная блокировка: если контракт полностью не подлежит обновлению, он слишком жесткий, поэтому я все же рекомендую, чтобы контракты проектов можно было обновлять. Однако обновление должно быть обоснованным: когда обновление содержит важные изменения или изменения ключевых параметров, необходимо установить временную блокировку, чтобы дать всем время оценить, действительно ли обновление вредно или полезно для пользователей, это также является способом обеспечения открытости и прозрачности.
Принимал ли контракт аудит от нескольких организаций ( не стоит слепо доверять аудиторским компаниям ), слишком ли велики права владельца: во-первых, не следует доверять только одной аудиторской компании, так как разные аудиторские компании и разные аудиторы смотрят на проблему с разных точек зрения. Во-вторых, нужно проверить, не слишком ли велики права владельца. У нормального проекта права владельца должны быть контролируемыми, чтобы не было слишком много опасных операций, а операции также должны осуществляться с помощью временной блокировки, чтобы пользователи знали, какие операции выполняются.
Обратите внимание на оракулы: если проект использует ведущие оракулы на рынке, в основном не будет больших проблем, но если используется созданный собственный оракул или оракул, в который можно просто внести некоторые токены для подачи цен, тогда стоит насторожиться. Если вы обнаружите, что оракул может иметь некоторые проблемы или существует вероятность манипуляции, даже если доходность проекта очень высокая, участвовать нельзя.