Smart kontraktsikkerhed: En agil SDLC-tilgang

Genudgivet af Platon

Abonnenter: 0

Læsetid: 10 minutter

Blockchain er citeret som en decentraliseret og manipulationssikker hovedbog. Men denne manipulationssikrede hovedbog er sårbar over for hacks og udnyttelser. Decentraliseringen, som er en af de stærkeste fordele ved Blockchain, er en af ulemperne.

Nå, det er fint, men hvad med SDLC?

Den softwarelivscyklustilgang, som vi er ved at diskutere, er baseret på at klassificere sikkerhedssårbarheder i smarte kontrakter i flere faser.

I det første afsnit har vi udstukket sikkerhedsproblemerne i de smarte kontrakter. Og i næste afsnit diskuterer vi dets løsninger opdelt i fire faser; Sikkerhedsdesign, sikkerhedsimplementering, test før implementering, og den sidste, overvågning og analyse.

ANALYSE AF SIKKERHEDSPROBLEM I SMART KONTRAKTER

Smarte kontrakter er sårbare over for forskellige hacks og udnyttelser. Disse kontrakter, der er synonyme med juridiske aftaler i den virkelige verden, kører uafhængigt baseret på vilkårene for de indfødte blockchains.

Men har du tænkt på, at selv de indfødte blockchains også kan være ansvarlige for potentielle sikkerhedstrusler i smarte kontrakter? Nedenfor præsenterer vi nogle af egenskaberne ved Blockchains for det samme:

decentralisering: Det betragtes som en af fordelene ved blockchain-baserede protokoller. Men angriberne har udtænkt en måde at vende denne positive egenskab til en negativ.

Ondsindede aktører kan skabe en falsk identitet for at udvikle og implementere en smart kontrakt. Nogle gange bliver det svært at identificere en sårbar kontrakt, da kun den offentlige adresse (eller) offentlige nøgler er tilgængelige på offentlige blockchains.

Open Source kode: Dette kan overraske dig, men ja, generelt er de fleste smarte kontraktkoder noget open source.

Lad os sige, i tilfælde af Ethereum Virtual Machine (EVM), er dens bytekode altid offentlig. Og nogle Solidity-decompilere kan hjælpe dig med at få en smart kontraktadresse og Solidity-koden. Eksponeringen af kildekoden gør denne funktion fordel for angribere.

Uudviklede blockchain-platforme: For en udvikler er det et primært krav at blive fortrolig med udviklingsplatformen. Der er mange underudviklede eller nye blockchain-platforme, så udviklere kan ikke udvikle et dybtgående kendskab til operationer på blockchain.

Denne inkonsistens påvirker de smarte kontrakter på grund af manglende synkronisering. Fejlene i blockchain-platformen forbliver ubemærket på grund af dens kontinuerlige udvikling.

Ukendte transaktioner: I det første punkt har vi diskuteret anonym identitet; på samme måde er transaktionerne på blockchains ikke oplyst. Det er umuligt at spore transaktionerne, hvilket fører til mange ulovlige aktiviteter. Da finansielle transaktioner er involveret, kan ethvert sikkerhedsproblem resultere i enorme økonomiske tab.

SMART KONTRAKTSIKKERHEDSLØSNINGER

Når vi nu går videre med den smarte kontraktsikkerhed, kan vi sammenligne alle de nødvendige trin, der kræves for at sikre en smart kontrakt med dens udvikling. Som i traditionel softwareudvikling har vi en tendens til at følge en udviklingslivscyklus; på samme måde kan vi klassificere kontraktudviklingens livscyklus.

Den smarte kontraktudviklings livscyklus kan opdeles i fire faser: sikkerhedsdesign, sikkerhedsimplementering, test før implementering og overvågning og analyse.

overblik over sikkerhedstemaer fra et smart kontraktlivscyklusperspektiv — *oversigt over sikkerhedstemaer fra et smart kontraktlivscyklusperspektiv*

1. SIKKERHEDSDESIGN

Denne første fase indkapsler tre temaer; designprincip, designmønster og sikkerhedsmodellering (som vist i ovenstående figur). Det primære fokus for disse temaer er på kontraktdesign og hvordan sikkerhedstrusler kan afværges.

DESIGNPRINCIP

