Smart Contract Security: En smidig SDLC-tilnærming 

Lesetid: 10 minutter

Blockchain er sitert som en desentralisert og manipulasjonssikker hovedbok. Men denne manipulasjonssikre hovedboken er sårbar for hacks og utnyttelser. Desentraliseringen, som er en av de sterkeste fordelene med Blockchain, er en av ulempene. 

Vel, det er greit, men hva med SDLC? 

Programvarens livssyklustilnærming som vi skal diskutere er basert på å klassifisere sikkerhetssårbarheter i smarte kontrakter i flere faser. 

I den første delen har vi lagt opp til sikkerhetsproblemene i de smarte kontraktene. Og i neste avsnitt diskuterer vi løsningene fordelt på fire faser; Sikkerhetsdesign, sikkerhetsimplementering, testing før distribusjon, og den siste, overvåking og analyse. 

ANALYSE AV SIKKERHETSSPØRSMÅL I SMARTE KONTRAKTER 

Smarte kontrakter er sårbare for ulike hacks og utnyttelser. Disse kontraktene som er synonyme med juridiske avtaler i den virkelige verden, kjøres uavhengig basert på vilkårene til de innfødte blokkjedene. 

Men har du tenkt på at selv de innfødte blokkjedene også kan være ansvarlige for potensielle sikkerhetstrusler i smarte kontrakter? Nedenfor presenterer vi noen av egenskapene til blokkjeder for det samme:

desentralisering: Det regnes som en av fordelene med blokkjedebaserte protokoller. Men angriperne har utviklet en måte å snu denne positive egenskapen til en negativ. 

Ondsinnede aktører kan skape en falsk identitet for å utvikle og distribuere en smart kontrakt. Noen ganger blir det vanskelig å identifisere en sårbar kontrakt ettersom bare offentlig adresse (eller) offentlige nøkler er tilgjengelige på offentlige blokkjeder. 

Åpen kildekode: Dette kan overraske deg, men ja, generelt sett er de fleste smarte kontraktskoder noe åpen kildekode. 

Si, når det gjelder Ethereum Virtual Machine (EVM), er bytekoden alltid offentlig. Og noen Solidity-dekompilatorer kan hjelpe deg med å få en smart kontraktsadresse og Solidity-koden. Eksponeringen av kildekoden gjør denne funksjonen fordel for angripere. 

Uutviklede blokkjedeplattformer: For en utvikler er det et primært krav å bli kjent med utviklingsplattformen. Det er mange underutviklede eller nye blokkjedeplattformer, så utviklere kan ikke utvikle en dybdekunnskap om operasjoner på blokkjeden. 

Denne inkonsekvensen påvirker de smarte kontraktene på grunn av mangel på synkronisering. Feilene i blockchain-plattformen forblir ubemerket på grunn av dens kontinuerlige utvikling. 

Ukjente transaksjoner: I det første punktet har vi diskutert anonym identitet; på samme måte er transaksjonene på blokkjeder ikke avslørt. Det er umulig å spore transaksjonene, noe som fører til mange ulovlige aktiviteter. Ettersom økonomiske transaksjoner er involvert, kan ethvert sikkerhetsproblem resultere i store økonomiske tap. 

SMARTE KONTRAKTSIKKERHETSLØSNINGER

Nå, for å gå videre med smart kontraktsikkerhet, kan vi sammenligne alle de nødvendige trinnene som kreves for å sikre en smart kontrakt med utviklingen. Som i tradisjonell programvareutvikling har vi en tendens til å følge en utviklingslivssyklus; på samme måte kan vi klassifisere kontraktsutviklingens livssyklus. 

Livssyklusen for smart kontraktutvikling kan deles inn i fire faser: sikkerhetsdesign, sikkerhetsimplementering, testing før distribusjon og overvåking og analyse.

1. SIKKERHETSDESIGN 

Denne første fasen innkapsler tre temaer; designprinsipp, designmønster og sikkerhetsmodellering (som vist i figuren ovenfor). Hovedfokuset for disse temaene er på kontraktsdesign og hvordan sikkerhetstrusler kan avverges. 

DESIGNPRINSIPP

Designprinsipper er grunnleggende ideer for å designe sikre smarte kontrakter på blokkjeden. Det er fem essensielle designprinsipper for kontrakter: Forbered deg på feil, utrulling nøye, Hold kontrakter enkle, Hold deg oppdatert og Må vite om blokkjedeegenskaper. 

