Nutikas lepingute turvalisus: agiilne SDLC-lähenemine 

Lugemise aeg: 10 protokoll

Blockchaini nimetatakse detsentraliseeritud ja võltsimiskindlaks pearaamatuks. Kuid see võltsimiskindel pearaamat on häkkimise ja ärakasutamise suhtes haavatav. Detsentraliseerimine, mis on Blockchaini üks tugevamaid eeliseid, on üks puudusi. 

Noh, see on hea, aga kuidas on lood SDLC-ga? 

Tarkvara elutsükli lähenemisviis, mida me arutama hakkame, põhineb nutikate lepingute turvaaukude liigitamisel mitmesse faasi. 

Esimeses osas oleme välja toonud nutikate lepingute turvaprobleemid. Ja järgmises osas käsitleme selle nelja faasi jagatud lahendusi; Turvakujundus, turbe juurutamine, testimine enne juurutamist ja viimane, jälgimine ja analüüs. 

NUTITE LEPINGUTE TURVALISUSKÜSIMUSTE ANALÜÜS 

Nutikad lepingud on haavatavad erinevate häkkimiste ja ärakasutamiste suhtes. Need lepingud, mis on sünonüümid reaalmaailma juriidilistele kokkulepetele, töötavad iseseisvalt, tuginedes algsete plokiahelate tingimustele. 

Kuid kas olete mõelnud, et isegi need kohalikud plokiahelad võivad olla vastutavad ka nutikate lepingute võimalike turvaohtude eest? Allpool tutvustame mõnda Blockchainsi omadust sama jaoks:

detsentraliseerimine: Seda peetakse plokiahelapõhiste protokollide üheks eeliseks. Kuid ründajad on välja mõelnud viisi, kuidas muuta see positiivne omadus negatiivseks. 

Pahatahtlikud osalejad võivad nutika lepingu väljatöötamiseks ja juurutamiseks luua võltsitud identiteedi. Mõnikord on haavatavat lepingut raske tuvastada, kuna avalikes plokiahelates on saadaval ainult avaliku aadressi (või) avalikud võtmed. 

Avatud lähtekoodiga kood: See võib teid üllatada, kuid jah, üldiselt on enamik nutikaid lepingukoode mõnevõrra avatud lähtekoodiga. 

Oletame, et Ethereumi virtuaalmasina (EVM) puhul on selle baitkood alati avalik. Ja mõned Solidity dekompilaatorid võivad aidata teil hankida nutika lepingu aadressi ja Solidity koodi. Lähtekoodi paljastamine muudab selle funktsiooni ründajate jaoks eeliseks. 

Arenemata plokiahela platvormid: Arendaja jaoks on esmane nõue arendusplatvormiga tutvuda. On palju vähearenenud või uusi plokiahela platvorme, mistõttu arendajad ei saa arendada plokiahela toimingute kohta sügavaid teadmisi. 

See ebakõla mõjutab nutikaid lepinguid sünkroonimise puudumise tõttu. Plokiahela platvormi vead jäävad selle pideva arengu tõttu märkamatuks. 

Tundmatud tehingud: Esimeses punktis oleme arutanud anonüümset identiteeti; samamoodi on plokiahelate tehingud avalikustamata. Tehinguid on võimatu jälgida, mis toob kaasa palju ebaseaduslikke tegevusi. Kuna tegemist on finantstehingutega, võib igasugune turvaprobleem kaasa tuua tohutu rahalise kahju. 

NUTIKAD LEPINGU TURVALISUSLAHENDUSED

Nüüd, kui aruka lepingu turvalisusega edasi minna, saame võrrelda kõiki nutika lepingu kindlustamiseks vajalikke samme selle arenguga. Nagu traditsioonilise tarkvaraarenduse puhul, kaldume järgima arenduse elutsüklit; samamoodi saame klassifitseerida lepingu arendamise elutsüklit. 

Nutika lepingu arendamise elutsükli võib jagada nelja faasi: turbekujundus, turbe juurutamine, testimine enne kasutuselevõttu ning jälgimine ja analüüs.

1. TURVADISAIN 

See esimene etapp hõlmab kolme teemat; disaini põhimõte, kujundusmuster ja turvamodelleerimine (nagu on näidatud ülaltoodud joonisel). Nende teemade põhirõhk on lepingute kavandamisel ja turvaohtude ärahoidmisel. 

DISAINITÕIME

