Slimme contractbeveiliging: een agile SDLC-aanpak PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.

Slimme contractbeveiliging: een agile SDLC-aanpak 

Leestijd: 10 minuten

Blockchain wordt geciteerd als een gedecentraliseerd en fraudebestendig grootboek. Maar dit fraudebestendige grootboek is kwetsbaar voor hacks en exploits. De decentralisatie, een van de sterkste voordelen van Blockchain, is een van de nadelen. 

Dat is prima, maar hoe zit het met SDLC? 

De software-levenscyclusbenadering die we gaan bespreken, is gebaseerd op het classificeren van beveiligingsproblemen in slimme contracten in meerdere fasen. 

In het eerste gedeelte hebben we de beveiligingsproblemen in de slimme contracten uiteengezet. En in de volgende sectie bespreken we de oplossingen verdeeld in vier fasen; Beveiligingsontwerp, beveiligingsimplementatie, testen vóór implementatie en de laatste, monitoring en analyse. 

ANALYSE VAN VEILIGHEIDSPROBLEMEN IN SLIMME CONTRACTEN 

Slimme contracten zijn kwetsbaar voor verschillende hacks en exploits. Deze contracten die synoniem zijn met juridische overeenkomsten in de echte wereld, worden onafhankelijk uitgevoerd op basis van de voorwaarden van de native blockchains. 

Maar heb je gedacht dat zelfs die native blockchains ook verantwoordelijk kunnen zijn voor potentiële beveiligingsbedreigingen in slimme contracten? Hieronder presenteren we enkele kenmerken van Blockchains daarvoor:

Decentralisatie: Het wordt beschouwd als een van de voordelen van op blockchain gebaseerde protocollen. Maar de aanvallers hebben een manier bedacht om van deze positieve eigenschap een negatieve te maken. 

Kwaadwillenden kunnen een valse identiteit creëren om een ​​slim contract te ontwikkelen en in te zetten. Soms wordt het moeilijk om een ​​kwetsbaar contract te identificeren, omdat alleen het openbare adres (of) de openbare sleutels beschikbaar zijn op openbare blockchains. 

Open source-code: Dit zal je misschien verbazen, maar ja, over het algemeen zijn de meeste slimme contractcodes enigszins open-source. 

Stel dat in het geval van Ethereum Virtual Machine (EVM), de bytecode altijd openbaar is. En sommige Solidity-decompilers kunnen u helpen een slim contractadres en de Solidity-code te krijgen. De blootstelling van de broncode maakt deze functie een voordeel voor aanvallers. 

Onontwikkelde blockchain-platforms: Voor een ontwikkelaar is het een eerste vereiste om vertrouwd te raken met het ontwikkelplatform. Er zijn veel onderontwikkelde of nieuwe blockchain-platforms, dus ontwikkelaars kunnen geen diepgaande kennis van operaties op de blockchain ontwikkelen. 

Deze inconsistentie beïnvloedt de slimme contracten vanwege een gebrek aan synchronisatie. De gebreken in het blockchain-platform blijven onopgemerkt vanwege de voortdurende evolutie. 

Onbekende transacties: In het eerste punt hebben we het gehad over anonieme identiteit; evenzo zijn de transacties op blockchains niet bekendgemaakt. Het is onmogelijk om de transacties te traceren, wat leidt tot veel illegale activiteiten. Omdat er financiële transacties bij betrokken zijn, kan elk beveiligingsprobleem resulteren in enorme financiële verliezen. 

SLIMME CONTRACTBEVEILIGINGSOPLOSSINGEN

Nu we doorgaan met de beveiliging van slimme contracten, kunnen we alle noodzakelijke stappen vergelijken die nodig zijn om een ​​slim contract te beveiligen met de evolutie ervan. Net als bij traditionele softwareontwikkeling, hebben we de neiging om een ​​ontwikkelingslevenscyclus te volgen; op dezelfde manier kunnen we de levenscyclus van contractontwikkeling classificeren. 

De levenscyclus van de ontwikkeling van slimme contracten kan worden onderverdeeld in vier fasen: beveiligingsontwerp, beveiligingsimplementatie, testen vóór implementatie en monitoring en analyse.

overzicht van beveiligingsthema's vanuit het perspectief van de levenscyclus van een slim contract
overzicht van beveiligingsthema's vanuit een levenscyclusperspectief van slimme contracten

1. VEILIGHEIDSONTWERP 

Deze eerste fase omvat drie thema's; ontwerpprincipe, ontwerppatroon en beveiligingsmodellering (zoals weergegeven in de bovenstaande afbeelding). De primaire focus van deze thema's ligt op contractontwerp en hoe beveiligingsrisico's kunnen worden afgewend. 

ONTWERP PRINCIPE

