Прибыль:
- Способность распознавать общие шаблоны уязвимостей, такие как повторный вход, контроль доступа, манипулирование оракулом и опережающее выполнение, и сканировать их с помощью инструмента статического анализа + искусственный интеллект + человек.
- Способность различать сильные стороны ИИ при объяснении результатов работы инструмента и определении приоритетов ложных срабатываний и слабых мест в MEV и бизнес-логике.
- Поймите, что «чистое сканирование» — это не сертификат безопасности, что сканирование — это всего лишь один уровень контроля.
В предыдущем разделе мы видели целостную дисциплину одитинга. В этом модуле мы сосредоточимся на более технической теме: сканировании уязвимостей — систематическом поиске известных шаблонов уязвимостей в коде. Здесь мы будем использовать ИИ вместе с инструментами статического анализа в качестве помощника, который сканирует и описывает известные шаблоны уязвимостей. Цель: глубже узнать наиболее распространенные уязвимости и отличить, где ИИ надежен, а где он неадекватен при их сканировании.
Статическое и динамическое сканирование
Сканирование бывает двух типов. Статический анализ — проверка кода без его запуска. Такие инструменты, как Slither и Mythril, сканируют код контракта и отмечают известные шаблоны. В эту группу попадают динамический/символический анализ (запуск кода с различными входными данными или его математическое исследование): фаззинг (бомбардировка случайными входными данными) и символическое выполнение (исследование всех возможных путей).
ИИ не заменяет эти инструменты, а дополняет их: когда автомобиль выдает предупреждение, ИИ объясняет предупреждение простым языком; ИИ может напомнить, когда инструмент пропускает закономерность; Но сам по себе ИИ не может гарантировать, сколько он сканирует. Правильный рабочий процесс: инструмент + ИИ + человек.
Совет: дайте ИИ выходные данные инструмента статического анализа (например, отчета Slither) и попросите «объясните каждое предупреждение простым языком, какие риски представляют собой реальные риски, а какие могут быть ложными срабатываниями?» просить. ИИ имеет неоценимое значение для того, чтобы сделать необработанные результаты инструментов понятными и приоритетными для людей.
Наиболее распространенные шаблоны уязвимостей
1. Реентерабельность. Если функция вызывает внешний контракт без обновления его состояния, вызванный контракт может вернуться назад, снова вызвать ту же функцию и вывести средства несколько раз. Решение: порядок проверок-эффектов-взаимодействий и защита повторного входа.
2. Отсутствие контроля доступа. Критическая функция (вывод, вывод, обновление) случайно обнародована. Это одна из самых распространенных и дорогостоящих ошибок.
3. Манипулирование Oracle. Слепая зависимость контракта от внешнего источника цен (оракула). Злоумышленник мгновенно манипулирует ценой и обманывает протокол. Решение: средневзвешенная по времени цена (TWAP), из нескольких источников.
4. Целочисленное переполнение/недополнение. Когда число превышает максимально допустимое значение и возвращается в начало. Современная Solidity ловит большую часть этого автоматически, но риск остается в низкоуровневом (ассемблерном) коде.
5. Опережающее движение. Транзакции появляются в публичном пуле (мемпуле) до того, как они будут подтверждены; Злоумышленник может увидеть вашу транзакцию и вставить перед ней свою собственную транзакцию. MEV (Maximal Extractable Value — значение, извлекаемое из последовательности транзакций) — общее название этого субъекта.
6. Отказ в обслуживании (DoS). Цикл становится слишком дорогим и делает функцию непригодной для использования, или зависимость от адреса блокируется.
7. Риски обновления. Коллизия хранилищ и злоупотребление полномочиями в обновляемых контрактах.
уязвимость
Доверие к сканированию ИИ
Почему
повторный вход
высокий
Известная, понятная закономерность
контроль доступа
высокий
Плесень можно сканировать
Целочисленные операции
высокий
стандартное управление
Манипулирование Oracle
средний
Требуется контекст
Опережающий/MEV
Средне-низкий
специфичный для протокола
ошибка бизнес-логики
низкий
Аутентичный, контекстуальный
Слабая подсказка / Сильная подсказка
Слабая подсказка:
Есть ли лазейка в этом коде?
Мощная подсказка:
Ваша роль: помощник по досмотру. Просканируйте контракт ниже на наличие следующих известных шаблонов и «под угрозой/нет/не уверен» для каждого: повторный вход, контроль доступа, целочисленные операции, зависимость от оракула, опережающий запуск, DoS, безопасность обновления. Свяжите каждое определение с соответствующей строкой и объясните, почему существует риск. Это гипотезы, которые БУДУТ ПРОВЕРЕНЫ с помощью инструмента статического анализа и аудитора. Обратите внимание, что могут быть ложные срабатывания.
Четыре копируемых шаблона
1) Описание выходных данных инструмента:
Ниже представлен отчет инструмента статического анализа (Slither). Объясните каждое оповещение доступным языком: что оно означает, является ли это реальным риском или возможным ложным срабатыванием, каков должен быть его приоритет? Не принимайте твердого решения; Отдайте приоритет подтверждению аудитора.
2) Скрининг, ориентированный на реентерабельность:
Найдите в этом контракте все функции, которые выполняют внешние вызовы. Проверьте, соблюдается ли для каждого из них порядок проверки-эффекты-взаимодействия и имеется ли защита повторного входа. Покажите рискованные линии линией. Отметьте, если не уверены; Генерация кода эксплойта.
3) Карта контроля доступа:
Перечислите все внешние/публичные функции в этом контракте и укажите для каждой «кто может звонить» (каждый/владелец/роль). Выполняйте критически важные операции (изъятие, печать, обновление) и отмечайте операции со слабым контролем доступа. Представьте это в виде таблицы.
4) Ложноположительное исключение:
Подумайте, почему это предупреждение сканирования не может быть РЕАЛЬНЫМ риском (ложное срабатывание): какой контекст или условие кода сделают это предупреждение недействительным? Но не говорите: «Проблемы абсолютно нет»; Перечислите пункты, которые нуждаются в подтверждении.
Три мини-кейса (в цифрах)
Случай 1 — Транспортное средство + ИИ удвоили эффективность. Одна команда запустила Slither на проекте с 12 контрактами и получила 140 предупреждений. Как только мы попросили ИИ объяснить и расставить приоритеты оповещений, оказалось, что 95 из 140 оповещений были ложноположительными; Команда сосредоточилась на 45 реальных кандидатах. Время сортировки сократилось с 2 дней до 5 часов. Урок: искусственный интеллект способен сделать автомобиль более гуманным.
Случай 2 — ИИ захватил MEV. В контракте DEX (децентрализованная биржа) ИИ нашел стандартные шаблоны чистыми, но не смог обнаружить уязвимость; потому что это было специфично для порядка операций протокола. Человек-аудитор и симуляция захвачены. Урок: специфичные для протокола риски, такие как MEV/опережание, являются слабым местом ИИ.
Случай 3 — удалось избежать траты времени на ложное срабатывание. Команда была избавлена от ненужной переписывания, когда ИИ объяснил, что предупреждение о повторном входе на самом деле было ложным срабатыванием (функция уже была защищена). Но команда все же подтвердила это единственным тестом. Урок: ИИ расставляет приоритеты; Подтверждение снова приходит с тестированием.
Ограничения сканирования
Сканирование находит известные закономерности. Ни инструмент, ни ИИ не могут гарантированно обнаружить новую, уникальную или специфичную для протокола уязвимость. Таким образом, проверка является частью аудита; не он сам. Идея о том, что «скан чистый, значит, безопасный» — одно из самых опасных заблуждений в этой области. Дноуглубительные работы подбирают низко висящие плоды; Для глубоких и уникальных рисков необходимы человеческий опыт, тестирование, фаззинг и формальный аудит.
Внимание: «чистый» отчет сканирующего инструмента или искусственного интеллекта не является сертификатом безопасности. Представление этого таким образом – особенно инвесторам – вводит в заблуждение и неэтично.
Распространенные ошибки
- Замена скрининга осмотру. Сканирование — это один слой, а не весь.
- Использование ИИ без инструментов. Статический анализ + ИИ + работа человека вместе.
- Устранение ложных срабатываний без подтверждения. Каждый экран протестирован/проверен человеком.
- Обход рисков, связанных с протоколом (MEV), с помощью искусственного интеллекта. Слабое место ИИ.
- Думая «чистое сканирование» = «безопасно». Он не может найти неизвестное.
- Генерация кода эксплойта. Правомерно только описание защитного риска.
В заключение
- Сканирование уязвимостей ищет известные шаблоны уязвимостей с использованием транспортного средства + ИИ + человека.
- ИИ обладает мощными возможностями для объяснения и определения приоритетности результатов инструмента статического анализа.
- Надежность в четких шаблонах, таких как повторный вход и контроль доступа; Слаб в MEV и бизнес-логике.
- Даже исключение ложных срабатываний требует подтверждения.
- «Чистое сканирование» не является сертификатом безопасности; Это не замена надзору.
Задача приложения
Запустите инструмент статического анализа на образце контракта (если возможно) или найдите готовый отчет Slither. Примените подсказку «Описание выходных данных инструмента» к AI. Оцените, действительно ли ИИ: (1) правильно объясняет предупреждения, (2) имеет смысл различать ложные срабатывания и (3) упускает риск, специфичный для протокола. Заполните столбцы «Автомобиль найден/объяснено ИИ/подтверждено человеком» в таблице.
контрольный список
- [ ] Я расположил штриховку как слой элемента управления.
- [ ] Я использовал инструмент статического анализа + искусственный интеллект + человека вместе.
- [ ] Я искал известные шаблоны по категориям.
- [ ] Я исключил ложные срабатывания с подтверждением.
- [ ] Я полагался на людей в слабых областях, таких как MEV/бизнес-логика.
- [ ] Я не предлагал «чистую очистку» в качестве гарантии.
- [ ] Я работал только в целях обороны; Я не создавал эксплойты.