Designprincipper er grundlæggende ideer til at designe sikre smarte kontrakter på blockchain. Der er fem væsentlige designprincipper for kontrakter: Forbered dig på fiasko, udrulning omhyggeligt, Hold kontrakter enkle, Hold dig opdateret og Must-know om blockchain-egenskaber.

Nu tænker du måske, hvordan vil de hjælpe med at skabe en sikker smart kontrakt?

Lad os tage et hvilket som helst af principperne ovenfra, f.eks. "Forbered dig på fiasko", dette betyder, at i fravær af patching-ordninger, burde kontrakten være i stand til at reagere på fejl. Og hvis et angreb finder sted, bør kontrakten være i stand til at holde pause for at forhindre yderligere tab.

DESIGN MØNSTER

I softwaredesign er designmønstrene de løsninger, der kan genbruges til at løse et problem.

Hvis vi tager et eksempel på Ethereum, er der seks sikkerhedsmønstre; Check-effects-interaction, Emergency stop, Mutex, Speed bump, Rate limit og Balance limit.

Vi kan bruge disse sikkerhedsmønstre til at løse sikkerhedsproblemer i blockchain, ligesom genindtræden-sårbarheden kan håndteres af Mutex-mønsteret.

Samtidig kan Nødstop-mønsteret hjælpe os med at afslutte en kontrakts udførelse, hvis den bliver påvirket af en sårbarhed.

SIKKERHEDSMODELLER

Der kan være forskel på den udviklede kode og den nødvendige kode for kontrakter, da Solidity bruges til at oprette kontrakter; dette sprog opfylder Turing-fuldstændigheden, men det er tilbøjeligt til fejl.

Ovenstående figur viser, at denne underfase dækker over to faser; sikkerhedsdesign og implementering.

Sikkerhedsmodellering er direkte relateret til forretningslogik; da specifikationer er afledt af virksomheden, kan logik klassificeres ved fejlfri semantik. Dette hjælper senere under den formelle verifikationsproces, der udføres for at afbøde sårbarheder.

2. SIKKERHEDSIMPLEMENTERING

I dette afsnit vil vi dække to af de tre temaer; sikkerhed

Udvikling og Sikkerhedsskabelon, da vi allerede har dækket Sikkerhedsmodellering i sidste fase.

SIKKERHEDSUDVIKLING

Dette afsnit vil se, hvordan sårbarheder kan undgås under kontraktimplementeringsprocessen.

På Ethereum-platformen har vi sikkerheds-EIP'er (Ethereum-forbedringsforslag) – anbefalinger til at bekæmpe sikkerhedsproblemerne på Ethereum platform. Disse EIP'er er således bemærkelsesværdige for sikker implementering af smarte kontrakter.

SIKKERHEDSSkabelon

Skabeloner tjener som oprindelse for nye dokumenter. De smarte kontraktskabeloner med driftsparametre forbinder en juridisk aftale med en eksekverbar kode.

I sammenhæng med smart kontraktsikkerhed er det muligt at udtrække standard kontraktskabeloner med opgraderede sikkerhedsparametre, såsom sikkerhedsmønstre og sikkerhedsbiblioteker. Dette vil reducere muligheden for fejl i manuel kodning.

3. TEST FØR IDRÆVNING

Igen, kravet om denne fase opstår fra en af fordelene ved smarte kontrakter - "Immutability".

Når først de smarte kontrakter er oprettet, er der ingen måde at ændre dem på. Derfor er det obligatorisk at udføre tilstrækkelige tests for at sikre sikkerheden af smarte kontrakter før implementering.

Denne fase dækker tre sikkerhedsparametre, der skal følges før implementering af en smart kontrakt; Strenge formel verifikation, kodeanalyseværktøjer og sikkerhedsrevision.

STRANG FORMEL VERIFIKATION

Formel verifikation er en veldefineret proces, der udnytter matematisk ræsonnement og matematiske beviser til at verificere ønskede egenskaber ved systemet.

Vi kan udføre formel verifikation på smarte kontrakter, da kontraktprogrammet er kort og tidsbegrænset. Der er flere måder at formalisere og verificere smarte kontrakter på; nogle er baseret på kontraktkode, og andre på semantikken i den virtuelle Ethereum-maskine (EVM).

KODEANALYSEVÆRKTØJ