Nå tenker du kanskje, hvordan vil de bidra til å skape en sikker smart kontrakt? 

La oss ta ett av prinsippene ovenfra, si "Forbered deg på feil" dette betyr at i fravær av oppdateringsordninger, bør kontrakten være i stand til å svare på feil. Og hvis et angrep finner sted, bør kontrakten kunne settes på pause for å forhindre ytterligere tap. 

DESIGN MØNSTER

I programvaredesign er designmønstrene løsningene som kan gjenbrukes for å løse et problem. 

Hvis vi tar et eksempel på Ethereum, er det seks sikkerhetsmønstre; Sjekk-effekter-interaksjon, Nødstopp, Mutex, Fartshump, Hastighetsgrense og Balansegrense.  

Vi kan bruke disse sikkerhetsmønstrene til å løse sikkerhetsproblemer i blokkjeden, slik som reentrancy-sårbarheten kan håndteres av Mutex-mønsteret. 

Samtidig kan Nødstoppmønsteret hjelpe oss med å avslutte en kontrakts utførelse dersom den blir påvirket av en sårbarhet. 

SIKKERHETSMODELLER

Det kan være en forskjell mellom den utviklede koden og den nødvendige koden for kontrakter da Solidity brukes til å lage kontrakter; dette språket tilfredsstiller Turing-fullstendigheten, men det er utsatt for feil. 

Figuren over viser at denne delfasen dekker to faser; sikkerhetsdesign og implementering. 

Sikkerhetsmodellering er direkte relatert til forretningslogikk; ettersom spesifikasjoner er avledet fra virksomheten, kan logikk klassifiseres ved feilfri semantikk. Dette hjelper senere under den formelle verifiseringsprosessen som utføres for å redusere sårbarheter. 

2. SIKKERHETSIMPLEMENTERING

I denne delen skal vi dekke to av de tre temaene; sikkerhet

Utvikling, og Sikkerhetsmal, da vi allerede har dekket Sikkerhetsmodellering i siste fase.

SIKKERHETSUTVIKLING

Denne delen vil se hvordan sårbarheter kan unngås under kontraktsimplementeringsprosessen. 

På Ethereum-plattformen har vi sikkerhets-EIP-er (Ethereum-forbedringsforslag) – anbefalinger for å bekjempe sikkerhetsproblemene på Ethereum plattform. Derfor er disse EIP-ene bemerkelsesverdige for sikker implementering av smarte kontrakter. 

SIKKERHETSMAL

Maler fungerer som opprinnelsen til nye dokumenter. De smarte kontraktsmalene med driftsparametere kobler en juridisk avtale til en kjørbar kode. 

I sammenheng med smart kontraktssikkerhet er det mulig å trekke ut standard kontraktsmaler med oppgraderte sikkerhetsparametere, som sikkerhetsmønstre og sikkerhetsbiblioteker. Dette vil redusere muligheten for feil i manuell koding. 

3. TESTING FØR IPLASSERING

Igjen, kravet til denne fasen oppstår fra en av fordelene med smarte kontrakter - "Immutability". 

Når de smarte kontraktene er opprettet, er det ingen måte å endre dem på. Derfor er det obligatorisk å gjennomføre tilstrekkelige tester for å sikre sikkerheten til smarte kontrakter før distribusjon.

Denne fasen dekker tre sikkerhetsparametere som skal følges før en smart kontrakt implementeres; Streng formell verifisering, kodeanalyseverktøy og sikkerhetsrevisjon. 

STRENGE FORMELL VERIFIKASJON

Formell verifisering er en veldefinert prosess som utnytter matematisk resonnement og matematiske bevis for å verifisere ønskede egenskaper til systemet. 

Vi kan utføre formell verifisering på smarte kontrakter da kontraktsprogrammet er kort og tidsavgrenset. Det er flere måter å formalisere og verifisere smarte kontrakter på; noen er basert på kontraktskode, og andre på semantikken til den virtuelle Ethereum-maskinen (EVM). 

KODEANALYSEVERKTØY

Analysen av koden gjøres uten å kjøre programmene. Til dette formålet bruker vi noen verktøy kalt Static Application Security Testing (SAST) Tools. Disse verktøyene hjelper til med å oppdage sikkerhetsfeil i kildekoden. 