Ontwerpprincipes zijn fundamentele ideeën voor het ontwerpen van veilige slimme contracten op de blockchain. Er zijn vijf essentiële ontwerpprincipes voor contracten: voorbereiden op mislukking, zorgvuldig uitrollen, contracten eenvoudig houden, op de hoogte blijven en must-know over blockchain-eigenschappen. 

Nu denk je misschien, hoe zullen ze helpen bij het creëren van een veilig slim contract? 

Laten we een van de bovenstaande principes nemen, bijvoorbeeld "Bereid je voor op mislukking", dit betekent dat bij afwezigheid van patchschema's, het contract in staat zou moeten zijn om op bugs te reageren. En als er een aanval plaatsvindt, moet het contract kunnen worden onderbroken om verder verlies te voorkomen. 

ONTWERP PATROON

Bij softwareontwerp zijn de ontwerppatronen de oplossingen die kunnen worden hergebruikt om een ​​probleem op te lossen. 

Als we een voorbeeld van Ethereum nemen, zijn er zes beveiligingspatronen; Check-effecten-interactie, Noodstop, Mutex, Verkeersdrempel, Snelheidslimiet en Balanslimiet.  

We kunnen deze beveiligingspatronen gebruiken om beveiligingsproblemen in de blockchain aan te pakken, zoals de kwetsbaarheid voor herintreding die kan worden afgehandeld door het Mutex-patroon. 

Tegelijkertijd kan het noodstoppatroon ons helpen de uitvoering van een contract te beëindigen als het wordt getroffen door een kwetsbaarheid. 

VEILIGHEIDSMODELLEN

Er kan een verschil zijn tussen de ontwikkelde code en de vereiste code voor contracten, aangezien Solidity wordt gebruikt om contracten te maken; deze taal voldoet aan de volledigheid van Turing, maar is gevoelig voor fouten. 

Bovenstaande figuur laat zien dat deze deelfase twee fasen omvat; beveiligingsontwerp en -implementatie. 

Beveiligingsmodellering is direct gerelateerd aan bedrijfslogica; aangezien specificaties zijn afgeleid van het bedrijf, kan logica worden geclassificeerd door foutloze semantiek. Dit helpt later tijdens het formele verificatieproces dat wordt uitgevoerd om kwetsbaarheden te verminderen. 

2. IMPLEMENTATIE VAN DE BEVEILIGING

In deze sectie zullen we twee van de drie thema's behandelen; beveiliging

Ontwikkeling en Beveiligingssjabloon, zoals we Beveiligingsmodellering in de laatste fase al hebben behandeld.

VEILIGHEIDSONTWIKKELING

In deze paragraaf wordt beschreven hoe kwetsbaarheden tijdens het contractuitvoeringsproces kunnen worden vermeden. 

Op het Ethereum-platform hebben we beveiligings-EIP's (Ethereum-verbeteringsvoorstellen) - aanbevelingen om de beveiligingsproblemen op de Ethereum platform. Deze EIP's zijn dus opmerkelijk voor het veilig implementeren van slimme contracten. 

BEVEILIGINGSSJABLOON

Sjablonen dienen als oorsprong voor nieuwe documenten. De slimme contractsjablonen met operationele parameters koppelen een juridische overeenkomst aan een uitvoerbare code. 

In de context van slimme contractbeveiliging is het mogelijk om de standaard contractsjablonen te extraheren met verbeterde beveiligingsparameters, zoals beveiligingspatronen en beveiligingsbibliotheken. Dit verkleint de kans op fouten bij handmatige codering. 

3. TESTEN VOOR INGEBRUIKNAME

Nogmaals, de vereiste van deze fase komt voort uit een van de voordelen van slimme contracten - "onveranderlijkheid". 

Zodra de slimme contracten zijn gemaakt, is er geen manier om ze te wijzigen. Daarom is het verplicht om voldoende tests uit te voeren om de beveiliging van slimme contracten te waarborgen voordat ze worden geïmplementeerd.

Deze fase omvat drie beveiligingsparameters die moeten worden gevolgd voordat een slim contract wordt geïmplementeerd; Strenge formele verificatie, code-analysetools en beveiligingsaudit. 

STRENGERE FORMELE VERIFICATIE

Formele verificatie is een goed gedefinieerd proces dat gebruikmaakt van wiskundige redeneringen en wiskundige bewijzen om de gewenste eigenschappen van het systeem te verifiëren. 

We kunnen formele verificatie uitvoeren op slimme contracten, aangezien het contractprogramma kort en tijdgebonden is. Er zijn meerdere manieren om slimme contracten strikt te formaliseren en te verifiëren; sommige zijn gebaseerd op contractcode en andere op de semantiek van de virtuele Ethereum-machine (EVM). 

CODE ANALYSE HULPMIDDELEN

