zisky:
- Schopnost rozpoznat běžné vzorce zranitelnosti, jako je reentrancy, řízení přístupu, manipulace orákulem a front-running, a skenovat je pomocí nástroje pro statickou analýzu + umělá inteligence + člověk
- Schopnost rozlišovat mezi silnými stránkami AI při vysvětlování výstupu nástroje a upřednostňování falešně pozitivních a slabých stránek v MEV a obchodní logice
- Pochopte, že „čisté skenování“ není bezpečnostní certifikát, že skenování je pouze jednou vrstvou kontroly
Celostní disciplínu auditu jsme viděli v předchozí jednotce. V této části se zaměřujeme na techničtější téma: skenování zranitelností — systematické hledání známých vzorců zranitelnosti v kódu. Zde budeme používat AI spolu s nástroji pro statickou analýzu jako asistenta, který skenuje a popisuje známé vzorce zranitelnosti. Cíl: poznat do hloubky nejčastější zranitelnosti a rozlišit, kde je AI spolehlivá a kde je při jejich skenování nedostatečná.
Statické a dynamické skenování
Skenování je dvou typů. Statická analýza – zkoumání kódu bez jeho spouštění: Nástroje jako Slither a Mythril skenují kód smlouvy a označují známé vzory. Do této skupiny spadá dynamická/symbolická analýza (spouštění kódu s různými vstupy nebo jeho zkoumání matematicky): fuzzing (bombardování náhodným vstupem) a symbolické provádění (prozkoumávání všech možných cest).
AI tyto nástroje nenahrazuje, ale doplňuje: když vozidlo vydá varování, AI vysvětlí varování srozumitelným jazykem; Umělá inteligence může připomenout, když nástroj vynechá vzor; Ale samotná AI nemůže zaručit, kolik skenuje. Správný pracovní postup: nástroj + AI + člověk.
Tip: Poskytněte AI výstup nástroje statické analýzy (např. Slither report) a zeptejte se „vysvětlete každé upozornění srozumitelným jazykem, která jsou skutečná rizika a která by mohla být falešně pozitivní?“ požádat. Umělá inteligence je neocenitelná pro to, aby byl výstup surového nástroje pro lidi srozumitelný a prioritní.
Nejběžnější vzorce zranitelnosti
1. Reentrancy. Pokud funkce zavolá externí smlouvu, aniž by aktualizovala její stav, může se volaná smlouva vrátit zpět, znovu spustit stejnou funkci a vybrat fond vícekrát. Řešení: kontrola-efekty-pořadí interakcí a ochrana proti opětovnému vstupu.
2. Nedostatek kontroly přístupu. Kritická funkce (stažení, stažení, upgrade) je náhodně zveřejněna. Je to jedna z nejčastějších a nejdražších chyb.
3. Manipulace s Oracle. Slepá závislost smlouvy na externím cenovém zdroji (oracle). Útočník okamžitě manipuluje s cenou a oklame protokol. Řešení: časově vážená průměrná cena (TWAP), vícezdrojová.
4. Přetečení/podpad celého čísla. Když číslo překročí maximální povolenou hodnotu a vrátí se na začátek. Modern Solidity většinu z toho zachytí automaticky, ale riziko zůstává v kódu nízké úrovně (sestavení).
5. Přední běh. Transakce se objeví ve veřejném fondu (mempool) před jejich potvrzením; Útočník může vidět vaši transakci a vložit před ni svou vlastní transakci. MEV (Maximal Extrahable Value — hodnota extrahovaná z transakční sekvence) je obecný název tohoto subjektu.
6. Denial of Service (DoS). Smyčka se stává příliš drahou a činí funkci nepoužitelnou nebo se závislost na adrese zablokuje.
7. Rizika upgradu. Kolize úložiště a zneužití pravomoci u upgradovatelných smluv.
zranitelnost
Důvěra skenování AI
Proč?
opětovného vstupu
vysoká
Dobře známý, jasný vzor
řízení přístupu
vysoká
Plíseň lze skenovat
Celočíselné operace
vysoká
standardní ovládání
Oracle manipulace
střední
Vyžaduje kontext
Přední běh/MEV
Střední-Nízká
specifický pro protokol
chyba obchodní logiky
nízká
Autentické, kontextuální
Slabá výzva / Silná výzva
Slabá výzva:
Je v tomto kódu mezera?
Výkonná výzva:
Vaše role: asistent bezpečnostní kontroly. Naskenujte níže uvedenou smlouvu pro následující známé vzory a pro každý z nich „v riziku/ne/nejistě“: opakovaný vstup, řízení přístupu, celočíselné operace, závislost na oracle, front-running, DoS, zabezpečení upgradu. Propojte každé určení s příslušným řádkem a vysvětlete, proč existuje riziko. Toto jsou hypotézy, které BUDOU OVĚŘENY pomocí nástroje pro statickou analýzu a auditora. Všimněte si, že mohou existovat falešně pozitivní výsledky.
Čtyři kopírovatelné šablony
1) Popis výstupu nástroje:
Níže je uvedena zpráva o nástroji pro statickou analýzu (Slither). Vysvětlete každé upozornění srozumitelným jazykem: co to znamená, je to skutečné riziko nebo možný falešně pozitivní výsledek, jaká by měla být jeho priorita? Nedělejte pevné rozhodnutí; Upřednostněte potvrzení auditora.
2) Screening zaměřený na reentrancy:
Všechny funkce, které uskutečňují externí volání, najdete v této smlouvě. Prozkoumejte, zda je u každého z nich dodržováno pořadí kontroly-efekty-interakce a zda existuje hlídač opětovného vstupu. Ty rizikové ukažte čarou. Označte, pokud si nejste jisti; Generování exploit kódu.
3) Mapa řízení přístupu:
Uveďte všechny externí/veřejné funkce v této smlouvě a u každé uveďte „kdo může volat“ (každý/vlastník/role). Provádějte kritické operace (výběr, tisk, upgrade) a označte ty se slabým řízením přístupu. Prezentujte jej tabulkou.
4) Falešně pozitivní eliminace:
Zvažte, proč toto varování skenování nemusí představovat SKUTEČNÉ riziko (falešně pozitivní): jaký kontext nebo podmínka kódu by toto varování zrušila? Ale neříkejte „není absolutně žádný problém“; Uveďte body, které je třeba potvrdit.
Tři mini pouzdra (v číslech)
Případ 1 — Vozidlo + AI zdvojnásobila účinnost. Jeden tým provozoval Slither na projektu s 12 smlouvami a obdržel 140 varování. Jakmile jsme nechali AI vysvětlit a určit prioritu výstrah, ukázalo se, že 95 ze 140 výstrah bylo falešně pozitivních; Tým se zaměřil na 45 skutečných kandidátů. Doba třídění se zkrátila ze 2 dnů na 5 hodin. Ponaučení: Umělá inteligence je mocná při zlidšťování výkonu vozidla.
Případ 2 – AI unesla MEV. Ve smlouvě DEX (decentralized exchange) AI shledala standardní vzory čisté, ale nezjistila přední zranitelnost; protože to bylo specifické pro pořadí operací protokolu. Lidský auditor a simulace zachyceny. Ponaučení: Rizika specifická pro protokol, jako je MEV/front-runing, jsou slabou oblastí AI.
Případ 3 — Zabránění plýtvání časem na falešně pozitivní výsledek. Tým byl ušetřen zbytečného přepisování, když AI vysvětlila, že varování o opětovném vstupu bylo ve skutečnosti falešně pozitivní (funkce již byla hlídána). Tým to ale přesto potvrdil jediným testem. Lekce: AI upřednostňuje; Potvrzení opět přichází s testováním.
Limity skenování
Skenování najde známé vzory. Ani nástroj, ani umělá inteligence nezaručují detekci nové, jedinečné nebo protokolově specifické zranitelnosti. Proto je screening součástí auditu; ne on sám. Myšlenka, že "skenování je čisté, takže to znamená, že je bezpečné", je jednou z nejnebezpečnějších mylných představ v této oblasti. Bagrování zvedne nízko visící ovoce; U hlubokých a jedinečných rizik je nezbytná lidská odbornost, testování, fuzzing a formální audit.
Upozornění: „Čistá“ zpráva skenovacího nástroje nebo AI není bezpečnostní certifikát. Prezentovat to tímto způsobem – zejména investorům – je zavádějící a neetické.
Časté chyby
- Náhrada screeningu za kontrolu. Skenování je jedna vrstva, ne celek.
- Použití AI bez nástrojů. Statická analýza + AI + lidská práce společně.
- Eliminace falešně pozitivních výsledků bez potvrzení. Každá obrazovka je testována/ověřena člověkem.
- Obcházení rizik specifických pro protokol (MEV) spoléháním se na AI. Slabá oblast AI.
- Myšlení „čisté skenování“ = „bezpečné“. Nemůže najít neznámé.
- Generování exploit kódu. Pouze popis defenzivního rizika je legitimní.
V souhrnu
- Skenování zranitelnosti hledá známé vzorce zranitelnosti s vozidlem + AI + člověkem.
- AI je výkonná při vysvětlování a upřednostňování výstupu nástroje pro statickou analýzu.
- Spolehlivý v jasných vzorcích, jako je reentrancy a řízení přístupu; Slabé v MEV a obchodní logice.
- Dokonce i odstranění falešných poplachů vyžaduje potvrzení.
- "Čisté skenování" není bezpečnostní certifikát; Nenahrazuje dohled.
Aplikační úkol
Spusťte nástroj pro statickou analýzu na vzorové smlouvě (pokud je to možné) nebo najděte připravenou zprávu Slither. Použijte výzvu "tool output description" na AI. Vyhodnoťte, zda AI: (1) správně vysvětluje varování, (2) dává smysl rozlišovat mezi falešně pozitivními výsledky a (3) postrádá riziko specifické pro protokol. Vyplňte sloupce „nalezeno vozidlo / AI vysvětleno / člověk potvrzen“ v tabulce.
kontrolní seznam
- [ ] Poklop jsem umístil jako vrstvu ovládání.
- [ ] Použil jsem nástroj statické analýzy + AI + člověk dohromady.
- [ ] Hledal jsem kategorii po kategorii pro známé vzory.
- [ ] Falešné poplachy jsem vyloučil potvrzením.
- [ ] Spoléhal jsem na lidi ve slabých oblastech, jako je MEV/obchodní logika.
- [ ] Nenabízel jsem "čisté zametání" jako záruku.
- [ ] Pracoval jsem pouze pro obranné účely; Nevytvářel jsem exploity.