Analysen af koden udføres uden at udføre programmerne. Til dette formål bruger vi nogle værktøjer kaldet Static Application Security Testing (SAST) Tools. Disse værktøjer hjælper med at opdage sikkerhedsfejl i kildekoden.

Analysen udført af disse værktøjer kan omfatte et eller alle af følgende trin:

(I) Opret en mellemrepræsentation (IR), såsom et abstrakt syntakstræ (AST), til detaljeret analyse.

(Ii) Suppler IR med tilstrækkelig information opnået fra statisk kontrol eller datoflowanalyse og formelle verifikationsteknikker; disse teknikker omfatter: symbolsk udførelse, abstrakt fortolkning og symbolsk modelkontrol.

Men hvad er de værktøjer, man kan bruge til at udføre kodeanalyse på Smart Contract?

Selvom der er mange værktøjer, man kan bruge til at udføre sikkerhedsanalysen, er Oyente det mest populære.

Lytter kan bruges til at udføre sikkerhedsanalyse for EVM smarte kontrakter. Den bruger "symbolsk udførelse" til at opdage fire almindelige fejl; afhængighed af transaktionsbestilling, tidsstempelafhængighed, fejlbehandlede undtagelser og genindtræden.

Arkitekturen i Oyente viser, at den tager bytekode og præsenterer Ethereums globale tilstand som input.

En af bagsiderne ved Oyente er, at den kun registrerer sikkerhedssårbarheder. Den symbolske udførelsesteknik, som Oyente bruger, udforsker ikke alle mulige veje. Dermed opstår behovet for andre værktøjer som Sikkerhed og manuelle revisioner.

SIKKERHEDSREVISION

Vi begynder dette afsnit, hvor vi forlod det sidste; de manuelle revisioner.

Men lad os først forstå behovet for en sikkerhedsrevision; uanset om det er Ronin Network-hacket eller Poly Network-hacket, er urevideret kode den mest sårbare over for hacks og udnyttelser.

De fører til store økonomiske tab. Ikke bare at få dit Web3-projekt revideret, som en kendsgerning, men at få det revideret af eksperter er også vigtigt, da det afhænger af revisorernes professionelle evne til at udføre sikkerhedsrevisioner.

Igen, hvor finder man disse professionelle eksperter? Du behøver ikke gå nogen steder på udkig efter pålidelige revisorer; klik https://t.me/quillhash at komme i kontakt med en af dem!

En ideel smart kontraktrevision er en kombination af manuel og automatiseret kodeanalyse; som vi har diskuteret i det foregående punkt, selvom man går efter automatiseret kodeanalyse fra værktøjer som Oyente, er der mulighed for uidentificerede sårbarheder i kontrakten.

For at overvinde det kan sikkerhedsrevisorer manuelt analysere hver linje kode og teste dem mod potentielle sårbarheder.

4. OVERVÅGNING OG ANALYSE

Kan du huske det stadigt udviklende princip om Blockchain, som vi diskuterede indledningsvis?

Denne fase tager udgangspunkt i samme tema; når kontrakten er blevet implementeret og kørt, kan nogle sårbarheder, der blev efterladt ubemærket i de tidligere faser, opstå på grund af nye udgivelser og hyppige opdateringer, der senere gør kontrakter mindre effektive.

Vi kan udføre; bug bounty, sikkerhedsovervågning og post hoc analyse for at overvinde disse barrierer.

BUG BOUNTY

Da vi overvejer sikkerhedsproblemerne efter implementeringen med kontrakter, kan Bug Bounties være nyttige. Den formelle verifikationsteknik, der er diskuteret tidligere, er en statisk analyseteknik. Bug bounty er på den anden side en dynamisk analyseteknik.

Konceptet bag Bug bounty er enkelt; hackere opdager fejl, og til gengæld bliver de betalt med nogle økonomiske belønninger. Det ligner en win-win situation, ikke? Men det er det ikke!

Fangsten her er; at værdien af fejl kan være højere end dusøren på de grå markeder, og muligheden er, at hackere kan udnytte eller sælge fejlene for at få en høj pris.

Nogle gange nægter projektejere at betale dusøren, medmindre fejlene er bekræftet; hackere bekymrer sig også om usikkerheden ved betalinger efter afsløring af fejl.

