Smart kontraktssäkerhet: en smidig SDLC-metod

Återutgiven av Platon

anhängare: 0

Lästid: 10 minuter

Blockchain citeras som en decentraliserad och manipuleringssäker reskontra. Men denna manipuleringssäkra redovisning är sårbar för hacks och utnyttjande. Decentraliseringen, som är en av de starkaste fördelarna med Blockchain, är en av nackdelarna.

Tja, det är bra, men hur är det med SDLC?

Den mjukvarulivscykelstrategi som vi ska diskutera bygger på att klassificera säkerhetssårbarheter i smarta kontrakt i flera faser.

I det första avsnittet har vi lagt upp säkerhetsfrågorna i de smarta kontrakten. Och i nästa avsnitt diskuterar vi dess lösningar uppdelade i fyra faser; Säkerhetsdesign, säkerhetsimplementering, testning före implementering och den sista, övervakning och analys.

ANALYS AV SÄKERHETSFRÅGOR I SMARTA KONTRAKT

Smarta kontrakt är sårbara för olika hacks och utnyttjar. Dessa kontrakt som är synonyma med verkliga juridiska avtal körs oberoende baserat på villkoren för de inhemska blockkedjorna.

Men har du tänkt att även de inhemska blockkedjorna också kan vara ansvariga för potentiella säkerhetshot i smarta kontrakt? Nedan presenterar vi några av egenskaperna hos blockkedjor för detsamma:

Decentralisering: Det anses vara en av fördelarna med blockchain-baserade protokoll. Men angriparna har utarbetat ett sätt att vända denna positiva egenskap till en negativ.

Skadliga aktörer kan skapa en falsk identitet för att utveckla och distribuera ett smart kontrakt. Ibland blir det svårt att identifiera ett sårbart kontrakt eftersom endast den offentliga adressen (eller) de offentliga nycklarna är tillgängliga på offentliga blockkedjor.

Öppen källkod: Det här kanske överraskar dig, men ja, i allmänhet är de flesta smarta avtalskoder något med öppen källkod.

Säg, i fallet med Ethereum Virtual Machine (EVM) är dess bytekod alltid offentlig. Och vissa Solidity-dekompilatorer kan hjälpa dig att få en smart kontraktsadress och Solidity-koden. Exponeringen av källkoden gör denna funktion till fördel för angripare.

Outvecklade blockchain-plattformar: För en utvecklare är det ett primärt krav att bekanta sig med utvecklingsplattformen. Det finns många underutvecklade eller nya blockchain-plattformar, så utvecklare kan inte utveckla en djupgående kunskap om operationer på blockchain.

Denna inkonsekvens påverkar de smarta kontrakten på grund av bristande synkronisering. Bristerna i blockchain-plattformen förblir obemärkta på grund av dess kontinuerliga utveckling.

Okända transaktioner: I den första punkten har vi diskuterat anonym identitet; på samma sätt är transaktionerna på blockkedjor inte avslöjade. Det är omöjligt att spåra transaktionerna, vilket leder till många olagliga aktiviteter. Eftersom finansiella transaktioner är inblandade kan alla säkerhetsproblem resultera i enorma ekonomiska förluster.

SMARTA KONTRAKTSSÄKERHETSLÖSNINGAR

Nu när vi går vidare med smart kontraktssäkerhet kan vi jämföra alla nödvändiga steg som krävs för att säkra ett smart kontrakt med dess utveckling. Som i traditionell mjukvaruutveckling tenderar vi att följa en utvecklingslivscykel; på samma sätt kan vi klassificera kontraktsutvecklingens livscykel.

Livscykeln för smart kontraktsutveckling kan delas in i fyra faser: säkerhetsdesign, säkerhetsimplementering, testning före implementering samt övervakning och analys.

*översikt över säkerhetsteman ur ett smart kontraktslivscykelperspektiv*

1. SÄKERHETSDESIGN

Denna första fas kapslar in tre teman; designprincip, designmönster och säkerhetsmodellering (som visas i figuren ovan). Det primära fokus för dessa teman är på kontraktsdesign och hur säkerhetshot kan avvärjas.

DESIGNPRINCIP

