Gevinster:
- Evne til å gjenkjenne vanlige sårbarhetsmønstre som reentrancy, tilgangskontroll, orakelmanipulasjon og frontkjøring og skanne dem med et statisk analyseverktøy + kunstig intelligens + menneskelig
- Evne til å skille mellom AI-styrker ved å forklare verktøyutgang og prioritere falske positiver og svakheter i MEV og forretningslogikk
- Forstå at en "ren skanning" ikke er et sikkerhetssertifikat, at skanning bare er ett kontrolllag
Vi så den helhetlige disiplinen revisjon i forrige enhet. I denne enheten fokuserer vi på et mer teknisk emne: sårbarhetsskanning — det systematiske søket etter kjente sårbarhetsmønstre i kode. Her skal vi bruke AI, sammen med statiske analyseverktøy, som en assistent som skanner og beskriver kjente sårbarhetsmønstre. Målet: å bli kjent med de vanligste sårbarhetene i dybden og skille hvor AI er pålitelig og hvor den er utilstrekkelig til å skanne dem.
Statisk og dynamisk skanning
Skanning er av to typer. Statisk analyse – undersøker koden uten å kjøre den: Verktøy som Slither og Mythril skanner kontraktskoden og flagger kjente mønstre. Dynamisk/symbolsk analyse (kjøre koden med forskjellige innganger eller utforske den matematisk): fuzzing (bombardering med tilfeldig input) og symbolsk utførelse (utforsker alle mulige veier) faller inn i denne gruppen.
AI erstatter ikke disse verktøyene, den utfyller dem: når kjøretøyet avgir en advarsel, forklarer AI advarselen på et klart språk; AI kan minne når verktøyet savner et mønster; Men AI alene kan ikke garantere hvor mye den skanner. Riktig arbeidsflyt: verktøy + AI + menneske.
Tips: Gi AI-en utdata fra et statisk analyseverktøy (f.eks. Slither-rapport) og spør "forklar hvert varsel på klart språk, hvilke er reelle risikoer og hvilke kan være falske positive?" spørre. AI er uvurderlig for å gjøre råverktøyutgang forståelig og prioritert for mennesker.
De vanligste sårbarhetsmønstrene
1. Reentrancy. Hvis en funksjon kaller en ekstern kontrakt uten å oppdatere dens tilstand, kan den oppringte kontrakten gå tilbake, utløse den samme funksjonen igjen og trekke ut fondet flere ganger. Løsning: sjekk-effekter-interaksjoner ordre og reentrancy guard.
2. Mangel på adgangskontroll. En kritisk funksjon (uttak, uttak, oppgradering) blir ved et uhell offentliggjort. Det er en av de vanligste og mest kostbare feilene.
3. Oracle manipulasjon. Kontraktens blinde avhengighet av en ekstern priskilde (oracle). Angriperen manipulerer prisen umiddelbart og lurer protokollen. Løsning: tidsvektet gjennomsnittspris (TWAP), multi-source.
4. Heltalls overløp/underfall. Når et tall overskrider den maksimalt tillatte verdien og går tilbake til begynnelsen. Modern Solidity fanger opp det meste automatisk, men risikoen forblir i lavnivå (montering) kode.
5. Forangående. Transaksjoner vises i den offentlige poolen (mempool) før de bekreftes; Angriperen kan se transaksjonen din og sette inn sin egen transaksjon foran den. MEV (Maximal Extractable Value — verdien hentet fra transaksjonssekvensen) er det generelle navnet på dette emnet.
6. Denial of Service (DoS). En sløyfe blir for dyr og gjør funksjonen ubrukelig, eller en avhengighet av en adresse blir låst.
7. Oppgraderingsrisiko. Lagerkollisjon og misbruk av myndighet i oppgraderbare kontrakter.
sårbarhet
AI skanning tillit
Hvorfor
gjeninntreden
høy
Velkjent, tydelig mønster
tilgangskontroll
høy
Mugg kan skannes
Heltallsoperasjoner
høy
standard kontroll
Oracle manipulasjon
medium
Krever kontekst
Frontløp/MEV
Middels-Lav
protokollspesifikk
forretningslogikkfeil
lav
Autentisk, kontekstuell
Svak forespørsel / Sterk forespørsel
Svak melding:
Er det et smutthull i denne koden?
Kraftig ledetekst:
Din rolle: assistent for sikkerhetskontroll. Skann kontrakten nedenfor for følgende kjente mønstre og "i fare/ingen/usikker" for hver: reentrancy, tilgangskontroll, heltallsoperasjoner, oracledependency, front-running, DoS, oppgraderingssikkerhet. Knytt hver bestemmelse til den aktuelle linjen og forklar hvorfor det er en risiko. Dette er hypoteser som VIL VERIFISERES med et statisk analyseverktøy og revisor. Merk at det kan være falske positiver.
Fire kopierbare maler
1) Beskrivelse av verktøyutgang:
Nedenfor er rapporten fra et statisk analyseverktøy (Slither). Forklar hvert varsel på et klart språk: hva betyr det, er det en reell risiko eller en mulig falsk positiv, hva bør prioriteres? Ikke ta en fast beslutning; Prioriter for revisorbekreftelse.
2) Reentrancy-fokusert screening:
Finn alle funksjoner som foretar eksterne samtaler i denne kontrakten. Undersøk om kontroll-effekter-interaksjonsrekkefølgen følges for hver av dem og om det er en tilbakeføringsvakt. Vis de risikable med en strek. Merk hvis du ikke er sikker; Genererer utnyttelseskode.
3) Adgangskontrollkart:
List opp alle eksterne/offentlige funksjoner i denne kontrakten og spesifiser "hvem kan ringe" (alle/eier/rolle) for hver. Utfør kritiske operasjoner (trekk ut, skriv ut, oppgrader) og merk de med svak tilgangskontroll. Presenter det med et bord.
4) Falsk positiv eliminering:
Vurder hvorfor denne skanneadvarselen kanskje ikke er en REELL risiko (falsk positiv): hvilken kontekst eller kodebetingelse ville ugyldiggjøre denne advarselen? Men ikke si "det er absolutt ikke noe problem"; List opp punktene som trenger bekreftelse.
Tre minietuier (i antall)
Tilfelle 1 — Kjøretøy + AI doblet effektiviteten. Ett team drev Slither på et 12-kontraktsprosjekt og mottok 140 advarsler. Når vi fikk AI til å forklare og prioritere varslene, viste det seg at 95 av de 140 varslene var falske positive; Teamet fokuserte på 45 reelle kandidater. Triagetiden ble redusert fra 2 dager til 5 timer. Leksjon: AI er kraftig til å humanisere kjøretøyets produksjon.
Sak 2 – AI kapret MEV. I en DEX-kontrakt (desentralisert utveksling) fant AI standardmønstrene rene, men klarte ikke å oppdage en front-running sårbarhet; fordi dette var spesifikt for protokollens operasjonsrekkefølge. Menneskelig auditør og simulering fanget. Leksjon: Protokollspesifikke risikoer som MEV/front-running er AIs svake område.
Tilfelle 3 – Unngikk å kaste bort tid på en falsk positiv. Teamet ble spart for en unødvendig omskriving da AI forklarte at en reentrancy-advarsel faktisk var en falsk positiv (funksjonen var allerede bevoktet). Men teamet bekreftet det likevel med en enkelt test. Leksjon: AI prioriterer; Bekreftelse igjen kommer med testing.
Begrensninger for skanning
Skanningen finner kjente mønstre. Verken verktøyet eller AI er garantert å oppdage en ny, unik eller protokollspesifikk sårbarhet. Derfor er screening en del av tilsynet; ikke seg selv. Ideen om at "skanningen er ren, så det betyr at den er trygg" er en av de farligste misoppfatningene på dette feltet. Mudring plukker opp den lavthengende frukten; For dype og unike risikoer er menneskelig ekspertise, testing, fuzzing og formell revisjon avgjørende.
Forsiktig: En "ren" rapport om et skanneverktøy eller AI er ikke et sikkerhetssertifikat. Å presentere det på den måten - spesielt for investorer - er misvisende og uetisk.
Vanlige feil
- Erstatter screening for inspeksjon. Skanning er ett lag, ikke hele.
- Bruker AI uten verktøy. Statisk analyse + AI + menneskelig arbeid sammen.
- Eliminere falske positive uten bekreftelse. Hver skjerm er testet/menneskeverifisert.
- Omgå protokollspesifikke risikoer (MEV) ved å stole på AI. AIs svake område.
- Tenker "ren skanning" = "trygt". Den kan ikke finne det ukjente.
- Genererer utnyttelseskode. Bare defensiv risikobeskrivelse er legitim.
Oppsummert
- Sårbarhetsskanning ser etter kjente sårbarhetsmønstre med kjøretøy + AI + menneske.
- AI er kraftig til å forklare og prioritere utdata fra statiske analyseverktøy.
- Pålitelig i klare mønstre som reentrancy og tilgangskontroll; Svak i MEV og forretningslogikk.
- Selv eliminering av falske positiver krever bekreftelse.
- En "ren skanning" er ikke et sikkerhetssertifikat; Det er ikke en erstatning for tilsyn.
Søknadsoppgave
Kjør et statisk analyseverktøy på en prøvekontrakt (hvis mulig) eller finn en ferdig Slither-rapport. Bruk "verktøyutdatabeskrivelse" på AI-en. Vurder om AI: (1) forklarer advarsler korrekt, (2) gir mening når det gjelder å skille mellom falske positive, og (3) går glipp av en protokollspesifikk risiko. Fyll ut «kjøretøy funnet / AI forklart / menneskelig bekreftet»-kolonnene i en tabell.
sjekkliste
- [ ] Jeg plasserte luken som et lag av kontrollen.
- [ ] Jeg brukte statisk analyseverktøy + AI + menneske sammen.
- [ ] Jeg søkte kategori for kategori etter kjente mønstre.
- [ ] Jeg eliminerte falske positiver med bekreftelse.
- [ ] Jeg stolte på mennesker i svake områder som MEV/forretningslogikk.
- [ ] Jeg ga ikke "rent fei" som forsikring.
- [ ] Jeg jobbet kun for forsvarsformål; Jeg skapte ikke bedrifter.