De analyse van de code wordt gedaan zonder de programma's uit te voeren. Voor dit doel gebruiken we een aantal tools genaamd Static Application Security Testing (SAST) Tools. Deze tools helpen bij het ontdekken van beveiligingsfouten in de broncode. 

De analyse die door deze tools wordt uitgevoerd, kan een of alle van de volgende stappen omvatten:

(I) Maak een intermediaire representatie (IR), zoals een abstracte syntaxisboom (AST), voor gedetailleerde analyse. 

(Ii) Vul IR aan met voldoende informatie verkregen uit statische controle of datumstroomanalyse en formele verificatietechnieken; deze technieken omvatten: symbolische uitvoering, abstracte interpretatie en symbolische modelcontrole. 

Maar wat zijn de tools die je kunt gebruiken om code-analyse op Smart Contract uit te voeren? 

Hoewel er veel tools zijn die je kunt gebruiken om de beveiligingsanalyse uit te voeren, is Oyente de meest populaire. 

Luisteraar kan worden gebruikt om beveiligingsanalyses uit te voeren voor de EVM slimme contracten. Het gebruikt "symbolische uitvoering" om vier veelvoorkomende bugs te ontdekken; afhankelijkheid van transactiebestelling, afhankelijkheid van tijdstempels, verkeerd behandelde uitzonderingen en herintreding. 

De architectuur van Oyente
De architectuur van Oyente

De architectuur van Oyente laat zien dat het bytecode nodig heeft en de globale status van Ethereum als invoer presenteert. 

Een van de keerzijden van Oyente is dat het alleen beveiligingsproblemen detecteert. De symbolische uitvoeringstechniek die Oyente gebruikt, verkent niet alle mogelijke paden. Zo ontstaat de behoefte aan andere tools zoals beveiliging en handmatige audits. 

VEILIGHEIDSAUDIT

We beginnen deze sectie waar we de laatste verlieten; de handmatige controles. 

Maar laten we eerst de noodzaak van een beveiligingsaudit begrijpen; of het nu de Ronin Network-hack of de Poly Network-hack is, niet-gecontroleerde code is het meest kwetsbaar voor hacks en exploits. 

Ze leiden tot enorme financiële verliezen. Niet alleen uw Web3-project laten auditen, maar het is ook belangrijk om het te laten controleren door deskundige professionals, aangezien het afhangt van de professionele bekwaamheid van de auditors om beveiligingsaudits uit te voeren. 

Nogmaals, waar vind je die professionele experts? U hoeft nergens heen op zoek naar betrouwbare auditors; Klik https://t.me/quillhash om met een van hen in contact te komen! 

Een ideale smart contract audit is een combinatie van handmatige en geautomatiseerde code-analyse; zoals we in het vorige punt hebben besproken, is er de mogelijkheid van niet-geïdentificeerde kwetsbaarheden in het contract, ook al gaan we na geautomatiseerde code-analyse van tools zoals Oyente. 

Om dat te verhelpen, kunnen beveiligingsauditors elke regel code handmatig analyseren en testen op mogelijke kwetsbaarheden. 

4. MONITORING EN ANALYSE

Herinner je je het steeds evoluerende principe van Blockchain dat we aanvankelijk bespraken? 

Deze fase is gebaseerd op hetzelfde thema; zodra het contract is geïmplementeerd en uitgevoerd, kunnen sommige kwetsbaarheden optreden die in de vorige fasen onopgemerkt zijn gebleven als gevolg van nieuwe releases en frequente updates die contracten later minder efficiënt maken. 

Wij kunnen uitvoeren; bug bounty, beveiligingsmonitoring en post-hocanalyse om deze barrières te overwinnen. 

BUG BOUNTY

Omdat we de beveiligingsproblemen met contracten na de implementatie overwegen, kunnen Bug Bounties nuttig zijn. De eerder besproken formele verificatietechniek is een statische analysetechniek. Bug bounty daarentegen is een dynamische analysetechniek. 

Het concept achter Bug bounty is eenvoudig; hackers ontdekken bugs en in ruil daarvoor krijgen ze een financiële beloning. Lijkt me een win-win situatie, toch? Maar dat is het niet!

De vangst hier is; dat de waarde van bugs hoger kan zijn dan de premie in de grijze markten, en de mogelijkheid is dat hackers de bugs kunnen exploiteren of verkopen om een ​​hoge prijs te krijgen. 

Soms weigeren de projecteigenaren de premie te betalen, tenzij de bugs worden bevestigd; hackers maken zich ook zorgen over de onzekerheid van betalingen na de onthulling van bugs. 

Om dit te verhelpen, werd een bug bounty-raamwerk voorgesteld, bekend als "Hydra". 

