Analyse av Smart Contract Security Practices av utviklere

Analyse av Smart Contract Security Practices av utviklere 

Tidsstempel: 13. januar 2023 7:10
Analyse av Smart Contract Security Practices av utviklere PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Lesetid: 5 minutter

Siden DeFi begynte å skyte i været, har en ny bølge av smarte kontraktsangrep som har ført til tap av hundrevis av millioner dollar dukket opp. Det er tydelig fra de stigende hacktallene at sikkerhet er avgjørende for smarte kontrakter. 

De fleste av sårbarhetene kan avverges på utviklingsstadiet av kontrakter hvis beste praksis følges. DeFi-prosjekter har noen ganger det travelt med å komme ut på markedet, noe som gjør sikkerhet til andre prioritet. Det er forskjell på utviklere i tidlig stadium og erfarne utviklere. En erfaren utvikler kjenner beste sikkerhetspraksis, verktøy og kunnskap om vanlige sårbarheter og kan identifisere sikkerhetsproblemer på et tidlig stadium av utviklingen. 

Smarte kontrakter er den digitale representasjonen av kontraktsavtaler i kode. Utførelsen av denne koden verifiseres og distribueres ved hjelp av nettverksnoder i et blokkjedenettverk. 

I denne artikkelen vil vi dekke den menneskelige faktoren bak sikkerheten og personvernet til smarte kontrakter og analysere hvorfor utviklere fortsatt anses som det "svakeste leddet".

Hva er sårbarheter i smarte kontrakter

Ettersom smarte kontrakter kjører på distribuerte og tillatelsesløse nettverk, forårsaker det sårbarheter på grunn av feil i utførelse av smart kontrakt. Ettersom midler er låst i disse kontraktene, blir det et veldig attraktivt mål for hackere, og vellykket angrep kan føre til at hackere stikker av med midlene direkte fra kontraktene. 

Noen vanlige sårbarheter i EVM-baserte smarte kontrakter inkluderer gjeninntreden, heltallsoverløp og ubegrenset tilgangskontroll. For å utnytte en kontrakt med re-entrance, gjøres en oppfordring til den eksterne kontrakten; den påkaller deretter en tilbakeringing på nytt. Operasjoner på lavt nivå som "send", "overfør" og "ring" er alarmerende, og dette kan føre til sårbarheter hvis unntak ikke håndteres forsiktig. 

Innovasjoner i Blockchain-området utvikler seg kontinuerlig, noe som resulterer i designfeil i smarte kontrakter. Utviklere som bygger desentraliserte applikasjoner må forholde seg til oppdateringer på plattformene de jobber med. Derfor kan vanlige programvarefeil som tilgangskontroll, feil beregning, rasetilstand og flere andre intensivere på blockchain-plattformene. 

Smarte kontraktsikkerhetsverktøy

Ulike praksiser har blitt tatt i bruk på ulike nivåer av utviklingen av smarte kontrakter for å sikre og forbedre sikkerheten til smarte kontrakter. 

Smarte kontraktstestverktøy: Flere verktøy er utviklet for å analysere kontraktens kildekode og skanne etter kjente sikkerhetsproblemer som re-entrancy, overflow, etc. Noen av de mest brukte verktøyene er Oyente, Maian, MadMax og Vandal. 

Utviklings- og testmiljøer: Trøffel er det populære utviklingsrammeverket for smarte kontrakter. Utviklere kan skrive enhets- og integrasjonstester med dette. Hardhat er et annet utviklingsmiljø som hjelper til med å kjøre tester, sjekke kode for feil og samhandle med smarte kontrakter; den kjører på et utviklingsnettverk. Det forenkler plugins for å dekke koden, måle gass brukt per enhetstest, automatisk verifisere kontrakter på Etherscan, etc. Remiksen er en annen go-to suite for utviklere; den brukes mye på grunn av nettleserens IDE som støtter testing, utvikling og distribusjon av smarte kontrakter. 

