На днях одна из компаний по безопасности в области блокчейна обнаружила два серьезных уязвимости в контракте цифрового коллекционного предмета, что привлекло внимание в отрасли. Адрес этого контракта находится в основной сети Ethereum, а выявленные проблемы могут привести к блокировке активов пользователей и невозможности вывода средств командой проекта.
Первый уязвимость существует в функции обработки возврата. Эта функция выполняет возврат средств для всех пользователей в цикле, но если объект возврата является злонамеренным контрактом, он может отказать в получении и привести к откату транзакции, что приведет к провалу всего процесса возврата. К счастью, эта уязвимость на самом деле не была использована.
!
По поводу данной логики возврата, специалисты отрасли выдвинули несколько рекомендаций:
Ограничение только для внешних аккаунтов (EOA), которые могут участвовать в проекте
Используйте WETH и другие токены ERC20 вместо нативных активов
Разработать механизм, позволяющий пользователям самостоятельно запрашивать возврат средств, чтобы избежать массовых возвратов.
!
Второй уязвимость возникла из-за небрежности в написании кода. В функции извлечения средств командой проекта существует ошибка в условном операторе. Вместо того чтобы сравнивать прогресс возврата и индекс заявки, он ошибочно сравнивается с общим количеством заявок. Это приводит к тому, что условие никогда не может быть выполнено, и средства команды проекта (более 34 миллионов долларов) навсегда заблокированы в контракте.
!
Это событие снова вызвало беспокойство в отрасли по поводу безопасности проектов цифровых коллекционных предметов. В области децентрализованных финансов (DeFi) безопасность аудита стала обычной практикой, но в проектах цифровых коллекционных предметов этот этап, похоже, все еще игнорируется. Эксперты призывают команду проекта в процессе разработки составлять достаточные тестовые случаи, развивать базовую безопасность и рассмотреть возможность привлечения профессионального аудита безопасности, чтобы избежать огромных потерь из-за подобных низкоуровневых ошибок.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Контракт на цифровые коллекционные предметы Ethereum раскрыл два крупных уязвимости, 34 миллиона долларов средств заблокированы.
На днях одна из компаний по безопасности в области блокчейна обнаружила два серьезных уязвимости в контракте цифрового коллекционного предмета, что привлекло внимание в отрасли. Адрес этого контракта находится в основной сети Ethereum, а выявленные проблемы могут привести к блокировке активов пользователей и невозможности вывода средств командой проекта.
Первый уязвимость существует в функции обработки возврата. Эта функция выполняет возврат средств для всех пользователей в цикле, но если объект возврата является злонамеренным контрактом, он может отказать в получении и привести к откату транзакции, что приведет к провалу всего процесса возврата. К счастью, эта уязвимость на самом деле не была использована.
!
По поводу данной логики возврата, специалисты отрасли выдвинули несколько рекомендаций:
!
Второй уязвимость возникла из-за небрежности в написании кода. В функции извлечения средств командой проекта существует ошибка в условном операторе. Вместо того чтобы сравнивать прогресс возврата и индекс заявки, он ошибочно сравнивается с общим количеством заявок. Это приводит к тому, что условие никогда не может быть выполнено, и средства команды проекта (более 34 миллионов долларов) навсегда заблокированы в контракте.
!
Это событие снова вызвало беспокойство в отрасли по поводу безопасности проектов цифровых коллекционных предметов. В области децентрализованных финансов (DeFi) безопасность аудита стала обычной практикой, но в проектах цифровых коллекционных предметов этот этап, похоже, все еще игнорируется. Эксперты призывают команду проекта в процессе разработки составлять достаточные тестовые случаи, развивать базовую безопасность и рассмотреть возможность привлечения профессионального аудита безопасности, чтобы избежать огромных потерь из-за подобных низкоуровневых ошибок.