Câștiguri:
- Capacitatea de a recunoaște tiparele comune de vulnerabilitate, cum ar fi reintrarea, controlul accesului, manipularea oracolului și avansarea și de a le scana cu un instrument de analiză statică + inteligență artificială + uman
- Abilitatea de a face distincția între punctele forte ale AI în explicarea rezultatelor instrumentului și prioritizarea falselor pozitive și a punctelor slabe în MEV și logica de afaceri
- Înțelegeți că o „scanare curată” nu este un certificat de securitate, că scanarea este doar un nivel de control
Am văzut disciplina holistică a auditului în unitatea anterioară. În această unitate, ne concentrăm pe un subiect mai tehnic: scanarea vulnerabilităților — căutarea sistematică a tiparelor de vulnerabilitate cunoscute în cod. Aici vom folosi AI, împreună cu instrumente de analiză statică, ca asistent care scanează și descrie tiparele de vulnerabilitate cunoscute. Scopul: să cunoaștem cele mai comune vulnerabilități în profunzime și să distingem unde AI este de încredere și unde este inadecvat în scanarea acestora.
Scanare statică și dinamică
Scanarea este de două tipuri. Analiză statică — examinarea codului fără a-l rula: instrumente precum Slither și Mythril scanează codul contractului și semnalează modele cunoscute. Analiza dinamică/simbolică (rularea codului cu diferite intrări sau explorarea lui matematic): fuzzing (bombardarea cu intrare aleatorie) și execuția simbolică (explorarea tuturor căilor posibile) se încadrează în acest grup.
AI nu înlocuiește aceste instrumente, le completează: atunci când vehiculul emite un avertisment, AI explică avertismentul într-un limbaj simplu; AI poate reaminti când instrumentul ratează un model; Dar AI singură nu poate garanta cât de mult scanează. Fluxul de lucru potrivit: instrument + AI + om.
Sfat: dați AI rezultatul unui instrument de analiză statică (de exemplu, raportul Slither) și întrebați „explicați fiecare alertă într-un limbaj simplu, care sunt riscuri reale și care ar putea fi fals pozitive?” intreaba. Inteligența artificială este de neprețuit pentru a face ca rezultatul instrumentelor brute să fie ușor de înțeles și prioritizat pentru oameni.
Cele mai comune modele de vulnerabilitate
1. Reintrare. Dacă o funcție apelează un contract extern fără a-și actualiza starea, contractul apelat poate reveni, declanșa din nou aceeași funcție și poate retrage fondul de mai multe ori. Soluție: verificări-efecte-interacțiuni ordine și gardă de reintrare.
2. Lipsa controlului accesului. O funcție critică (retragere, retragere, upgrade) este făcută publică accidental. Este una dintre cele mai frecvente și costisitoare greșeli.
3. Manipularea oracolului. Încrederea oarbă a contractului pe o sursă externă de preț (oracol). Atacatorul manipulează prețul instantaneu și înșală protocolul. Soluție: preț mediu ponderat în timp (TWAP), multi-sursă.
4. Integer overflow/underfall. Când un număr depășește valoarea maximă permisă și revine la început. Modern Solidity prinde cea mai mare parte automat, dar riscul rămâne în codul de nivel scăzut (asamblare).
5. Frontieră. Tranzacțiile apar în pool-ul public (mempool) înainte de a fi confirmate; Atacatorul vă poate vedea tranzacția și poate introduce propria sa tranzacție în fața acesteia. MEV (Valoarea maximă extractabilă — valoarea extrasă din secvența tranzacției) este denumirea generală a acestui subiect.
6. Denial of Service (DoS). O buclă devine prea scumpă și face funcția inutilizabilă sau dependența de o adresă devine blocată.
7. Riscuri de upgrade. Coliziunea de stocare și abuzul de autoritate în contractele care pot fi actualizate.
vulnerabilitate
Încredere în scanarea AI
De ce
reintrare
înalt
Model binecunoscut, clar
controlul accesului
înalt
Mucegaiul poate fi scanat
Operații cu numere întregi
înalt
control standard
Manipularea oracolului
mediu
Necesită context
Frontul/MEV
Mediu-Scăzut
specifice protocolului
eroare de logica de afaceri
scăzută
Autentic, contextual
Prompt slab / Prompt puternic
Prompt slab:
Există o lacună în acest cod?
Solicitare puternică:
Rolul dvs.: asistent de control de securitate. Scanați contractul de mai jos pentru următoarele modele cunoscute și „la risc/nu/nesigur” pentru fiecare: reintrare, control acces, operațiuni întregi, dependență de oracle, front-running, DoS, securitate de upgrade. Conectați fiecare determinare la linia relevantă și explicați de ce există un risc. Acestea sunt ipoteze care VOR VERIFICATE cu un instrument de analiză statică și cu un auditor. Rețineți că pot exista rezultate false pozitive.
Patru șabloane copiabile
1) Descrierea ieșirii instrumentului:
Mai jos este raportul unui instrument de analiză statică (Slither). Explicați fiecare alertă într-un limbaj simplu: ce înseamnă, este un risc real sau un posibil fals pozitiv, care ar trebui să fie prioritatea acesteia? Nu lua o decizie fermă; Acordați prioritate pentru confirmarea auditorului.
2) Screening centrat pe reintrare:
Găsiți toate funcțiile care efectuează apeluri externe în acest contract. Examinați dacă ordinea verificări-efecte-interacțiuni este urmată pentru fiecare dintre ele și dacă există o gardă de reintrare. Arătați-i pe cei riscanți cu o linie. Marcați dacă nu sunteți sigur; Generarea codului de exploatare.
3) Harta de control acces:
Listați toate funcțiile externe/publice din acest contract și specificați „cine poate apela” (toată lumea/proprietar/rol) pentru fiecare. Efectuați operațiuni critice (retragere, imprimare, upgrade) și marcați pe cele cu control de acces slab. Prezintă-l cu o masă.
4) Eliminare fals pozitivă:
Luați în considerare de ce acest avertisment de scanare ar putea să nu fie un risc REAL (fals pozitiv): ce context sau condiția codului ar invalida acest avertisment? Dar nu spune „nu există absolut nicio problemă”; Enumerați punctele care necesită confirmare.
Trei mini cutii (în cifre)
Cazul 1 — Vehicul + AI a dublat eficiența. O echipă a condus Slither pe un proiect cu 12 contracte și a primit 140 de avertismente. Odată ce am avut AI-ul să explice și să prioritizeze alertele, s-a dovedit că 95 din cele 140 de alerte au fost fals pozitive; Echipa sa concentrat pe 45 de candidați reali. Timpul de triaj a scăzut de la 2 zile la 5 ore. Lecție: Inteligența artificială este puternică în umanizarea producției vehiculelor.
Cazul 2 – AI a deturnat MEV. Într-un contract DEX (schimb descentralizat), AI a găsit modelele standard curate, dar nu a reușit să detecteze o vulnerabilitate de front; deoarece aceasta era specifică ordinii de operațiuni a protocolului. Auditor uman și simulare capturate. Lecție: Riscurile specifice protocolului, cum ar fi MEV/front-running, sunt zona slabă a AI.
Cazul 3 – S-a evitat pierderea timpului cu un fals pozitiv. Echipa a fost scutită de o rescriere inutilă când AI a explicat că un avertisment de reintrare a fost de fapt un fals pozitiv (funcția era deja protejată). Dar echipa a confirmat-o în continuare cu un singur test. Lecția: AI prioritizează; Confirmarea vine din nou odată cu testarea.
Limitele scanării
Scanarea găsește modele cunoscute. Nici instrumentul, nici AI nu sunt garantate să detecteze o vulnerabilitate nouă, unică sau specifică protocolului. Prin urmare, screening-ul face parte din audit; nu el însuși. Ideea că „scanarea este curată, deci înseamnă că este sigură” este una dintre cele mai periculoase concepții greșite în acest domeniu. Dragarea culege fructele de jos; Pentru riscuri profunde și unice, expertiza umană, testarea, fuzzing și auditul formal sunt esențiale.
Atenție: Un raport „curat” al unui instrument de scanare sau AI nu este un certificat de securitate. Prezentarea în acest fel - în special investitorilor - este înșelătoare și lipsită de etică.
Greșeli comune
- Înlocuirea screening-ului pentru inspecție. Scanarea este un strat, nu întregul.
- Folosind AI fără instrumente. Analiza statică + AI + om lucrează împreună.
- Eliminarea fals pozitive fără confirmare. Fiecare ecran este testat/verificat uman.
- Ocolind riscurile specifice protocolului (MEV) bazându-se pe AI. Zona slabă a AI.
- Gândirea „scanare curată” = „sigur”. Nu poate găsi necunoscutul.
- Generarea codului de exploatare. Doar descrierea defensivă a riscului este legitimă.
Pe scurt
- Scanarea vulnerabilităților caută modele de vulnerabilitate cunoscute cu vehicul + AI + om.
- AI este puternic în explicarea și prioritizarea rezultatelor instrumentelor de analiză statică.
- Fiabil în modele clare, cum ar fi reintrarea și controlul accesului; Slab în MEV și logica de afaceri.
- Chiar și eliminarea fals pozitive necesită confirmare.
- O „scanare curată” nu este un certificat de securitate; Nu este un substitut pentru supraveghere.
Sarcina de aplicare
Rulați un instrument de analiză statică pe un exemplu de contract (dacă este posibil) sau găsiți un raport Slither gata făcut. Aplicați promptul „descrierea ieșirii instrumentului” la AI. Evaluați dacă AI: (1) explică corect avertismentele, (2) are sens în a face distincția între false pozitive și (3) ratează un risc specific protocolului. Completați coloanele „vehicul găsit / AI explicat / om confirmat” dintr-un tabel.
lista de verificare
- [ ] Am poziționat trapa ca un strat al controlului.
- [ ] Am folosit împreună instrumentul de analiză statică + AI + om.
- [ ] Am căutat categorie după categorie pentru modele cunoscute.
- [ ] Am eliminat fals pozitive cu confirmare.
- [ ] M-am bazat pe oameni în domenii slabe, cum ar fi MEV/logica de afaceri.
- [ ] Nu am oferit „măturare curată” ca asigurare.
- [ ] Am lucrat numai în scop de apărare; Nu am creat exploit-uri.