Vinster:
- Förmåga att känna igen vanliga sårbarhetsmönster som återinträde, åtkomstkontroll, orakelmanipulation och frontrunning och skanna dem med ett statiskt analysverktyg + artificiell intelligens + mänsklig
- Förmåga att skilja mellan AI-styrkor när det gäller att förklara verktygsutdata och prioritera falska positiva och svagheter i MEV och affärslogik
- Förstå att en "ren skanning" inte är ett säkerhetscertifikat, att skanning bara är ett kontrolllager
Vi såg den holistiska disciplinen revision i den förra enheten. I den här enheten fokuserar vi på ett mer tekniskt ämne: sårbarhetsskanning — den systematiska sökningen efter kända sårbarhetsmönster i kod. Här kommer vi att använda AI, tillsammans med statiska analysverktyg, som en assistent som skannar och beskriver kända sårbarhetsmönster. Målet: att lära känna de vanligaste sårbarheterna på djupet och urskilja var AI är tillförlitlig och var den är otillräcklig för att skanna dem.
Statisk och dynamisk skanning
Skanning är av två typer. Statisk analys — undersöker koden utan att köra den: Verktyg som Slither och Mythril skannar kontraktskoden och flaggar kända mönster. Dynamisk/symbolisk analys (körning av koden med olika ingångar eller utforskar den matematiskt): fuzzing (bombardering med slumpmässig inmatning) och symbolisk exekvering (utforskar alla möjliga vägar) faller inom denna grupp.
AI ersätter inte dessa verktyg, det kompletterar dem: när fordonet utfärdar en varning förklarar AI varningen på ett enkelt språk; AI kan påminna när verktyget missar ett mönster; Men AI ensam kan inte garantera hur mycket den skannar. Rätt arbetsflöde: verktyg + AI + människa.
Tips: Ge AI:n resultatet av ett statiskt analysverktyg (t.ex. Slither-rapporten) och fråga "förklara varje varning på ett enkelt språk, vilka är verkliga risker och vilka kan vara falska positiva?" be. AI är ovärderlig för att göra råverktygsutdata begriplig och prioriterbar för människor.
De vanligaste sårbarhetsmönstren
1. Återinträde. Om en funktion anropar ett externt kontrakt utan att uppdatera dess status, kan det anropade kontraktet gå tillbaka, utlösa samma funktion igen och ta ut fonden flera gånger. Lösning: checks-effects-interactions order och reentrancy guard.
2. Brist på passerkontroll. En kritisk funktion (uttag, uttag, uppgradering) offentliggörs av misstag. Det är ett av de vanligaste och dyraste misstagen.
3. Oracle-manipulation. Kontraktets blinda tillit till en extern priskälla (oracle). Angriparen manipulerar priset direkt och lurar protokollet. Lösning: tidsvägt genomsnittspris (TWAP), multi-source.
4. Heltalsspill/underfall. När ett tal överskrider det högsta tillåtna värdet och återgår till början. Modern Solidity fångar det mesta automatiskt, men risken kvarstår i lågnivåkod (monteringskod).
5. Framåtgående. Transaktioner visas i den offentliga poolen (mempool) innan de bekräftas; Angriparen kan se din transaktion och infoga sin egen transaktion framför den. MEV (Maximal Extractable Value — värdet som extraheras från transaktionssekvensen) är det allmänna namnet på detta ämne.
6. Denial of Service (DoS). En slinga blir för dyr och gör funktionen oanvändbar, eller så blir ett beroende av en adress låst.
7. Uppgraderingsrisker. Lagerkollision och maktmissbruk i uppgraderbara kontrakt.
sårbarhet
AI-skanningsförtroende
Varför
återinträde
hög
Välkänt, tydligt mönster
åtkomstkontroll
hög
Mögel kan skannas
Heltalsoperationer
hög
standardstyrning
Oracle manipulation
medium
Kräver sammanhang
Framgående/MEV
Medium-Låg
protokollspecifikt
affärslogikfel
låg
Autentisk, kontextuell
Svag prompt / Stark prompt
Svag uppmaning:
Finns det ett kryphål i den här koden?
Kraftfull uppmaning:
Din roll: säkerhetskontrollassistent. Skanna kontraktet nedan för följande kända mönster och "i risk/no/osäker" för var och en: återinträde, åtkomstkontroll, heltalsoperationer, orakelberoende, front-running, DoS, uppgraderingssäkerhet. Koppla varje beslut till relevant linje och förklara varför det finns en risk. Detta är hypoteser som KOMMER att VERIFIERAS med ett statiskt analysverktyg och revisor. Observera att det kan finnas falska positiva resultat.
Fyra kopierbara mallar
1) Beskrivning av verktygsutgång:
Nedan är rapporten från ett statiskt analysverktyg (Slither). Förklara varje varning i klartext: vad betyder det, är det en verklig risk eller en möjlig falsk positiv, vad bör dess prioritet vara? Ta inte ett bestämt beslut; Prioritera för revisorsbekräftelse.
2) Reentrancy-fokuserad screening:
Hitta alla funktioner som gör externa samtal i detta kontrakt. Undersök om ordern för kontroller-effekter-interaktioner följs för var och en av dem och om det finns en återinträdesvakt. Visa de riskfyllda med en linje. Markera om du inte är säker; Genererar exploateringskod.
3) Tillträdeskontrollkarta:
Lista alla externa/offentliga funktioner i detta kontrakt och ange "vem kan ringa" (alla/ägare/roll) för var och en. Utför kritiska operationer (ta tillbaka, skriv ut, uppgradera) och markera dem med svag åtkomstkontroll. Presentera den med ett bord.
4) Falsk positiv eliminering:
Fundera på varför denna skanningsvarning kanske inte är en VERKLIG risk (falsk positiv): vilket sammanhang eller kodvillkor skulle ogiltigförklara denna varning? Men säg inte "det är absolut inga problem"; Lista de punkter som behöver bekräftas.
Tre minifodral (i antal)
Fall 1 — Fordon + AI fördubblad effektivitet. Ett team körde Slither på ett 12-kontraktsprojekt och fick 140 varningar. När vi fick AI att förklara och prioritera varningarna visade det sig att 95 av de 140 varningarna var falska positiva; Teamet fokuserade på 45 riktiga kandidater. Triagetiden minskade från 2 dagar till 5 timmar. Lektion: AI är kraftfull när det gäller att humanisera fordonsproduktion.
Fall 2 – AI kapade MEV. I ett DEX-kontrakt (decentraliserat utbyte) fann AI standardmönstren rena men misslyckades med att upptäcka en sårbarhet i framkant; eftersom detta var specifikt för protokollets ordningsföljd. Mänsklig auditör och simulering fångad. Lärdom: Protokollspecifika risker som MEV/front-running är AI:s svaga område.
Fall 3 — Undvek att slösa tid på ett falskt positivt. Teamet besparades en onödig omskrivning när AI:n förklarade att en återinträdesvarning faktiskt var en falsk positiv (funktionen var redan bevakad). Men laget bekräftade det ändå med ett enda test. Lektion: AI prioriterar; Bekräftelse kommer igen med testning.
Gränser för skanning
Skanningen hittar kända mönster. Varken verktyget eller AI:n är garanterat att upptäcka en ny, unik eller protokollspecifik sårbarhet. Därför är screening en del av revisionen; inte sig själv. Tanken att "skanningen är ren, så det betyder att den är säker" är en av de farligaste missuppfattningarna inom detta område. Muddring plockar upp den lågt hängande frukten; För djupa och unika risker är mänsklig expertis, testning, fuzzing och formell revision väsentliga.
Varning: En "ren" rapport om ett skanningsverktyg eller AI är inte ett säkerhetscertifikat. Att presentera det på det sättet - särskilt för investerare - är vilseledande och oetiskt.
Vanliga misstag
- Ersätter screening för inspektion. Skanning är ett lager, inte hela.
- Använder AI utan verktyg. Statisk analys + AI + mänskligt arbete tillsammans.
- Eliminera falska positiva utan bekräftelse. Varje skärm är testad/människverifierad.
- Förbigå protokollspecifika risker (MEV) genom att förlita sig på AI. AI:s svaga område.
- Tänker "ren skanning" = "säker". Den kan inte hitta det okända.
- Genererar exploateringskod. Endast defensiv riskbeskrivning är legitim.
Sammanfattningsvis
- Sårbarhetsskanning letar efter kända sårbarhetsmönster med fordon + AI + människa.
- AI är kraftfull på att förklara och prioritera utdata från statiska analysverktyg.
- Pålitlig i tydliga mönster som återinträde och åtkomstkontroll; Svag i MEV och affärslogik.
- Även eliminering av falska positiva resultat kräver bekräftelse.
- En "ren skanning" är inte ett säkerhetscertifikat; Det är inte en ersättning för tillsyn.
Applikationsuppgift
Kör ett statiskt analysverktyg på ett provkontrakt (om möjligt) eller hitta en färdig Slither-rapport. Tillämpa "verktygsutgångsbeskrivning"-prompten på AI. Utvärdera om AI:n: (1) förklarar varningar korrekt, (2) är vettigt när det gäller att skilja mellan falska positiva och (3) missar en protokollspecifik risk. Fyll i kolumnerna "fordon hittat / AI förklarad / mänsklig bekräftad" i en tabell.
checklista
- [ ] Jag placerade luckan som ett lager av kontrollen.
- [ ] Jag använde statiskt analysverktyg + AI + människa tillsammans.
- [ ] Jag sökte kategori för kategori efter kända mönster.
- [ ] Jag eliminerade falska positiva med bekräftelse.
- [ ] Jag litade på människor i svaga områden som MEV/affärslogik.
- [ ] Jag erbjöd inte "rent svep" som garanti.
- [ ] Jag arbetade endast i försvarssyfte; Jag skapade inte bedrifter.