Disainipõhimõtted on põhiideed plokiahelas turvaliste nutikate lepingute kujundamiseks. Lepingute kujundamisel on viis peamist põhimõtet: valmistuge ebaõnnestumiseks, levitage hoolikalt, hoidke lepingud lihtsad, hoidke end kursis ja Peab teadma plokiahela omadustest. 

Nüüd võite mõelda, kuidas need aitavad luua turvalise nutika lepingu? 

Võtkem üks ülaltoodud põhimõtetest, ütleme: "Valmistu ebaõnnestumiseks", see tähendab, et paigamisskeemide puudumisel peaks leping suutma reageerida vigadele. Ja kui mõni rünnak toimub, peaks leping saama peatada, et vältida edasist kahju. 

DISAINMUSTER

Tarkvarakujunduses on disainimustrid lahendused, mida saab probleemi lahendamiseks uuesti kasutada. 

Kui võtame näiteks Ethereumi, on seal kuus turvamustrit; Kontrolli mõjusid-koostoimet, hädaseiskamist, Mutex-i, kiirusepiire, kiirusepiirangut ja tasakaalupiirangut.  

Neid turbemustreid saame kasutada plokiahela turbeprobleemide lahendamiseks, nagu näiteks taassisenemise haavatavust saab käsitleda Mutexi mustriga. 

Samal ajal võib hädaseiskamismuster aidata meil lepingu täitmist lõpetada, kui seda mõjutab haavatavus. 

TURVAMODELLEERIMINE

Väljatöötatud koodi ja lepingute jaoks nõutava koodi vahel võib esineda erinevusi, kuna lepingute koostamiseks kasutatakse Solidity'i; see keel rahuldab Turingi täielikkust, kuid selles esineb vigu. 

Ülaltoodud joonis näitab, et see alamfaas hõlmab kahte faasi; turvalisuse kavandamine ja rakendamine. 

Turvamodelleerimine on otseselt seotud äriloogikaga; kuna spetsifikatsioonid on tuletatud ärist, saab loogikat klassifitseerida veatu semantika järgi. See aitab hiljem haavatavuste leevendamiseks läbiviidava ametliku kontrolliprotsessi käigus. 

2. TURVALISUSE RAKENDAMINE

Selles osas käsitleme kolmest teemast kahte; turvalisus

Arendus- ja turbemall, nagu oleme juba viimases etapis turvamodelleerimist käsitlenud.

TURVALISUSE ARENG

Selles jaotises selgitatakse, kuidas turvaauke lepingu rakendamise käigus vältida. 

Ethereumi platvormil on meil turvalisuse EIP-d (Ethereumi täiustamise ettepanekud) – soovitused turvaprobleemidega võitlemiseks. Ethereum platvorm. Seega on need EIP-d tähelepanuväärsed nutikate lepingute turvaliseks rakendamiseks. 

TURVAMALL

Mallid on uute dokumentide lähtekohaks. Tööparameetritega nutikad lepingumallid ühendavad juriidilise lepingu käivitatava koodiga. 

Nutika lepinguturbe kontekstis on võimalik ekstraheerida standardseid lepingumalle täiustatud turbeparameetritega, nagu turbemustrid ja turbeteegid. See vähendab vigade võimalust käsitsi kodeerimisel. 

3. TESTIMINE ENNE Kasutuselevõtmist

Jällegi tuleneb selle faasi nõue nutikate lepingute ühest eelisest – “muutmatus”. 

Kui nutikad lepingud on loodud, ei saa neid enam muuta. Seetõttu on nutikate lepingute turvalisuse tagamiseks enne kasutuselevõttu kohustuslik läbi viia piisavad testid.

See etapp hõlmab kolme turbeparameetrit, mida tuleb enne nutika lepingu juurutamist järgida; Range formaalne kontrollimine, koodianalüüsi tööriistad ja turvaaudit. 

RANGE FORMAALNE KONTROLL

Formaalne kontrollimine on täpselt määratletud protsess, mis kasutab matemaatilisi arutluskäike ja matemaatilisi tõestusi, et kontrollida süsteemi soovitud omadusi. 

Saame teha nutikate lepingute ametlikku kontrolli, kuna lepinguprogramm on lühike ja tähtajaline. Nutikate lepingute jäigaks vormistamiseks ja kontrollimiseks on mitu võimalust; mõned põhinevad lepingukoodil ja teised Ethereumi virtuaalmasina (EVM) semantikas. 

KOODI ANALÜÜSI VAHENDID

Koodi analüüs tehakse ilma programme käivitamata. Sel eesmärgil kasutame mõningaid tööriistu, mida nimetatakse staatiliste rakenduste turvalisuse testimise (SAST) tööriistadeks. Need tööriistad aitavad avastada lähtekoodi turvavigu. 