Designprinciper är grundläggande idéer för att designa säkra smarta kontrakt på blockkedjan. Det finns fem viktiga designprinciper för kontrakt: Förbered dig på misslyckande, utrullning noggrant, Håll kontrakten enkla, Håll dig uppdaterad och Måste veta om blockkedjeegenskaper.

Nu kanske du tänker, hur kommer de att hjälpa till att skapa ett säkert smart kontrakt?

Låt oss ta någon av principerna från ovan, säg, "Förbered dig på misslyckande" detta betyder att i frånvaro av patchsystem, bör kontraktet kunna svara på buggar. Och om någon attack äger rum, bör kontraktet kunna pausas för att förhindra ytterligare förlust.

DESIGN MÖNSTER

Inom mjukvarudesign är designmönstren de lösningar som kan återanvändas för att lösa ett problem.

Om vi tar ett exempel på Ethereum så finns det sex säkerhetsmönster; Check-effects-interaction, Emergency stop, Mutex, Speed Bump, Rate limit och Balance limit.

Vi kan använda dessa säkerhetsmönster för att lösa säkerhetsproblem i blockkedjan, som att återinträdessårbarheten kan hanteras av Mutex-mönstret.

Samtidigt kan nödstoppsmönstret hjälpa oss att avsluta ett kontrakts utförande om det påverkas av en sårbarhet.

SÄKERHETSMODELLER

Det kan finnas en skillnad mellan den utvecklade koden och den obligatoriska koden för kontrakt eftersom Solidity används för att skapa kontrakt; det här språket uppfyller Turings fullständighet, men det är benäget att göra fel.

Figuren ovan visar att denna delfas omfattar två faser; säkerhetsdesign och implementering.

Säkerhetsmodellering är direkt relaterad till affärslogik; eftersom specifikationer härrör från verksamheten kan logik klassificeras genom felfri semantik. Detta hjälper senare under den formella verifieringsprocessen som utförs för att mildra sårbarheter.

2. SÄKERHETSIMPLEMENTERING

I det här avsnittet kommer vi att täcka två av de tre teman; säkerhet

Utveckling och säkerhetsmall, eftersom vi redan har täckt säkerhetsmodellering i den senaste fasen.

SÄKERHETSUTVECKLING

Det här avsnittet kommer att se hur sårbarheter kan undvikas under kontraktsimplementeringsprocessen.

På Ethereum-plattformen har vi säkerhets-EIPs (Ethereum-förbättringsförslag) – rekommendationer för att bekämpa säkerhetsproblemen på Ethereum plattform. Därför är dessa EIP:er anmärkningsvärda för att säkert implementera smarta kontrakt.

SÄKERHETSMALL

Mallar fungerar som ursprung för nya dokument. De smarta kontraktsmallarna med driftsparametrar kopplar ett juridiskt avtal till en körbar kod.

I samband med smart avtalssäkerhet är det möjligt att extrahera standardkontraktsmallarna med uppgraderade säkerhetsparametrar, såsom säkerhetsmönster och säkerhetsbibliotek. Detta kommer att minska risken för fel i manuell kodning.

3. TESTNING INNAN INVÄNDNING

Återigen, kravet i denna fas uppstår från en av fördelarna med smarta kontrakt – "Oföränderlighet".

När de smarta kontrakten väl har skapats finns det inget sätt att ändra dem. Därför är det obligatoriskt att utföra tillräckliga tester för att säkerställa säkerheten för smarta kontrakt före implementering.

Denna fas omfattar tre säkerhetsparametrar som ska följas innan ett smart kontrakt implementeras; Rigorös formell verifiering, kodanalysverktyg och säkerhetsgranskning.

RIGORÖS FORMELL VERIFIERING

Formell verifiering är en väldefinierad process som utnyttjar matematiska resonemang och matematiska bevis för att verifiera önskade egenskaper hos systemet.

Vi kan utföra formell verifiering på smarta kontrakt då kontraktsprogrammet är kort och tidsbegränsat. Det finns flera sätt att formalisera och verifiera smarta kontrakt rigidt; vissa är baserade på kontraktskod och andra på semantiken för den virtuella Ethereum-maskinen (EVM).

KODANALYSVERKTYG

