Печалби:
- Възможност за разпознаване на често срещани модели на уязвимост като повторно влизане, контрол на достъпа, манипулация на оракул и първоначално изпълнение и сканиране с инструмент за статичен анализ + изкуствен интелект + човек
- Способност за разграничаване между силните страни на AI при обясняване на резултатите от инструмента и приоритизиране на фалшиви положителни резултати и слабости в MEV и бизнес логиката
- Разберете, че „чистото сканиране“ не е сертификат за сигурност, че сканирането е само едно ниво на контрол
Видяхме холистичната дисциплина на одита в предишния раздел. В този раздел ние се фокусираме върху по-техническа тема: сканиране на уязвимости — систематично търсене на известни модели на уязвимости в кода. Тук ще използваме AI, заедно с инструменти за статичен анализ, като помощник, който сканира и описва известни модели на уязвимости. Целта: да се запознаят в дълбочина с най-често срещаните уязвимости и да се разграничи къде AI е надежден и къде е неадекватен при сканирането им.
Статично и динамично сканиране
Сканирането е два вида. Статичен анализ — изследване на кода, без да го стартирате: Инструменти като Slither и Mythril сканират кода на договора и маркират известни модели. Динамичен/символичен анализ (пускане на кода с различни входове или математическо изследване): размиване (бомбардиране с произволен вход) и символно изпълнение (проучване на всички възможни пътища) попадат в тази група.
AI не замества тези инструменти, той ги допълва: когато превозното средство издава предупреждение, AI обяснява предупреждението на ясен език; AI може да напомня, когато инструментът пропусне модел; Но AI сам по себе си не може да гарантира колко сканира. Правилният работен процес: инструмент + AI + човек.
Съвет: Дайте на AI изхода на инструмент за статичен анализ (напр. Slither report) и попитайте „обяснете всеки сигнал на обикновен език, кои са реални рискове и кои може да са фалшиви положителни резултати?“ попитайте. Изкуственият интелект е безценен, за да направи суровия резултат от инструмента разбираем и приоритетен за хората.
Най-често срещаните модели на уязвимост
1. Повторно влизане. Ако функция извика външен договор, без да актуализира състоянието си, извиканият договор може да се върне, да задейства отново същата функция и да изтегли фонда няколко пъти. Решение: проверки-ефекти-ред на взаимодействията и защита при повторно влизане.
2. Липса на контрол на достъпа. Критична функция (теглене, теглене, надграждане) случайно се оповестява публично. Това е една от най-честите и скъпи грешки.
3. Манипулация на Oracle. Сляпото разчитане на договора на външен ценови източник (оракул). Нападателят манипулира цената незабавно и заблуждава протокола. Решение: претеглена във времето средна цена (TWAP), множество източници.
4. Целочислено препълване/подминаване. Когато дадено число превиши максимално допустимата стойност и се връща в началото. Modern Solidity улавя повечето от тях автоматично, но рискът остава в кода на ниско ниво (сглобяване).
5. Предно бягане. Транзакциите се появяват в публичния пул (mempool), преди да бъдат потвърдени; Нападателят може да види вашата транзакция и да вмъкне своя собствена транзакция пред нея. MEV (Максимална стойност за извличане — стойността, извлечена от последователността на транзакцията) е общото име на този обект.
6. Отказ от услуга (DoS). Цикълът става твърде скъп и прави функцията неизползваема или зависимостта от адрес става заключена.
7. Рискове при надграждане. Сблъсък при съхранение и злоупотреба с правомощия в надграждащи се договори.
уязвимост
AI сканиране доверие
защо
повторно влизане
високо
Добре познат, ясен модел
контрол на достъпа
високо
Мухълът може да се сканира
Целочислени операции
високо
стандартен контрол
Манипулация на Oracle
среден
Изисква контекст
Предно движение/MEV
Средно-Нисък
специфичен за протокола
грешка в бизнес логиката
ниско
Автентичен, контекстуален
Слаба подкана / Силна подкана
Слаба подкана:
Има ли вратичка в този код?
Мощна подкана:
Вашата роля: асистент за проверка на сигурността. Сканирайте договора по-долу за следните известни модели и „изложен на риск/не/несигурен“ за всеки: повторно влизане, контрол на достъпа, операции с цели числа, зависимост от оракул, изпреварване, DoS, защита при надграждане. Свържете всяко определение със съответния ред и обяснете защо има риск. Това са хипотези, които ЩЕ БЪДАТ ПРОВЕРЕНИ с инструмент за статичен анализ и одитор. Имайте предвид, че може да има фалшиви положителни резултати.
Четири копируеми шаблона
1) Описание на резултатите от инструмента:
По-долу е отчетът на инструмент за статичен анализ (Slither). Обяснете всеки сигнал на ясен език: какво означава, реален риск ли е или е възможен фалшив положителен сигнал, какъв трябва да бъде неговият приоритет? Не вземайте твърдо решение; Дайте приоритет на потвърждението на одитора.
2) Скрининг, фокусиран върху повторното влизане:
Намерете всички функции, които правят външни повиквания в този договор. Проверете дали редът проверки-ефекти-взаимодействия се спазва за всеки от тях и дали има защита за повторно влизане. Покажете рисковите с линия. Маркирайте, ако не сте сигурни; Генериране на експлойт код.
3) Карта за контрол на достъпа:
Избройте всички външни/публични функции в този договор и посочете „кой може да се обажда“ (всеки/собственик/роля) за всяка. Извършвайте критични операции (теглене, печат, надграждане) и маркирайте тези със слаб контрол на достъпа. Представете го с таблица.
4) Фалшиво положително елиминиране:
Помислете защо това предупреждение за сканиране може да не е РЕАЛЕН риск (фалшиво положително): какъв контекст или кодово условие би обезсилило това предупреждение? Но не казвайте „няма абсолютно никакъв проблем“; Избройте точките, които се нуждаят от потвърждение.
Три мини калъфа (в брой)
Случай 1 — Превозно средство + AI удвоена ефективност. Един отбор управлява Slither по проект с 12 договора и получава 140 предупреждения. След като накарахме AI да обясни и приоритизира сигналите, се оказа, че 95 от 140 сигнала са фалшиви положителни резултати; Екипът се фокусира върху 45 реални кандидати. Времето за сортиране намаля от 2 дни на 5 часа. Урок: AI е мощен в хуманизирането на продукцията на превозното средство.
Случай 2 — AI отвлече MEV. В договор за DEX (децентрализиран обмен) AI откри стандартните модели чисти, но не успя да открие предна уязвимост; защото това беше специфично за реда на операциите на протокола. Човешкият одитор и симулацията са заснети. Урок: Специфичните за протокол рискове като MEV/front-running са слабата област на AI.
Случай 3 — Избегнато губене на време за фалшив положителен резултат. Екипът беше спестен от ненужно пренаписване, когато AI обясни, че предупреждението за повторно влизане всъщност е фалшиво положително (функцията вече е била защитена). Но екипът все пак го потвърди с един тест. Урок: AI дава приоритети; Потвърждението отново идва с тестване.
Граници на сканиране
Сканирането открива известни модели. Нито инструментът, нито изкуственият интелект са гарантирани, че ще открият нова, уникална или специфична за протокола уязвимост. Следователно проверката е част от одита; не себе си. Идеята, че „сканирането е чисто, значи е безопасно“ е едно от най-опасните погрешни схващания в тази област. Драгирането събира ниско висящите плодове; За дълбоки и уникални рискове човешкият опит, тестването, размиването и официалният одит са от съществено значение.
Внимание: „Чист“ отчет на инструмент за сканиране или AI не е сертификат за сигурност. Представянето му по този начин - особено на инвеститорите - е подвеждащо и неетично.
Често срещани грешки
- Замяна на скрининг за проверка. Сканирането е един слой, а не цялото.
- Използване на AI без инструменти. Статичен анализ + AI + човешка работа заедно.
- Елиминиране на фалшиви положителни резултати без потвърждение. Всеки екран е тестван/проверен от човек.
- Заобикаляне на специфичните за протокол рискове (MEV) чрез разчитане на AI. Слабата област на AI.
- Мислейки "чисто сканиране" = "безопасно". Не може да намери неизвестното.
- Генериране на експлойт код. Легитимно е само защитното описание на риска.
В обобщение
- Сканирането за уязвимости търси известни модели на уязвимости с превозно средство + AI + човек.
- AI е мощен при обяснението и приоритизирането на изхода на инструмента за статичен анализ.
- Надеждни в ясни модели като повторно влизане и контрол на достъпа; Слаб в MEV и бизнес логиката.
- Дори елиминирането на фалшиви положителни резултати изисква потвърждение.
- „Чистото сканиране“ не е сертификат за сигурност; Не е заместител на надзора.
Задача за приложение
Стартирайте инструмент за статичен анализ върху примерен договор (ако е възможно) или намерете готов доклад на Slither. Приложете подканата „описание на изхода на инструмента“ към AI. Оценете дали AI: (1) правилно обяснява предупрежденията, (2) има смисъл в разграничаването на фалшиви положителни резултати и (3) пропуска специфичен за протокола риск. Попълнете колоните „намерено превозно средство / обяснено с AI / потвърдено от човек“ в таблица.
контролен списък
- [ ] Позиционирах люка като слой на контролата.
- [ ] Използвах инструмент за статичен анализ + AI + човек заедно.
- [ ] Търсих категория по категория за известни модели.
- [ ] Елиминирах фалшивите положителни резултати с потвърждение.
- [ ] Разчитах на хора в слаби области като MEV/бизнес логика.
- [ ] Не предложих „чисто почистване“ като уверение.
- [ ] Работех само за отбранителни цели; Не съм създавал експлойти.