Nende tööriistadega tehtud analüüs võib hõlmata ühte või kõiki järgmisi samme:

(I) Üksikasjalikuks analüüsiks looge vaheesitus (IR), näiteks abstraktne süntaksipuu (AST). 

(Ii) Täiendage IR-d piisava teabega, mis on saadud staatilisest kontrollist või kuupäevavoo analüüsist ja ametlikest kontrollimeetoditest; need tehnikad hõlmavad sümboolset täitmist, abstraktset tõlgendamist ja sümboolse mudeli kontrollimist. 

Kuid milliseid tööriistu saab kasutada nutika lepingu koodianalüüsi tegemiseks? 

Kuigi turvaanalüüsi tegemiseks on palju tööriistu, on Oyente kõige populaarsem. 

Kuulaja saab kasutada EVM-i nutikate lepingute turvaanalüüsi tegemiseks. See kasutab "sümboolset täitmist", et avastada neli levinud viga; tehingujärjekorra sõltuvus, ajatempli sõltuvus, valesti käsitletud erandid ja taassisenemine. 

Oyente arhitektuur näitab, et see võtab baitkoodi ja esitab sisendina Ethereumi globaalse oleku. 

Oyente üks tagakülgi on see, et see tuvastab ainult turvanõrkused. Oyente kasutatav sümboolne teostustehnika ei uuri kõiki võimalikke teid. Seega tekib vajadus muude tööriistade, näiteks turvalisuse ja käsitsi auditite järele. 

TURVALISUSAUDIT

Alustame seda jaotist sealt, kus jätsime viimase; manuaalsed auditid. 

Kuid kõigepealt mõistame turvaauditi vajadust; Olgu see siis Ronini võrgu häkkimine või Poly Networki häkkimine, on auditeerimata kood häkkimise ja ärakasutamise suhtes kõige haavatavam. 

Need toovad kaasa suuri rahalisi kaotusi. Tegelikult ei ole oluline mitte ainult Web3 projekti auditeerimine, vaid ka ekspertide auditeerimine, kuna see sõltub audiitorite professionaalsest võimekusest turvaauditeid teha. 

Jällegi, kust neid professionaalseid eksperte leida? Te ei pea kuhugi otsima usaldusväärseid audiitoreid; klõpsa https://t.me/quillhash et ühega neist ühendust võtta! 

Ideaalne nutikas lepinguaudit on käsitsi ja automatiseeritud koodianalüüsi kombinatsioon; Nagu me eelmises punktis arutasime, on lepingus võimalik tuvastamata haavatavus, kuigi pärast selliste tööriistade nagu Oyente automaatset koodianalüüsi. 

Seega saavad turbeaudiitorid selle ületamiseks käsitsi analüüsida iga koodirida ja testida neid võimalike haavatavuste suhtes. 

4. JÄRELEVALVE JA ANALÜÜS

Kas mäletate pidevalt arenevat Blockchaini põhimõtet, mida me alguses arutasime? 

See etapp põhineb samal teemal; Kui leping on juurutatud ja käivitatud, võivad uute väljalasete ja sagedaste värskenduste tõttu ilmneda mõned varasemates etappides märkamatuks jäänud haavatavused, mis muudavad lepingud hiljem vähem tõhusaks. 

Saame teostada; bug bounty, turvaseire ja post hoc analüüs nende tõkete ületamiseks. 

BUG BOUNTY

Kuna kaalume lepingutega seotud juurutamisjärgseid turvaprobleeme, võib Bug Bounties abi olla. Eelnevalt käsitletud ametlik kontrollitehnika on staatilise analüüsi tehnika. Bug bounty on seevastu dünaamiline analüüsitehnika. 

Bug bounty kontseptsioon on lihtne; häkkerid avastavad vigu ja vastutasuks makstakse neile rahalisi hüvesid. Tundub, et win-win olukord, eks? Aga ei ole!

Konks siin on; et vigade väärtus võib olla kõrgem kui hallidel turgudel saadav raha ning häkkerid võivad neid kõrge hinna saamiseks ära kasutada või maha müüa. 

Mõnikord keelduvad projekti omanikud pearaha maksmisest, välja arvatud juhul, kui vead on kinnitatud; häkkerid muretsevad ka maksete ebakindluse pärast pärast vigade ilmnemist. 

Sellest ülesaamiseks pakuti välja vigade hüvitamise raamistik, mida tuntakse kui "Hydra". 