Analysen av koden görs utan att programmen körs. För detta ändamål använder vi några verktyg som kallas Static Application Security Testing (SAST) Tools. Dessa verktyg hjälper till att upptäcka säkerhetsbrister i källkoden.

Analysen som utförs av dessa verktyg kan innefatta ett eller alla av följande steg:

(I) Skapa en mellanrepresentation (IR), till exempel ett abstrakt syntaxträd (AST), för detaljerad analys.

(Ii) Komplettera IR med tillräcklig information erhållen från statisk kontroll eller datumflödesanalys och formella verifieringstekniker; dessa tekniker inkluderar: symbolisk utförande, abstrakt tolkning och symbolisk modellkontroll.

Men vilka verktyg kan man använda för att utföra kodanalys på Smart Contract?

Även om det finns många verktyg man kan använda för att utföra säkerhetsanalysen, är Oyente det mest populära.

Lyssnare kan användas för att utföra säkerhetsanalyser för EVM smarta kontrakt. Den använder "symbolsk utförande" för att upptäcka fyra vanliga buggar; transaktionsbeställningsberoende, tidsstämpelberoende, felaktigt hanterade undantag och återinträde.

Arkitekturen för Oyente visar att den tar bytekod och presenterar Ethereums globala tillstånd som indata.

En av baksidorna med Oyente är att den bara upptäcker säkerhetsbrister. Den symboliska avrättningstekniken som används av Oyente utforskar inte alla möjliga vägar. Därmed uppstår behovet av andra verktyg som Säkerhet och manuella revisioner.

SÄKERHETSREVISION

Vi börjar det här avsnittet där vi lämnade det sista; de manuella revisionerna.

Men först, låt oss förstå behovet av en säkerhetsrevision; vare sig det är Ronin Network-hacket eller Poly Network-hacket, är oreviderad kod den mest sårbara för hacks och utnyttjande.

De leder till stora ekonomiska förluster. Inte bara att få ditt Web3-projekt granskat, i själva verket, utan att få det granskat av experter är också viktigt eftersom det beror på revisorernas professionella förmåga att utföra säkerhetsrevisioner.

Återigen, var hittar man dessa professionella experter? Du behöver inte gå någonstans och leta efter pålitliga revisorer; klick https://t.me/quillhash för att komma i kontakt med någon av dem!

En idealisk smart kontraktsrevision är en kombination av manuell och automatiserad kodanalys; som vi har diskuterat i föregående punkt, även om man går efter automatiserad kodanalys från verktyg som Oyente, finns det möjligheten för oidentifierade sårbarheter i kontraktet.

För att övervinna det kan säkerhetsrevisorer manuellt analysera varje rad kod och testa dem mot potentiella sårbarheter.

4. ÖVERVAKNING OCH ANALYS

Kommer du ihåg den ständigt utvecklande principen för Blockchain som vi diskuterade från början?

Denna fas bygger på samma tema; när kontraktet har distribuerats och körts kan vissa sårbarheter som lämnats obemärkta i de tidigare stegen uppstå på grund av nya utgåvor och frekventa uppdateringar som senare gör kontrakt mindre effektiva.

Vi kan utföra; bug bounty, säkerhetsövervakning och post hoc-analys för att övervinna dessa hinder.

BUG BOUNTY

Eftersom vi överväger säkerhetsproblemen efter distributionen med kontrakt kan Bug Bounties vara till hjälp. Den formella verifieringstekniken som diskuterats tidigare är en statisk analysteknik. Bug bounty, å andra sidan, är en dynamisk analysteknik.

Konceptet bakom Bug bounty är enkelt; hackare upptäcker buggar och i gengäld får de några ekonomiska belöningar. Ser ut som en win-win situation, eller hur? Men det är det inte!

Haken här är; att värdet på buggar kan vara högre än bountyen på de grå marknaderna, och möjligheten är att hackare kan utnyttja eller sälja buggarna för att få ett högt pris.

Ibland nekar projektägarna att betala ut prispengarna om inte felen bekräftas; hackare oroar sig också för osäkerheten kring betalningar efter avslöjande av buggar.

För att övervinna detta föreslogs ett ramverk för bug-bounty, känt som "Hydra".

