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