Hydra kasutab plokiahelas vigade hüvitamise süsteemina N-of-N-versiooni programmeerimist (NNVP) nimega N-of-N-versiooni programmeerimine. 

TURVASEIRE

Saame kasutada turvaaukude tuvastamiseks staatilise koodi analüüsi, kuid seda meetodit kasutatakse enne nutikate lepingute juurutamist. 

Kuid vigade ja võimalike haavatavuste reaalajas leidmiseks peame jälgima ja analüüsima plokiahela tehinguandmeid. 

Neid nutikate lepingute analüüsimisel avastatud turvaauke võib nimetada jälgimishaavatavusteks. Nende haavatavuste keskmes on kolme tüüpi lepingud; 

(I) Ahned lepingud (lepingud, mis jäävad ellu ja lukustavad Eetrit määramata ajaks).

(Ii) Kadunud lepingud (lepingud, mis lekivad raha hooletult suvalistele kasutajatele) ja

(iii) Suitsiidsed lepingud (lepingud, mida iga suvaline kasutaja võib tappa). 

Haavatavuste tuvastamiseks ECF-objektide jälgimise abil pakuti välja isegi tõhusalt tagasihelistamisvabad (ECF) objektid. 

Sellega seoses esitati ka veebipõhine algoritm; see aitas avastada tundmatuid haavatavusi. Samas ettepanekus soovitati enne Mainnetis juurutamist sõlmida nutikad lepingud Testnetis. 

Jälgimisliides on Blockchaini jälgimisplatvorm, mis kasutab React.js-i. Seda platvormi saab kasutada tehingute tegemiseks, varade kontrollimiseks ja Blockchaini oleku kohta pärimiseks. 

Nutikate lepingute turvaliseks jälgimiseks ei saa me sellele platvormile loota, kuid kuna enamik nutikate lepingutega seotud tehinguandmeid on leitavad, saame varade ülekandmist jälgides reaalajas avastada ärakasutusi. 

POST HOC ANALÜÜS

Post Hoc Analysis kasutab plokiahela tehingute andmeid, et analüüsida, avastada või jälgida potentsiaalseid ohte plokiahelas võhiku mõistes. 

Kui arutleme graafiku analüüsist, siis see oli mõeldud kõigi tehinguandmete (sealhulgas nutikate lepingute sisetehingud) kogumiseks. 

Nende andmete abil koostasid nad kolm graafikut; 

(I) Rahavoogude graafik (MFG)

(Ii) Lepingu loomise graafik (CCG) ja

(iii) Lepingu väljakutsumise graafik (CIG)

Eespool mainitud graafikute analüüsi põhjal pakuti välja palju uusi leide, näiteks lahendusi turvaprobleemidele mitme omavahel suhtleva lepingu vahel. 

Ponzi skeem on üks klassikalistest petuskeemidest, mille kaudu saab omandada suure hulga rahalisi vahendeid, mis mõjutavad algset plokiahelat. Selle pettuse vastu võitlemiseks pakuti välja klassifitseerimismehhanism Ponzi skeemide tuvastamiseks Ethereumis. 

See mehhanism kasutab Ponzi lepingute tuvastamiseks andmete kaevandamist ja masinõpet. See protsess töötab isegi siis, kui nutikate lepingute lähtekood pole saadaval. 

Key Takeaway

See on kõik, jah, selleks korraks!

Kui olete meiega siiani olnud, oleksime selle eest tänulikud. Ilma pikemalt venimata ütleme kokkuvõtteks vaid seda, et arukate lepingute ökosüsteem on detsentraliseeritud ja vigu on raske parandada. 

Oleme püüdnud murda nutikate lepingute turvalisust tarkvara elutsükli vaatenurgast. 

Esmalt oleme arutanud plokiahela põhifunktsioone, mille eest vastutavad nutikate lepingute turvaprobleemid. Jaotasime nutikate lepingute turvalahendused nelja faasi. Loodame tuua rohkem postitusi, et hoida teid kasvava Web3 ökosüsteemi väljakutsetega ees. 

Mida arvate sellest paindlikust SDLC-meetodist nutika lepingu turvalisuse jaoks? Jagage oma mõtteid allolevates kommentaarides!

Postitus Nutikas lepingute turvalisus: agiilne SDLC-lähenemine  ilmus esmalt Blog.quillhash.

• Münditark. Euroopa parim Bitcoini ja krüptobörs.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. TASUTA PÄÄS.
• CryptoHawk. Altcoini radar. Tasuta prooviversioon.
• Allikas: https://blog.quillhash.com/2022/04/22/smart-contract-security-an-agile-sdlc-approach/