For at overvinde dette blev der foreslået en bug bounty-ramme, kendt som "Hydra".

Hydra bruger en exploit gap-teknologi ved navn N-of-N-version programmering (NNVP) som et bug bounty-system på blockchain.

SIKKERHEDSOVERVÅGNING

Vi kan bruge statisk kodeanalyse til at opdage sikkerhedssårbarhederne, men denne metode bruges før implementering af de smarte kontrakter.

Men for at finde fejl og potentielle sårbarheder i realtid, er vi nødt til at overvåge og analysere transaktionsdata på blockchain.

Disse sårbarheder opdaget ved at analysere smarte kontrakter kan kaldes sporsårbarheder. Tre typer kontrakter ligger i fokus for disse sporsårbarheder;

(I) Grådige kontrakter (kontrakter, der forbliver i live og låser Ether på ubestemt tid).

(Ii) Fortabte kontrakter (kontrakter, der lækker midler skødesløst til vilkårlige brugere) og,

(Iii) Selvmordskontrakter (kontrakter, som enhver vilkårlig bruger kan dræbe).

Selv en forestilling om Effectively Callback Free (ECF)-objekter blev foreslået for at identificere sårbarheder ved at overvåge ECF-objekter.

I forbindelse hermed blev der også præsenteret en online algoritme; det hjalp med at opdage ukendte sårbarheder. I det samme forslag blev det foreslået at udføre smarte kontrakter på Testnet før implementering på Mainnet.

Monitoring UI er en Blockchain-overvågningsplatform, der bruger React.js. Denne platform kan bruges til at udføre transaktioner, holde styr på aktiver og forespørge om Blockchains tilstand.

Vi kan ikke stole på denne platform til sikker overvågning af smarte kontrakter, men da de fleste transaktionsdata relateret til smarte kontrakter kan findes, kan vi opdage udnyttelser i realtid ved at spore overførslen af aktiver.

POST HOC ANALYSE

Post Hoc Analysis bruger blockchain-transaktionsdata til at analysere, opdage eller spore potentielle trusler på blockchain i lægmandssprog.

Hvis vi diskuterer Graph-analysen, var den designet som en tilgang til at indsamle alle transaktionsdata (dette inkluderede interne transaktioner fra smarte kontrakter).

Ved hjælp af disse data udarbejdede de tre grafer;

(I) En pengestrømsgraf (MFG)

(Ii) Kontraktoprettelsesgraf (CCG) og,

(Iii) Kontraktindkaldelsesgraf (CIG)

Baseret på analysen af ovennævnte grafer blev der foreslået mange nye resultater, såsom løsninger på sikkerhedsproblemer mellem flere kontrakter, der interagerer med hinanden.

Ponzi-ordningen er en af de klassiske svindelordninger, hvorigennem et stort antal midler kan erhverves og påvirke den oprindelige blockchain. For at bekæmpe denne svig blev der foreslået en klassificeringsmekanisme til at opdage Ponzi-ordninger på Ethereum.

Denne mekanisme bruger data mining og maskinlæring til at opdage Ponzi-kontrakter. Denne proces fungerer, selvom kildekoden til de smarte kontrakter ikke er tilgængelig.

Key takeaway

Det var det, ja, det var det for nu!

Hvis du har været hos os indtil nu, ville vi sætte pris på det. Uden at strække mere, vil vi afslutningsvis kun sige, at økosystemet af smarte kontrakter er decentraliseret, og det er svært at lappe for fejl.

Vi har forsøgt at nedbryde sikkerheden ved smarte kontrakter fra softwarens livscyklusperspektiv.

Vi har først diskuteret blockchains nøglefunktioner, der er ansvarlige for sikkerhedsproblemer i smarte kontrakter. Vi klassificerede sikkerhedsløsningerne til de smarte kontrakter i fire faser. Vi håber at bringe flere indlæg for at holde dig på forkant med udfordringerne i det voksende Web3-økosystem.

Hvad synes du om denne agile SDLC-tilgang til smart kontraktsikkerhed? Del dine tanker i kommentarerne nedenfor!

46 Views

Stillingen Smart kontraktsikkerhed: En agil SDLC-tilgang dukkede først på Blog.quillhash.

Tidsstempel: April 22, 2022