Analysen utført av disse verktøyene kan omfatte ett eller alle av følgende trinn:

(I) Opprett en mellomrepresentasjon (IR), for eksempel et abstrakt syntakstre (AST), for detaljert analyse. 

(Ii) Suppler IR med tilstrekkelig informasjon hentet fra statisk kontroll eller datoflytanalyse og formelle verifikasjonsteknikker; disse teknikkene inkluderer: symbolsk utførelse, abstrakt tolkning og symbolsk modellkontroll. 

Men hva er verktøyene man kan bruke for å utføre kodeanalyse på Smart Contract? 

Selv om det er mange verktøy man kan bruke for å utføre sikkerhetsanalysen, er Oyente det mest populære. 

Lytter kan brukes til å utføre sikkerhetsanalyse for EVM smarte kontrakter. Den bruker "symbolsk utførelse" for å oppdage fire vanlige feil; avhengighet av transaksjonsbestilling, tidsstempelavhengighet, feilbehandlede unntak og reentrancy. 

Arkitekturen til Oyente viser at den tar bytekode og presenterer Ethereums globale tilstand som input. 

En av baksidene til Oyente er at den bare oppdager sikkerhetssårbarheter. Den symbolske utførelsesteknikken brukt av Oyente utforsker ikke alle mulige veier. Dermed oppstår behovet for andre verktøy som Sikkerhet og manuelle revisjoner. 

SIKKERHETSREVISJON

Vi begynner denne delen der vi la den siste; de manuelle revisjonene. 

Men først, la oss forstå behovet for en sikkerhetsrevisjon; enten det er Ronin Network-hacket eller Poly Network-hacket, er urevidert kode den mest sårbare for hacks og utnyttelser. 

De fører til store økonomiske tap. Ikke bare å få Web3-prosjektet ditt revidert, som et spørsmål, men å få det revidert av eksperter er også viktig, siden det avhenger av revisors profesjonelle evne til å utføre sikkerhetsrevisjoner. 

Igjen, hvor finner man de profesjonelle ekspertene? Du trenger ikke gå noe sted og lete etter pålitelige revisorer; klikk https://t.me/quillhash for å komme i kontakt med en av dem! 

En ideell smart kontraktrevisjon er en kombinasjon av manuell og automatisert kodeanalyse; som vi har diskutert i forrige punkt, selv om man går etter automatisert kodeanalyse fra verktøy som Oyente, er det mulighet for uidentifiserte sårbarheter i kontrakten. 

For å overvinne det, kan sikkerhetsrevisorer manuelt analysere hver linje med kode og teste dem mot potensielle sårbarheter. 

4. OVERVÅKING OG ANALYSE

Husker du det stadig utviklende prinsippet om Blockchain som vi diskuterte innledningsvis? 

Denne fasen er basert på samme tema; når kontrakten har blitt distribuert og kjørt, kan noen sårbarheter som ble ubemerket i de tidligere stadiene oppstå på grunn av nye utgivelser og hyppige oppdateringer som senere gjør kontrakter mindre effektive. 

Vi kan gjennomføre; bug bounty, sikkerhetsovervåking og post hoc-analyse for å overvinne disse barrierene. 

BUG BOUNTY

Ettersom vi vurderer sikkerhetsproblemene etter distribusjon med kontrakter, kan Bug Bounties være nyttige. Den formelle verifiseringsteknikken diskutert tidligere er en statisk analyseteknikk. Bug bounty, derimot, er en dynamisk analyseteknikk. 

Konseptet bak Bug bounty er enkelt; hackere oppdager feil, og til gjengjeld blir de betalt med noen økonomiske belønninger. Ser ut som en vinn-vinn-situasjon, ikke sant? Men det er det ikke!

Fangsten her er; at verdien av bugs kan være høyere enn dusøren i de grå markedene, og muligheten er at hackere kan utnytte eller selge feilene for å få en høy pris. 

Noen ganger nekter prosjekteierne å betale dusøren med mindre feilene er bekreftet; hackere bekymrer seg også for usikkerheten rundt betalinger etter avsløring av feil. 

For å overvinne dette ble det foreslått et bug-bounty-rammeverk, kjent som "Hydra". 

Hydra bruker en utnyttelsesgap-teknologi kalt N-of-N-version programmering (NNVP) som et bug bounty-system på blokkjeden. 

