Gevinster:
- Evne til at genkende almindelige sårbarhedsmønstre såsom reentrancy, adgangskontrol, orakelmanipulation og front-running og scanne dem med et statisk analyseværktøj + kunstig intelligens + menneskelig
- Evne til at skelne mellem AI-styrker ved at forklare værktøjsoutput og prioritere falske positiver og svagheder i MEV og forretningslogik
- Forstå, at en 'ren scanning' ikke er et sikkerhedscertifikat, at scanning kun er ét kontrollag
Vi så den holistiske disciplin revision i den forrige enhed. I denne enhed fokuserer vi på et mere teknisk emne: sårbarhedsscanning — den systematiske søgning efter kendte sårbarhedsmønstre i kode. Her vil vi bruge AI, sammen med statiske analyseværktøjer, som en assistent, der scanner og beskriver kendte sårbarhedsmønstre. Målet: at lære de mest almindelige sårbarheder i dybden at kende og skelne, hvor AI er pålidelig, og hvor den er utilstrækkelig til at scanne dem.
Statisk og dynamisk scanning
Scanning er af to typer. Statisk analyse - undersøgelse af koden uden at køre den: Værktøjer som Slither og Mythril scanner kontraktkoden og markerer kendte mønstre. Dynamisk/symbolsk analyse (køre koden med forskellige input eller udforske den matematisk): fuzzing (bombardering med tilfældig input) og symbolsk eksekvering (udforskning af alle mulige stier) falder ind under denne gruppe.
AI erstatter ikke disse værktøjer, det supplerer dem: når køretøjet udsender en advarsel, forklarer AI advarslen i et klart sprog; AI kan minde, når værktøjet savner et mønster; Men AI alene kan ikke garantere, hvor meget den scanner. Den rigtige arbejdsgang: værktøj + AI + menneske.
Tip: Giv AI'en output fra et statisk analyseværktøj (f.eks. Slither-rapport) og spørg "forklar hver advarsel på et almindeligt sprog, hvilke er reelle risici, og hvilke kan være falske positive?" spørge. AI er uvurderlig til at gøre råværktøjsoutput forståeligt og prioriteret for mennesker.
Mest almindelige sårbarhedsmønstre
1. Genindtræden. Hvis en funktion kalder en ekstern kontrakt uden at opdatere dens tilstand, kan den kaldte kontrakt gå tilbage, udløse den samme funktion igen og trække fonden ud flere gange. Løsning: checks-effects-interactions order og reentrancy guard.
2. Manglende adgangskontrol. En kritisk funktion (tilbagetrækning, tilbagetrækning, opgradering) bliver ved et uheld offentliggjort. Det er en af de mest almindelige og dyre fejl.
3. Oracle manipulation. Kontraktens blinde afhængighed af en ekstern priskilde (oracle). Angriberen manipulerer prisen øjeblikkeligt og bedrager protokollen. Løsning: tidsvægtet gennemsnitspris (TWAP), multi-source.
4. Heltalsoverløb/underfald. Når et tal overstiger den maksimalt tilladte værdi og vender tilbage til begyndelsen. Modern Solidity fanger det meste automatisk, men risikoen forbliver i lav-niveau (samlings) kode.
5. Frontløbende. Transaktioner vises i den offentlige pulje (mempool), før de bekræftes; Angriberen kan se din transaktion og indsætte sin egen transaktion foran den. MEV (Maximal Extractable Value — værdien udtrukket fra transaktionssekvensen) er det generelle navn på dette emne.
6. Denial of Service (DoS). En løkke bliver for dyr og gør funktionen ubrugelig, eller en afhængighed af en adresse bliver låst.
7. Opgraderingsrisici. Lagerkollision og misbrug af autoritet i kontrakter, der kan opgraderes.
sårbarhed
AI scanning tillid
Hvorfor
genindtræden
høj
Velkendt, tydeligt mønster
adgangskontrol
høj
Skimmelsvamp kan scannes
Heltalsoperationer
høj
standard kontrol
Oracle manipulation
medium
Kræver kontekst
Frontløbende/MEV
Medium-Lav
protokolspecifik
forretningslogik fejl
lav
Autentisk, kontekstuel
Svag prompt / Stærk prompt
Svag prompt:
Er der et smuthul i denne kode?
Kraftig prompt:
Din rolle: sikkerhedsscreeningsassistent. Scan kontrakten nedenfor for følgende kendte mønstre og "i fare/ingen/usikker" for hver: genindtræden, adgangskontrol, heltalsoperationer, orakelafhængighed, front-running, DoS, opgraderingssikkerhed. Knyt hver bestemmelse til den relevante linje og forklar, hvorfor der er en risiko. Disse er hypoteser, som VIL blive VERIFICERET med et statisk analyseværktøj og auditor. Bemærk, at der kan være falske positiver.
Fire kopierbare skabeloner
1) Beskrivelse af værktøjsoutput:
Nedenfor er rapporten fra et statisk analyseværktøj (Slither). Forklar hver advarsel i almindeligt sprog: hvad betyder det, er det en reel risiko eller en mulig falsk positiv, hvad skal den prioriteres? Tag ikke en fast beslutning; Prioriter til revisorbekræftelse.
2) Reentrancy-fokuseret screening:
Find alle funktioner, der foretager eksterne opkald i denne kontrakt. Undersøg om checks-effects-interactions-rækkefølgen følges for hver af dem, og om der er en reentrancy-vagt. Vis de risikable med en streg. Marker, hvis du ikke er sikker; Generering af udnyttelseskode.
3) Adgangskontrolkort:
Angiv alle eksterne/offentlige funktioner i denne kontrakt og angiv "hvem kan ringe" (alle/ejer/rolle) for hver. Udfør kritiske operationer (træk tilbage, udskriv, opgrader) og marker dem med svag adgangskontrol. Præsenter det med et bord.
4) Falsk positiv eliminering:
Overvej hvorfor denne scanningsadvarsel måske ikke er en RIGTIG risiko (falsk positiv): hvilken kontekst eller kodebetingelse ville ugyldiggøre denne advarsel? Men sig ikke "der er absolut intet problem"; Angiv de punkter, der skal bekræftes.
Tre minisager (i antal)
Case 1 — Køretøj + AI fordoblet effektivitet. Et hold kørte Slither på et 12-kontraktsprojekt og modtog 140 advarsler. Da vi havde fået AI til at forklare og prioritere advarslerne, viste det sig, at 95 af de 140 advarsler var falske positive; Holdet fokuserede på 45 rigtige kandidater. Triage-tiden faldt fra 2 dage til 5 timer. Lektion: AI er stærk til at humanisere køretøjets output.
Case 2 - AI kaprede MEV. I en DEX-kontrakt (decentraliseret udveksling) fandt AI standardmønstrene rene, men kunne ikke opdage en frontløbende sårbarhed; fordi dette var specifikt for protokollens rækkefølge af operationer. Menneskelig auditor og simulering fanget. Lektion: Protokolspecifikke risici som MEV/front-running er AI's svage område.
Case 3 — Undgået at spilde tid på en falsk positiv. Holdet blev skånet for en unødvendig omskrivning, da AI’en forklarede, at en advarsel om genindtræden faktisk var en falsk positiv (funktionen var allerede bevogtet). Men holdet bekræftede det alligevel med en enkelt test. Lektion: AI prioriterer; Bekræftelse kommer igen med test.
Begrænsninger for scanning
Scanningen finder kendte mønstre. Hverken værktøjet eller AI kan med garanti opdage en ny, unik eller protokolspecifik sårbarhed. Derfor er screening en del af revisionen; ikke sig selv. Ideen om, at "scanningen er ren, så det betyder, at den er sikker" er en af de farligste misforståelser på dette felt. Uddybning samler de lavthængende frugter op; For dybe og unikke risici er menneskelig ekspertise, test, fuzzing og formel revision afgørende.
Forsigtig: En "ren" rapport om et scanningsværktøj eller AI er ikke et sikkerhedscertifikat. At præsentere det på den måde - især for investorer - er vildledende og uetisk.
Almindelige fejl
- Erstatning af screening for inspektion. Scanning er ét lag, ikke hele.
- Bruger AI uden værktøjer. Statisk analyse + AI + menneskeligt arbejde sammen.
- Eliminering af falske positiver uden bekræftelse. Hver skærm er testet/menneskeverificeret.
- Omgå protokolspecifikke risici (MEV) ved at stole på AI. AI's svage område.
- Tænker "ren scanning" = "sikker". Den kan ikke finde det ukendte.
- Generering af udnyttelseskode. Kun defensiv risikobeskrivelse er legitim.
Sammenfattende
- Sårbarhedsscanning leder efter kendte sårbarhedsmønstre med køretøj + AI + menneske.
- AI er stærk til at forklare og prioritere output fra statiske analyseværktøjer.
- Pålidelig i klare mønstre såsom reentrancy og adgangskontrol; Svag i MEV og forretningslogik.
- Selv eliminering af falske positiver kræver bekræftelse.
- En "ren scanning" er ikke et sikkerhedscertifikat; Det er ikke en erstatning for supervision.
Ansøgningsopgave
Kør et statisk analyseværktøj på en prøvekontrakt (hvis muligt), eller find en færdiglavet Slither-rapport. Anvend "værktøjsoutputbeskrivelse"-prompten på AI'en. Evaluer, om AI'en: (1) forklarer advarsler korrekt, (2) giver mening til at skelne mellem falske positive og (3) går glip af en protokolspecifik risiko. Udfyld kolonnerne "Fundet køretøj / AI forklaret / bekræftet af mennesker" i en tabel.
tjekliste
- [ ] Jeg placerede lugen som et lag af kontrollen.
- [ ] Jeg brugte statisk analyseværktøj + AI + menneske sammen.
- [ ] Jeg søgte kategori for kategori efter kendte mønstre.
- [ ] Jeg eliminerede falske positiver med bekræftelse.
- [ ] Jeg stolede på mennesker i svage områder såsom MEV/forretningslogik.
- [ ] Jeg tilbød ikke "clean sweep" som sikkerhed.
- [ ] Jeg arbejdede kun til forsvarsformål; Jeg skabte ikke bedrifter.