Voitot:
- Kyky tunnistaa yleisiä haavoittuvuusmalleja, kuten sisäänpääsy, kulunvalvonta, oraakkelin manipulointi ja etukäyttäytyminen, ja skannata ne staattisella analyysityökalulla + tekoäly + ihminen
- Kyky erottaa tekoälyn vahvuudet työkalun tulosten selittämisessä sekä väärien positiivisten ja heikkouksien priorisoinnissa MEV:ssä ja liiketoimintalogiikassa
- Ymmärrä, että "puhdas tarkistus" ei ole suojausvarmenne, vaan että skannaus on vain yksi ohjaustaso
Näimme tarkastuksen kokonaisvaltaisen kurinalaisuuden edellisessä yksikössä. Tässä osiossa keskitymme teknisempään aiheeseen: haavoittuvuusskannaus — tunnettujen haavoittuvuusmallien järjestelmällinen etsiminen koodista. Täällä käytämme tekoälyä yhdessä staattisten analyysityökalujen kanssa avustajana, joka skannaa ja kuvaa tunnettuja haavoittuvuusmalleja. Tavoitteena on tutustua yleisimpiin haavoittuvuuksiin perusteellisesti ja erottaa missä tekoäly on luotettava ja missä riittämätön niiden skannauksessa.
Staattinen ja dynaaminen skannaus
Skannausta on kahta tyyppiä. Staattinen analyysi — koodin tutkiminen ilman sitä: Slitherin ja Mythrilin kaltaiset työkalut skannaavat sopimuskoodin ja merkitsevät tunnetut kuviot. Dynaaminen/symbolinen analyysi (koodin ajaminen eri syötteillä tai sen tutkiminen matemaattisesti): fuzzing (pommittaminen satunnaisella syötteellä) ja symbolinen suoritus (kaikkien mahdollisten polkujen tutkiminen) kuuluvat tähän ryhmään.
Tekoäly ei korvaa näitä työkaluja, vaan täydentää niitä: kun ajoneuvo antaa varoituksen, tekoäly selittää varoituksen selkeällä kielellä; Tekoäly voi muistuttaa, kun työkalu ei tunnista kuviota; Mutta tekoäly ei yksin voi taata, kuinka paljon se skannaa. Oikea työnkulku: työkalu + tekoäly + ihminen.
Vinkki: Anna tekoälylle staattisen analyysityökalun tulos (esim. Slither-raportti) ja kysy "selitä jokainen hälytys selkeällä kielellä, mitkä ovat todellisia riskejä ja mitkä voivat olla vääriä positiivisia?" kysyä. Tekoäly on korvaamaton tehtäessä raakatyökalujen tuotosta ymmärrettävää ja priorisoitavaa ihmisille.
Yleisimmät haavoittuvuusmallit
1. Paluu. Jos toiminto kutsuu ulkoista sopimusta päivittämättä sen tilaa, kutsuttu sopimus voi palata takaisin, käynnistää saman toiminnon uudelleen ja nostaa rahaston useita kertoja. Ratkaisu: tarkastukset-vaikutukset-vuorovaikutusjärjestys ja paluusuoja.
2. Kulunvalvonnan puute. Kriittinen toiminto (nosto, nosto, päivitys) tulee vahingossa julkiseksi. Se on yksi yleisimmistä ja kalliimmista virheistä.
3. Oraakkelin manipulointi. Sopimuksen sokea riippuvuus ulkoisesta hintalähteestä (oraakkeli). Hyökkääjä manipuloi hintaa välittömästi ja pettää protokollaa. Ratkaisu: aikapainotettu keskihinta (TWAP), monilähde.
4. Kokonaisluvun ylivuoto/alipudotus. Kun luku ylittää suurimman sallitun arvon ja palaa alkuun. Modern Solidity saa suurimman osan siitä automaattisesti, mutta riski jää matalan tason (kokoonpano)koodiin.
5. Etujuoksu. Tapahtumat näkyvät julkisessa poolissa (mempool) ennen kuin ne on vahvistettu; Hyökkääjä voi nähdä tapahtumasi ja lisätä oman tapahtumansa sen eteen. MEV (Maximal Extractable Value — tapahtumasarjasta erotettu arvo) on tämän aiheen yleinen nimi.
6. Palvelunesto (DoS). Silmukasta tulee liian kallis ja tekee funktiosta käyttökelvottoman tai riippuvuus osoitteesta lukkiutuu.
7. Päivitysriskit. Tallennustörmäys ja vallan väärinkäyttö päivitettävissä sopimuksissa.
haavoittuvuus
AI-skannauksen luottamus
Miksi?
paluuta
korkea
Tunnettu, selkeä kuvio
kulunvalvonta
korkea
Muotti voidaan skannata
Kokonaislukuoperaatiot
korkea
standardi ohjaus
Oraakkelin manipulointi
keskikokoinen
Vaatii kontekstin
Etujuoksu/MEV
Keski-matala
protokollakohtainen
liikelogiikkavirhe
alhainen
Aito, kontekstuaalinen
Heikko kehote / Vahva kehote
Heikko kehote:
Onko tässä koodissa porsaanreikä?
Tehokas kehotus:
Tehtäväsi: turvatarkastusassistentti. Tarkista alla olevasta sopimuksesta seuraavat tunnetut mallit ja "riskissä/ei/epävarma" jokaiselle: paluu, kulunvalvonta, kokonaislukutoiminnot, oracleriippuvuus, etukäteiskäyttö, DoS, päivityssuojaus. Yhdistä jokainen määritys asiaankuuluvaan riviin ja selitä, miksi riski on olemassa. Nämä ovat hypoteeseja, jotka VARMISTETAAN staattisen analyysityökalun ja auditoijan avulla. Huomaa, että voi olla vääriä positiivisia tuloksia.
Neljä kopioitavaa mallia
1) Työkalun tulosteen kuvaus:
Alla on staattisen analyysityökalun (Slither) raportti. Selitä jokainen hälytys selkeällä kielellä: mitä se tarkoittaa, onko se todellinen riski vai mahdollinen väärä positiivinen tulos, minkä pitäisi olla sen prioriteetti? Älä tee lujaa päätöstä; Priorisoi tilintarkastajan vahvistus.
2) Palautumiseen keskittyvä seulonta:
Etsi tästä sopimuksesta kaikki ulkopuheluita soittavat toiminnot. Tarkista, noudatetaanko jokaisen kohdalla tarkastukset-vaikutukset-vuorovaikutusjärjestystä ja onko olemassa paluusuojaa. Näytä riskialttiit viivalla. Merkitse, jos et ole varma; Luodaan hyväksikäyttökoodia.
3) Kulunvalvontakartta:
Luettele kaikki ulkoiset/julkiset toiminnot tässä sopimuksessa ja määritä "kuka voi soittaa" (kaikki/omistaja/rooli) jokaiselle. Suorita kriittiset toiminnot (peruuta, tulosta, päivitä) ja merkitse ne, joilla on heikko pääsy. Esitä se taulukon kanssa.
4) Väärä positiivinen eliminointi:
Mieti, miksi tämä tarkistusvaroitus ei ehkä ole TOdellinen riski (väärä positiivinen): mikä konteksti tai koodin ehto mitätöisi tämän varoituksen? Mutta älä sano "ei ole mitään ongelmaa"; Listaa kohdat, jotka tarvitsevat vahvistusta.
Kolme minikoteloa (numeroina)
Tapaus 1 – Ajoneuvo + tekoäly kaksinkertaisti tehokkuuden. Yksi tiimi ajoi Slitheriä 12 sopimusprojektissa ja sai 140 varoitusta. Kun saimme tekoälyn selittämään ja priorisoimaan hälytykset, kävi ilmi, että 95 140 hälytyksestä oli vääriä positiivisia; Tiimi keskittyi 45 todelliseen ehdokkaaseen. Triage-aika lyheni 2 päivästä 5 tuntiin. Oppitunti: AI on tehokas inhimillistämään ajoneuvojen tehoa.
Tapaus 2 – AI kaappasi MEV:n. DEX-sopimuksessa (hajautettu vaihto) tekoäly havaitsi vakiomallit puhtaina, mutta ei havainnut edessä olevaa haavoittuvuutta; koska tämä liittyi protokollan toimintajärjestykseen. Ihmisten tarkastaja ja simulaatio kuvattu. Oppitunti: Protokollakohtaiset riskit, kuten MEV/front-running, ovat tekoälyn heikko alue.
Tapaus 3 – Aikaa ei hukattu väärään positiiviseen tulokseen. Ryhmä säästyi turhalta uudelleenkirjoitukselta, kun tekoäly selitti, että paluuvaroitus oli itse asiassa väärä positiivinen (toiminto oli jo vartioitu). Mutta tiimi vahvisti sen silti yhdellä testillä. Oppitunti: AI priorisoi; Vahvistus tulee jälleen testauksen myötä.
Skannauksen rajat
Skannaus löytää tunnetut kuviot. Työkalu tai tekoäly eivät takaa uuden, ainutlaatuisen tai protokollakohtaisen haavoittuvuuden havaitsemista. Siksi seulonta on osa auditointia; ei itseään. Ajatus, että "skannaus on puhdas, joten se tarkoittaa, että se on turvallinen" on yksi vaarallisimmista väärinkäsityksistä tällä alalla. Ruoppaus poimii matalalla roikkuvat hedelmät; Syvissä ja ainutlaatuisissa riskeissä inhimillinen asiantuntemus, testaus, fuzzing ja muodollinen auditointi ovat välttämättömiä.
Varoitus: Skannaustyökalun tai tekoälyn "puhdas" raportti ei ole suojausvarmenne. Sen esittäminen tällä tavalla - erityisesti sijoittajille - on harhaanjohtavaa ja epäeettistä.
Yleisiä virheitä
- Seulonnan korvaaminen tarkastuksella. Skannaus on yksi kerros, ei koko.
- Tekoälyn käyttö ilman työkaluja. Staattinen analyysi + tekoäly + ihmisen työ yhdessä.
- Väärien positiivisten tulosten poistaminen ilman vahvistusta. Jokainen näyttö on testattu/ihmisvahvistettu.
- Protokollakohtaisten riskien (MEV) ohittaminen luottamalla tekoälyyn. AI:n heikko alue.
- Ajattelemalla "puhdas skannaus" = "turvallinen". Se ei löydä tuntematonta.
- Luodaan hyväksikäyttökoodia. Vain puolustava riskikuvaus on laillinen.
Yhteenvetona
- Haavoittuvuusskannaus etsii tunnettuja haavoittuvuusmalleja ajoneuvolla + tekoälyllä + ihmisellä.
- Tekoäly selittää ja priorisoi staattisen analyysityökalun tuotoksia tehokkaasti.
- Luotettava selkeissä kuvioissa, kuten sisäänpääsy ja kulunvalvonta; Heikko MEV:ssä ja liikelogiikassa.
- Jopa väärien positiivisten tulosten poistaminen vaatii vahvistusta.
- "Puhdas skannaus" ei ole suojausvarmenne; Se ei korvaa valvontaa.
Sovellustehtävä
Suorita staattinen analyysityökalu mallisopimukselle (jos mahdollista) tai etsi valmis Slither-raportti. Käytä "työkalun tulosteen kuvaus" -kehotetta tekoälyyn. Arvioi, onko tekoäly: (1) selittää varoitukset oikein, (2) onko järkevää erottaa väärät positiiviset tulokset ja (3) ohittaako protokollakohtaisen riskin. Täytä taulukon sarakkeet "ajoneuvo löydetty / tekoäly selitetty / ihmisen vahvistama".
tarkistuslista
- [ ] Sijoitin luukun säätimen kerrokseksi.
- [ ] Käytin staattista analyysityökalua + tekoälyä + ihmistä yhdessä.
- [ ] Etsin tunnettuja malleja luokittain.
- [ ] Poistin väärät positiiviset vahvistuksella.
- [ ] Luotin ihmisiin heikoilla alueilla, kuten MEV/liiketoiminnan logiikassa.
- [ ] En tarjonnut "puhdasta pyyhkäisyä" vakuutukseksi.
- [ ] Työskentelin vain puolustustarkoituksiin; En luonut hyväksikäyttöjä.