Hydra maakt gebruik van een exploit gap-technologie genaamd N-of-N-version programming (NNVP) als een bug bounty-systeem op de blockchain. 

Het Hydra-frame met koppen
Het Hydra-frame met koppen

VEILIGHEIDSCONTROLE

We kunnen statische code-analyse gebruiken om de beveiligingsproblemen te ontdekken, maar deze methode wordt gebruikt voordat de slimme contracten worden geïmplementeerd. 

Maar om bugs en potentiële kwetsbaarheden in realtime te vinden, moeten we transactiegegevens op de blockchain monitoren en analyseren. 

Deze kwetsbaarheden die worden ontdekt door het analyseren van slimme contracten, kunnen traceerbare kwetsbaarheden worden genoemd. Drie soorten contracten liggen aan de basis van deze traceringskwetsbaarheden; 

(I) Hebzuchtige contracten (contracten die in leven blijven en Ether voor onbepaalde tijd vergrendelen).

(Ii) Verloren contracten (contracten die slordig geld lekken naar willekeurige gebruikers) en,

(Iii) Suïcidale contracten (contracten die elke willekeurige gebruiker kan doden). 

Er werd zelfs een idee van ECF-objecten (Effectly Callback Free) voorgesteld om kwetsbaarheden te identificeren door ECF-objecten te monitoren. 

In het kader hiervan werd ook een online algoritme gepresenteerd; het hielp onbekende kwetsbaarheden te ontdekken. In hetzelfde voorstel werd voorgesteld om slimme contracten op Testnet uit te voeren voordat ze op het Mainnet worden geïmplementeerd. 

Monitoring UI is een Blockchain-monitoringplatform dat gebruik maakt van React.js. Dit platform kan worden gebruikt om transacties uit te voeren, activa te controleren en te informeren naar de status van Blockchain. 

We kunnen niet vertrouwen op dit platform voor veilige monitoring van slimme contracten, maar aangezien de meeste transactiegegevens met betrekking tot slimme contracten kunnen worden gevonden, kunnen we exploits in realtime detecteren door de overdracht van activa te volgen. 

POSTHOCANALYSE

Post Hoc-analyse maakt gebruik van blockchain-transactiegegevens om potentiële bedreigingen op de blockchain in lekentermen te analyseren, ontdekken of op te sporen. 

Als we de Graph-analyse bespreken, is deze ontworpen als een benadering om alle transactiegegevens te verzamelen (inclusief interne transacties van slimme contracten). 

Met behulp van deze gegevens maakten ze drie grafieken; 

(I) Een geldstroomgrafiek (MFG)

(Ii) Grafiek voor het maken van contracten (CCG) en,

(Iii) Grafiek voor contractaanroep (CIG)

Op basis van de analyse van de bovengenoemde grafieken werden veel nieuwe bevindingen voorgesteld, zoals oplossingen voor beveiligingsproblemen tussen meerdere contracten die met elkaar in wisselwerking staan. 

Een overzicht van grafiekanalyse
Een overzicht van grafiekanalyse

Het Ponzi-schema is een van de klassieke fraudeschema's waarmee een groot aantal fondsen kan worden verkregen en de native blockchain kan worden beïnvloed. Om deze fraude te bestrijden, werd een classificatiemechanisme voorgesteld om Ponzi-schema's op Ethereum te detecteren. 

Dit mechanisme maakt gebruik van datamining en machine learning om Ponzi-contracten te detecteren. Dit proces werkt zelfs als de broncode van de slimme contracten niet beschikbaar is. 

Het raamwerk van slimme detectie van Ponzi-schema's
Het raamwerk van slimme detectie van Ponzi-schema's

Sleutel afhaalmaaltijden

Dat was het, ja, dat was het voor nu!

Als je tot nu toe bij ons bent geweest, zouden we het op prijs stellen. Zonder meer uit te rekken, zouden we tot slot alleen maar zeggen dat het ecosysteem van slimme contracten gedecentraliseerd is en dat het moeilijk is om bugs te patchen. 

We hebben geprobeerd de beveiliging van slimme contracten te doorbreken vanuit het perspectief van de softwarelevenscyclus. 

We hebben eerst de belangrijkste functies van de blockchain besproken die verantwoordelijk zijn voor: beveiligingsproblemen in slimme contracten. We hebben de beveiligingsoplossingen voor de slimme contracten ingedeeld in vier fasen. We hopen meer berichten te plaatsen om u de uitdagingen in het groeiende Web3-ecosysteem voor te blijven. 

Wat vind je van deze agile SDLC-aanpak voor slimme contractbeveiliging? Deel uw mening in de reacties hieronder!

46 keer bekeken

De post Slimme contractbeveiliging: een agile SDLC-aanpak  verscheen eerst op Blog.quillhash.

Tijdstempel:

Meer van Quillhash