Zyski:
- Umiejętność rozpoznawania typowych wzorców podatności, takich jak ponowne wejście, kontrola dostępu, manipulacja Oracle i front-running, oraz skanowanie ich za pomocą narzędzia do analizy statycznej + sztuczna inteligencja + człowiek
- Umiejętność rozróżniania mocnych stron sztucznej inteligencji w wyjaśnianiu wyników działania narzędzia oraz ustalaniu priorytetów fałszywych alarmów i słabych punktów w MEV i logice biznesowej
- Zrozum, że „czyste skanowanie” nie jest certyfikatem bezpieczeństwa, a skanowanie to tylko jeden poziom kontroli
Holistyczną dyscyplinę audytu widzieliśmy już w poprzedniej jednostce. W tej jednostce skupiamy się na bardziej technicznym temacie: skanowaniu podatności — systematycznym wyszukiwaniu znanych wzorców podatności w kodzie. Tutaj wykorzystamy sztuczną inteligencję wraz z narzędziami do analizy statycznej jako asystenta skanującego i opisującego znane wzorce podatności. Cel: dogłębne poznanie najczęstszych luk w zabezpieczeniach i rozróżnienie, gdzie sztuczna inteligencja jest niezawodna, a gdzie niewystarczająca w ich skanowaniu.
Skanowanie statyczne i dynamiczne
Skanowanie jest dwojakiego rodzaju. Analiza statyczna — badanie kodu bez jego uruchamiania: Narzędzia takie jak Slither i Mythril skanują kod kontraktu i oznaczają znane wzorce. Do tej grupy zaliczają się analiza dynamiczna/symboliczna (uruchamianie kodu z różnymi danymi wejściowymi lub eksploracja go matematycznie): fuzzing (bombardowanie losowymi danymi wejściowymi) i wykonanie symboliczne (badanie wszystkich możliwych ścieżek).
Sztuczna inteligencja nie zastępuje tych narzędzi, lecz je uzupełnia: gdy pojazd wydaje ostrzeżenie, sztuczna inteligencja wyjaśnia ostrzeżenie prostym językiem; Sztuczna inteligencja może przypomnieć, kiedy narzędzie pominie wzór; Jednak sama sztuczna inteligencja nie może zagwarantować, ile skanuje. Właściwy przepływ pracy: narzędzie + sztuczna inteligencja + człowiek.
Wskazówka: przekaż AI wyniki narzędzia analizy statycznej (np. raport Slithera) i poproś „wyjaśnij każdy alert prostym językiem, które stanowią rzeczywiste ryzyko, a które mogą być fałszywie pozytywne?” zapytać. Sztuczna inteligencja jest nieoceniona, ponieważ sprawia, że surowe narzędzia są zrozumiałe i nadają się do priorytetowego traktowania przez ludzi.
Najczęstsze wzorce podatności
1. Ponowne wejście. Jeśli funkcja wywoła kontrakt zewnętrzny bez aktualizacji jego stanu, wywołany kontrakt może wrócić, ponownie uruchomić tę samą funkcję i wielokrotnie wypłacić fundusz. Rozwiązanie: sprawdza kolejność interakcji i efekt ponownego wejścia.
2. Brak kontroli dostępu. Funkcja krytyczna (wycofanie, wycofanie, aktualizacja) zostaje przypadkowo upubliczniona. Jest to jeden z najczęstszych i kosztownych błędów.
3. Manipulacja Oracle. Ślepe poleganie kontraktu na zewnętrznym źródle cen (wyrocznia). Osoba atakująca natychmiast manipuluje ceną i oszukuje protokół. Rozwiązanie: średnia cena ważona w czasie (TWAP), wiele źródeł.
4. Przekroczenie/niedobór liczby całkowitej. Gdy liczba przekracza maksymalną dozwoloną wartość i powraca na początek. Modern Solidity przechwytuje większość z nich automatycznie, ale ryzyko pozostaje w kodzie niskiego poziomu (asemblera).
5. Bieganie do przodu. Transakcje pojawiają się w puli publicznej (mempool) przed ich potwierdzeniem; Osoba atakująca może zobaczyć Twoją transakcję i umieścić przed nią własną transakcję. MEV (Maximal Extractable Value – wartość wyodrębniona z sekwencji transakcji) to ogólna nazwa tego tematu.
6. Odmowa usługi (DoS). Pętla staje się zbyt kosztowna i sprawia, że funkcja staje się bezużyteczna lub zależność od adresu zostaje zablokowana.
7. Ryzyko aktualizacji. Kolizja w zakresie przechowywania i nadużycie władzy w umowach z możliwością aktualizacji.
podatność
Zaufanie do skanowania AI
Dlaczego
ponowne wejście
wysoki
Znany, wyraźny wzór
kontrola dostępu
wysoki
Formę można zeskanować
Operacje na liczbach całkowitych
wysoki
standardowe sterowanie
Manipulacja Oracle
średni
Wymaga kontekstu
Bieg do przodu/MEV
Średnio-niski
specyficzne dla protokołu
błąd logiki biznesowej
niski
Autentyczny, kontekstowy
Słaba zachęta/silna zachęta
Słaba zachęta:
Czy w tym kodzie jest luka?
Potężny monit:
Twoja rola: asystent kontroli bezpieczeństwa. Zeskanuj poniższą umowę pod kątem następujących znanych wzorców i „zagrożony/nie/niepewny” dla każdego z nich: ponowne wejście, kontrola dostępu, operacje na liczbach całkowitych, zależność od Oracle, front-running, DoS, aktualizacja zabezpieczeń. Połącz każde ustalenie z odpowiednią linią i wyjaśnij, dlaczego istnieje ryzyko. Są to hipotezy, które ZOSTANĄ WERYFIKOWANE za pomocą narzędzia do analizy statycznej i audytora. Należy pamiętać, że mogą wystąpić fałszywe alarmy.
Cztery szablony do kopiowania
1) Opis wyjścia narzędzia:
Poniżej znajduje się raport narzędzia do analizy statycznej (Slither). Wyjaśnij każdy alert prostym językiem: co oznacza, czy stanowi realne ryzyko, czy może jest fałszywie pozytywny, jaki powinien być jego priorytet? Nie podejmuj zdecydowanej decyzji; Ustal priorytety dla potwierdzenia przez audytora.
2) Badania przesiewowe skoncentrowane na ponownym wejściu:
Znajdź w tym kontrakcie wszystkie funkcje, które wykonują połączenia zewnętrzne. Sprawdź, czy dla każdego z nich zachowana jest kolejność kontroli-efektów-interakcji i czy istnieje zabezpieczenie przed ponownym wejściem. Wskaż ryzykowne linią. Zaznacz, jeśli nie jesteś pewien; Generowanie kodu exploita.
3) Mapa kontroli dostępu:
Wymień wszystkie funkcje zewnętrzne/publiczne w tej umowie i określ, „kto może dzwonić” (wszyscy/właściciel/rola) dla każdej z nich. Wykonuj krytyczne operacje (wycofaj, wydrukuj, uaktualnij) i oznacz te, które mają słabą kontrolę dostępu. Przedstaw go za pomocą tabeli.
4) Fałszywie pozytywna eliminacja:
Zastanów się, dlaczego to ostrzeżenie o skanowaniu może nie stanowić PRAWDZIWEGO ryzyka (fałszywie pozytywne): jaki kontekst lub warunek kodu unieważniłby to ostrzeżenie? Ale nie mów „nie ma absolutnie żadnego problemu”; Wymień punkty wymagające potwierdzenia.
Trzy mini etui (w liczbach)
Przypadek 1 — Pojazd + sztuczna inteligencja podwoiła wydajność. Jeden zespół prowadził Slithera w ramach projektu obejmującego 12 kontraktów i otrzymał 140 ostrzeżeń. Kiedy sztuczna inteligencja wyjaśniła alerty i nadała im priorytety, okazało się, że 95 ze 140 alertów było fałszywie pozytywnych; Zespół skupił się na 45 realnych kandydatach. Czas segregacji skrócił się z 2 dni do 5 godzin. Lekcja: sztuczna inteligencja ma potężną moc w humanizowaniu wydajności pojazdów.
Przypadek 2 — AI przejęła MEV. W kontrakcie DEX (zdecentralizowana wymiana) sztuczna inteligencja uznała standardowe wzorce za czyste, ale nie wykryła wyprzedzającej luki; ponieważ było to specyficzne dla kolejności działań protokołu. Przechwycono audytora ludzkiego i symulację. Lekcja: Zagrożenia specyficzne dla protokołu, takie jak MEV/wbieganie na front, to słaby obszar sztucznej inteligencji.
Przypadek 3 — Uniknięto marnowania czasu na fałszywie pozytywny wynik. Zespołowi oszczędzono niepotrzebnego przepisywania, gdy sztuczna inteligencja wyjaśniła, że ostrzeżenie o ponownym wejściu było w rzeczywistości fałszywym alarmem (funkcja była już strzeżona). Zespół i tak potwierdził to jednym testem. Lekcja: AI ustala priorytety; Ponowne potwierdzenie następuje wraz z testowaniem.
Granice skanowania
Skanowanie wykrywa znane wzorce. Ani narzędzie, ani sztuczna inteligencja nie gwarantują wykrycia nowej, unikalnej lub specyficznej dla protokołu luki. Dlatego też kontrola jest częścią audytu; nie on sam. Pogląd, że „skan jest czysty, więc oznacza, że jest bezpieczny” jest jednym z najniebezpieczniejszych błędnych przekonań w tej dziedzinie. Pogłębianie podnosi nisko wiszące owoce; W przypadku głębokich i unikalnych ryzyk niezbędna jest wiedza specjalistyczna, testowanie, fuzzing i formalny audyt.
Uwaga: „czysty” raport narzędzia skanującego lub sztucznej inteligencji nie jest certyfikatem bezpieczeństwa. Prezentowanie tego w ten sposób – zwłaszcza inwestorom – jest mylące i nieetyczne.
Typowe błędy
- Zastąpienie kontroli badaniem przesiewowym. Skanowanie to jedna warstwa, a nie całość.
- Korzystanie ze sztucznej inteligencji bez narzędzi. Analiza statyczna + sztuczna inteligencja + wspólna praca człowieka.
- Eliminowanie fałszywych alarmów bez potwierdzenia. Każdy ekran jest testowany/weryfikowany przez człowieka.
- Omijanie ryzyka specyficznego dla protokołu (MEV) poprzez poleganie na sztucznej inteligencji. Słaby obszar AI.
- Myślenie „czysty skan” = „bezpieczny”. Nie może znaleźć nieznanego.
- Generowanie kodu exploita. Uzasadniony jest jedynie opis ryzyka defensywnego.
Podsumowując
- Skanowanie podatności wyszukuje znane wzorce podatności na pojazd + sztuczną inteligencję + człowiek.
- Sztuczna inteligencja skutecznie wyjaśnia i ustala priorytety wyników narzędzia analizy statycznej.
- Niezawodność w przypadku przejrzystych wzorców, takich jak ponowne wejście i kontrola dostępu; Słaby w MEV i logice biznesowej.
- Nawet wyeliminowanie fałszywych alarmów wymaga potwierdzenia.
- „Czyste skanowanie” nie jest certyfikatem bezpieczeństwa; Nie zastępuje nadzoru.
Zadanie aplikacji
Uruchom narzędzie do analizy statycznej na przykładowej umowie (jeśli to możliwe) lub znajdź gotowy raport Slithera. Zastosuj monit „opis wyników narzędzia” do AI. Oceń, czy sztuczna inteligencja: (1) poprawnie wyjaśnia ostrzeżenia, (2) ma sens w rozróżnianiu fałszywych alarmów oraz (3) pomija ryzyko specyficzne dla protokołu. Wypełnij kolumny „znaleziono pojazd / wyjaśniono sztuczną inteligencję / potwierdzono obecność człowieka” w tabeli.
lista kontrolna
- [ ] Umieściłem kreskowanie jako warstwę kontrolki.
- [ ] Użyłem razem narzędzia do analizy statycznej + AI + człowiek.
- [ ] Przeszukałem kategorię po kategorii w poszukiwaniu znanych wzorców.
- [ ] Wyeliminowałem fałszywe alarmy z potwierdzeniem.
- [ ] Polegałem na ludziach w słabych obszarach, takich jak MEV/logika biznesowa.
- [ ] Nie oferowałem „czystego czyszczenia” jako zapewnienia.
- [ ] Pracowałem wyłącznie w celach obronnych; Nie stworzyłem exploitów.