Kode revisjoner: Revisjon av smarte kontrakter bidrar til å redusere risiko knyttet til dAapp. Det er å foretrekke å gjennomføre smarte kontraktrevisjoner når kontraktene er i testfasen. Noen verktøy som brukes til revisjon er Surya, Mythril, og MythX. Selv om automatisert revisjon ikke er tilstrekkelig for å redusere risiko knyttet til kontrakter, foreslås det å utføre manuelle tredjepartsrevisjoner fra et pålitelig firma som QuillAudits. Under en revisjon oppdages sårbarheter på tre hovedmåter:

  1.  Funksjoner utvinning fra ondsinnet kode og gjør semantisk matching på kildekoden;
  2.  Etter en matematisk tilnærming for å verifisere et systems fullstendighet, undersøker revisor her alle mulige inputtester mot alle potensielle testtilfeller som kan skje;
  3.  Opprette en kontrollflytgraf med logiske enheter i kontrakten der revisor krysser alle kodeveier for å inspisere logiske designfeil

Sikker smart kontraktutvikling

Hvis vi ser nøye på de nylige smarte kontraktsutnyttelsene, oppsto et større antall sårbarheter på grunn av utvikleres feil. Derfor betyr det å unngå smutthull i smarte kontrakter sikker utvikling av smarte kontrakter med tanke på brukerne under utviklingens livssyklus. Mange utviklere i tidlig fase anser ikke sikkerhet som hovedfaktoren og mangler bevissthet knyttet til ressurser og verktøy for smart kontraktssikkerhet. 

Smart Contract Security Insights

De fleste av utviklerne har ikke sikkerhet som toppprioritet mens de utvikler smarte kontrakter fordi:

  1. De blir bedt om å levere prosjektet så snart som mulig. Derfor blir sikkerhet sekundær
  2. Noen ganger gir prosjekter andre populære prosjekter 
  3. Noen fra teamet utfører tilsynet

Bortsett fra det hører vi vanligvis utviklere si at Solidity har noen iboende begrensninger for å opprettholde sikkerheten. Det er forskjellig fra det vanlige språket ettersom funksjoner ikke er definert eksplisitt. Det er også vanskeligheter med å utføre de riktige streng- og array-manipulasjonene fordi Solidity mangler direkte språk-/bibliotekstøtte.

Trinn utviklere tar for Smart Contract Security.

Utviklere som bryr seg om sikkerheten til smarte kontrakter følger ulike metoder på utviklingsstadiet for å redusere risikoer, for eksempel:

  1. Å lese mellom linjene i koden og tenke fra angriperens perspektiv. 
  2. Tegne et flytskjema for å analysere informasjonsflyten og se på punktene der det finnes tilbakefallsmuligheter; Derfor kan det å ha en grafisk representasjon løse mange logiske problemer. 
  3. Bruk av smarte kontraktssikkerhetsverktøy, noen av dem har vi nevnt tidligere 

Noen begrensninger for de smarte kontraktssikkerhetsverktøyene er ikke-trivielle, ettersom du må skrive en konstruktør og deretter teste kontrakten etter å ha implementert kontrakten. Utenom dette kan ingen verktøy integreres med utviklingsprosessen; du må skrive kode i en IDE og deretter bruke et annet verktøy for å teste det. Det vil være enkelt for utviklere å teste koden på kompilatoren i stedet for å bruke noe annet verktøy. 

Vi har også sett at utviklere med forkunnskaper om smarte kontrakter og revisjon har en tendens til å vurdere koden bedre og ha mer bevissthet om beste sikkerhetspraksis. Det bidrar også til å unngå kjente sårbarheter i kontrakten. Mange nye utviklere undervurderer sikkerheten og anser det ikke som en prioritet fordi de stort sett distribuerer prosjektene sine på testnett der feil og smutthull i kontrakter ikke har noen reell innvirkning. 

konklusjonen

Smart Contract-utvikleres sikkerhetsoppfatninger og -praksis er hovedsakelig avhengig av eksterne revisjoner for å sikre sikkerheten til prosjektene deres. Ettersom de vurderer sikkerheten manuelt og ofte mangler ressurser og verktøy. Med den nylige økningen i DeFi-prosjekter og tilhørende sikkerhetsangrep, må nybegynnere utviklere ta støtte fra verktøy for å redusere risikoen på forhånd. 

14 Visninger

Tidstempel:

Mer fra Quillhash