SIKKERHETSOVERVÅKNING

Vi kan bruke statisk kodeanalyse for å oppdage sikkerhetssårbarhetene, men denne metoden brukes før utplassering av smarte kontrakter. 

Men for å finne feil og potensielle sårbarheter i sanntid, må vi overvåke og analysere transaksjonsdata på blokkjeden. 

Disse sårbarhetene oppdaget ved å analysere smarte kontrakter kan kalles sporsårbarheter. Tre typer kontrakter ligger i fokus for disse sporsårbarhetene; 

(I) Grådige kontrakter (kontrakter som forblir i live og låser Ether på ubestemt tid).

(Ii) Tapte kontrakter (kontrakter som lekker midler uforsiktig til vilkårlige brukere) og,

(Iii) Selvmordskontrakter (kontrakter som enhver vilkårlig bruker kan drepe). 

Selv en forestilling om Effectively Callback Free (ECF)-objekter ble foreslått for å identifisere sårbarheter ved å overvåke ECF-objekter. 

I sammenheng med dette ble det også presentert en nettbasert algoritme; det hjalp til med å oppdage ukjente sårbarheter. I det samme forslaget ble det foreslått å utføre smarte kontrakter på Testnet før distribusjon på Mainnet. 

Monitoring UI er en Blockchain-overvåkingsplattform som bruker React.js. Denne plattformen kan brukes til å utføre transaksjoner, holde kontroll på eiendeler og spørre om tilstanden til Blockchain. 

Vi kan ikke stole på denne plattformen for sikker overvåking av smarte kontrakter, men ettersom de fleste transaksjonsdata knyttet til smarte kontrakter kan finnes, kan vi oppdage utnyttelser i sanntid ved å spore overføringen av eiendeler. 

POST HOC ANALYSE

Post Hoc Analysis bruker blokkjedetransaksjonsdata for å analysere, oppdage eller spore potensielle trusler på blokkjeden i lekmannstermer. 

Hvis vi diskuterer Graph-analysen, ble den designet som en tilnærming til å samle alle transaksjonsdataene (dette inkluderte interne transaksjoner fra smarte kontrakter). 

Ved hjelp av disse dataene utarbeidet de tre grafer; 

(I) En pengestrømgraf (MFG)

(Ii) Kontraktopprettelsesgraf (CCG) og,

(Iii) Kontraktanropsgraf (CIG)

Basert på analysen av grafene nevnt ovenfor, ble mange nye funn foreslått, for eksempel løsninger på sikkerhetsproblemer mellom flere kontrakter som samhandler med hverandre. 

Ponzi-ordningen er en av de klassiske svindelordningene der et stort antall midler kan skaffes og påvirke den innfødte blokkjeden. For å bekjempe denne svindelen ble det foreslått en klassifiseringsmekanisme for å oppdage Ponzi-ordninger på Ethereum. 

Denne mekanismen bruker data mining og maskinlæring for å oppdage Ponzi-kontrakter. Denne prosessen fungerer selv om kildekoden til de smarte kontraktene er utilgjengelig. 

Nøkkel takeaway

Det var det, ja, det var det for nå!

Hvis du har vært med oss ​​til nå, vil vi sette pris på det. Uten å strekke mer, på et avsluttende notat, vil vi bare si at økosystemet av smarte kontrakter er desentralisert, og det er vanskelig å lappe for feil. 

Vi har forsøkt å bryte ned sikkerheten til smarte kontrakter fra programvarens livssyklusperspektiv. 

Vi har først diskutert blokkjedens nøkkelfunksjoner som er ansvarlige for sikkerhetsproblemer i smarte kontrakter. Vi klassifiserte sikkerhetsløsningene for de smarte kontraktene i fire faser. Vi håper å komme med flere innlegg for å holde deg i forkant av utfordringene i det voksende Web3-økosystemet. 

Hva synes du om denne smidige SDLC-tilnærmingen for smart kontraktsikkerhet? Del dine tanker i kommentarene nedenfor!

Innlegget Smart Contract Security: En smidig SDLC-tilnærming  dukket først på Blog.quillhash.

• Myntsmart. Europas beste Bitcoin og Crypto Exchange.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
• CryptoHawk. Altcoin Radar. Gratis prøveperiode.
• Kilde: https://blog.quillhash.com/2022/04/22/smart-contract-security-an-agile-sdlc-approach/