Hydra använder en exploit gap-teknologi som heter N-of-N-version programmering (NNVP) som ett bugg-bounty-system på blockkedjan.

SÄKERHETSÖVERVAKNING

Vi kan använda statisk kodanalys för att upptäcka säkerhetsbristerna, men den här metoden används innan de smarta kontrakten implementeras.

Men för att hitta buggar och potentiella sårbarheter i realtid måste vi övervaka och analysera transaktionsdata på blockkedjan.

Dessa sårbarheter som upptäckts genom att analysera smarta kontrakt kan kallas spårningssårbarheter. Tre typer av kontrakt ligger i fokus för dessa spårningssårbarheter;

(I) Giriga kontrakt (kontrakt som förblir vid liv och låser Ether på obestämd tid).

(Ii) Förlorade kontrakt (kontrakt som läcker pengar vårdslöst till godtyckliga användare) och,

(Iii) Självmordskontrakt (kontrakt som vilken godtycklig användare som helst kan döda).

Till och med ett begrepp om Effectively Callback Free (ECF)-objekt föreslogs för att identifiera sårbarheter genom att övervaka ECF-objekt.

I samband med detta presenterades också en onlinealgoritm; det hjälpte till att upptäcka okända sårbarheter. I samma förslag föreslogs att man skulle utföra smarta kontrakt på Testnet innan man distribuerar på Mainnet.

Monitoring UI är en Blockchain-övervakningsplattform som använder React.js. Denna plattform kan användas för att utföra transaktioner, hålla koll på tillgångar och fråga om tillståndet för Blockchain.

Vi kan inte lita på den här plattformen för säker övervakning av smarta kontrakt, men eftersom det mesta av transaktionsdata relaterade till smarta kontrakt kan hittas, kan vi upptäcka exploateringar i realtid genom att spåra överföringen av tillgångar.

POST HOC ANALYS

Post Hoc Analysis använder blockchain-transaktionsdata för att analysera, upptäcka eller spåra potentiella hot på blockkedjan i lekmannatermer.

Om vi diskuterar Graph-analysen var den utformad som ett tillvägagångssätt för att samla in all transaktionsdata (detta inkluderade interna transaktioner från smarta kontrakt).

Med hjälp av denna data utarbetade de tre grafer;

(I) En penningflödesgraf (MFG)

(Ii) Graf för att skapa kontrakt (CCG) och,

(Iii) Kontraktsanropsdiagram (CIG)

Baserat på analysen av diagrammen som nämns ovan föreslogs många nya rön, såsom lösningar på säkerhetsfrågor mellan flera kontrakt som interagerar med varandra.

Ponzi-schemat är ett av de klassiska bedrägerisystemen genom vilka ett stort antal medel kan förvärvas och påverka den inhemska blockkedjan. För att bekämpa detta bedrägeri föreslogs en klassificeringsmekanism för att upptäcka Ponzi-scheman på Ethereum.

Denna mekanism använder datautvinning och maskininlärning för att upptäcka Ponzi-kontrakt. Denna process fungerar även om källkoden för de smarta kontrakten inte är tillgänglig.

*Ramverket för smart Ponzi-schemadetektering*

Nyckelhämtning

Det var det, ja, det var det för nu!

Om du har varit med oss hittills skulle vi uppskatta det. Utan att sträcka ut mer, avslutningsvis, skulle vi bara säga att ekosystemet av smarta kontrakt är decentraliserat, och det är svårt att korrigera för buggar.

Vi har försökt bryta ner säkerheten för smarta kontrakt ur mjukvarans livscykelperspektiv.

Vi har först diskuterat blockkedjans nyckelfunktioner som ansvarar för säkerhetsfrågor i smarta kontrakt. Vi klassificerade säkerhetslösningarna för de smarta kontrakten i fyra faser. Vi hoppas kunna ta med fler inlägg för att hålla dig före utmaningarna i det växande Web3-ekosystemet.

Vad tycker du om denna smidiga SDLC-metod för smart kontraktssäkerhet? Dela dina tankar i kommentarerna nedan!

46 Visningar

Posten Smart kontraktssäkerhet: en smidig SDLC-metod visades först på Blog.quillhash.

Tidsstämpel: 22 april 2022