Intelligens szerződésbiztonság: Agilis SDLC-megközelítés 

Olvasási idő: 10 jegyzőkönyv

A blokkláncot decentralizált és manipulációbiztos főkönyvként említik. Ez a manipulációbiztos főkönyv azonban ki van téve a feltöréseknek és a kihasználásoknak. A decentralizáció, amely a Blockchain egyik legerősebb előnye, az egyik hátránya. 

Nos, ez rendben van, de mi van az SDLC-vel? 

A szoftver-életciklus-megközelítés, amelyről most beszélni fogunk, az intelligens szerződések biztonsági réseinek több fázisba sorolásán alapul. 

Az első részben lefektettük az intelligens szerződések biztonsági kérdéseit. A következő részben pedig négy fázisra bontva tárgyaljuk a megoldásait; Biztonsági tervezés, biztonsági megvalósítás, tesztelés a telepítés előtt, és az utolsó, a megfigyelés és elemzés. 

AZ OKOS SZERZŐDÉSEK BIZTONSÁGI KÉRDÉSÉNEK ELEMZÉSE 

Az intelligens szerződések ki vannak téve a különféle feltöréseknek és kihasználásoknak. Ezek a szerződések, amelyek egyet jelentenek a valós jogi megállapodásokkal, függetlenül futnak a natív blokkláncok feltételei alapján. 

De arra gondoltál, hogy még ezek a natív blokkláncok is felelősek lehetnek az intelligens szerződések potenciális biztonsági fenyegetéseiért? Az alábbiakban a blokkláncok néhány jellemzőjét mutatjuk be:

Decentralizálás: A blokklánc alapú protokollok egyik előnyének tartják. A támadók azonban kitalálták a módját, hogy ezt a pozitív tulajdonságot negatívvá alakítsák. 

A rosszindulatú szereplők hamis identitást hozhatnak létre egy intelligens szerződés kidolgozásához és bevezetéséhez. Néha nehéz lesz azonosítani a sebezhető szerződést, mivel csak a nyilvános cím (vagy) nyilvános kulcsok érhetők el a nyilvános blokkláncokon. 

Nyílt forráskódú kód: Ez meglepő lehet, de igen, általában a legtöbb intelligens szerződési kód valamelyest nyílt forráskódú. 

Tegyük fel, hogy az Ethereum Virtual Machine (EVM) esetében a bájtkódja mindig nyilvános. Néhány Solidity visszafordító pedig segíthet egy intelligens szerződéscím és a Solidity kód megszerzésében. A forráskód megjelenése ezt a funkciót előnyben részesíti a támadók számára. 

Fejletlen blokklánc platformok: Egy fejlesztő számára elsődleges követelmény, hogy ismerkedjen a fejlesztői platformmal. Sok alulfejlett vagy új blokklánc platform létezik, így a fejlesztők nem tudnak mélyreható ismereteket szerezni a blokklánc műveleteiről. 

Ez az inkonzisztencia a szinkronizálás hiánya miatt érinti az intelligens szerződéseket. A blokklánc platform hibái a folyamatos fejlődés miatt észrevétlenek maradnak. 

Ismeretlen tranzakciók: Az első pontban az anonim személyazonosságot tárgyaltuk; hasonlóképpen a blokkláncokon végzett tranzakciók nem nyilvánosak. Lehetetlen nyomon követni a tranzakciókat, ami számos illegális tevékenységhez vezet. Mivel pénzügyi tranzakciókról van szó, minden biztonsági probléma hatalmas pénzügyi veszteséget okozhat. 

OKOS SZERZŐDÉSBIZTONSÁGI MEGOLDÁSOK

Most, az intelligens szerződések biztonsága terén, összehasonlíthatjuk az intelligens szerződés biztosításához szükséges összes lépést annak fejlődésével. A hagyományos szoftverfejlesztéshez hasonlóan hajlamosak vagyunk egy fejlesztési életciklust követni; hasonlóan osztályozhatjuk a szerződésfejlesztési életciklust. 

Az intelligens szerződések fejlesztési életciklusa négy szakaszra osztható: biztonsági tervezés, biztonsági megvalósítás, telepítés előtti tesztelés, valamint figyelés és elemzés.

1. BIZTONSÁGI TERVEZÉS 

Ez az első szakasz három témát foglal magában; tervezési elv, tervezési minta és biztonsági modellezés (a fenti ábra szerint). Ezeknek a témáknak a középpontjában a szerződések tervezése és a biztonsági fenyegetések elkerülésének módja áll. 

TERVEZÉSI ALAPELV

A tervezési elvek alapvető ötletek a biztonságos intelligens szerződések blokkláncon történő megtervezéséhez. A szerződések megtervezésének öt alapvető elve van: Készüljön fel a kudarcra, óvatosan terjessze ki, tartsa egyszerű a szerződéseket, Maradjon naprakész, és ismerje meg a blokklánc tulajdonságait. 

Most azt gondolhatja, hogyan fognak segíteni egy biztonságos intelligens szerződés létrehozásában? 

Vegyük felülről bármelyik alapelvet, mondjuk: „Készülj fel a kudarcra” ez azt jelenti, hogy javítási sémák hiányában a szerződésnek képesnek kell lennie reagálni a hibákra. És ha bármilyen támadásra kerül sor, a szerződésnek szüneteltethetőnek kell lennie a további veszteségek elkerülése érdekében. 

TERVEZÉSI MINTA

A szoftvertervezésben a tervezési minták azok a megoldások, amelyek újra felhasználhatók a probléma megoldására. 

Ha az Ethereum példáját vesszük, hat biztonsági minta létezik; Hatások ellenőrzése, interakció, Vészleállítás, Mutex, Sebességmérő, Sebességkorlát és Egyensúlykorlát.  

Ezeket a biztonsági mintákat használhatjuk a blokklánc biztonsági problémáinak megoldására, például a visszatérési sebezhetőséget a Mutex minta kezelheti. 

Ugyanakkor a Vészleállítási minta segíthet abban, hogy felmondjuk a szerződés végrehajtását, ha azt egy biztonsági rés érinti. 

BIZTONSÁGI MODELLEZÉS

Különbség lehet a kidolgozott kód és a szerződésekhez szükséges kód között, mivel a szerződések létrehozásához a Solidity szolgál; ez a nyelv kielégíti a Turing-teljességet, de hajlamos a hibákra. 

A fenti ábra azt mutatja, hogy ez az alfázis két fázist fed le; biztonsági tervezés és kivitelezés. 

A biztonsági modellezés közvetlenül kapcsolódik az üzleti logikához; mivel a specifikációk az üzletből származnak, a logika hibamentes szemantika alapján osztályozható. Ez később a hivatalos ellenőrzési folyamat során segít a sebezhetőségek enyhítésében. 

2. BIZTONSÁGI MEGVALÓSÍTÁS

Ebben a részben a három téma közül kettővel foglalkozunk; Biztonság

Fejlesztési és Biztonsági sablon, ahogyan az utolsó fázisban már foglalkoztunk a biztonsági modellezéssel.

BIZTONSÁGI FEJLESZTÉS

Ez a rész bemutatja, hogyan kerülhetők el a sebezhetőségek a szerződés végrehajtási folyamata során. 

Az Ethereum platformon biztonsági EIP-k (Ethereum javítási javaslatok) találhatók – ajánlások a biztonsági problémák leküzdésére Ethereum felület. Így ezek az EIP-k figyelemre méltóak az intelligens szerződések biztonságos megvalósítása szempontjából. 

BIZTONSÁGI SABLON

A sablonok az új dokumentumok forrásaként szolgálnak. A működési paraméterekkel rendelkező intelligens szerződéssablonok jogi megállapodást kötnek egy végrehajtható kódhoz. 

Az intelligens szerződésbiztonsággal összefüggésben lehetőség nyílik a szabványos szerződéssablonok kibontására frissített biztonsági paraméterekkel, például biztonsági mintákkal és biztonsági könyvtárakkal. Ez csökkenti a hibák lehetőségét a kézi kódolás során. 

3. BEVEZETÉS ELŐTT TESZTELÉS

Ennek a szakasznak a követelménye ismét az intelligens szerződések egyik előnyéből – a „változhatatlanságból” – adódik. 

Az intelligens szerződések létrehozása után nincs mód rajtuk módosítani. Ezért kötelező elegendő teszt elvégzése az intelligens szerződések biztonságának biztosítása érdekében a telepítés előtt.

Ez a fázis három biztonsági paramétert fed le, amelyeket követni kell az intelligens szerződés bevezetése előtt; Szigorú formális ellenőrzés, kódelemző eszközök és biztonsági audit. 

SZIGORÚ FORMÁLIS ELLENŐRZÉS

A formális ellenőrzés egy jól meghatározott folyamat, amely matematikai érvelést és matematikai bizonyítékokat használ a rendszer kívánt tulajdonságainak ellenőrzésére. 

Az okos szerződések formális ellenőrzését el tudjuk végezni, mivel a szerződési program rövid és határidőhöz kötött. Az intelligens szerződések szigorú formalizálásának és ellenőrzésének többféle módja van; egyesek szerződéskódon, mások pedig az Ethereum virtuális gép (EVM) szemantikáján alapulnak. 

KÓDELEMZŐ ESZKÖZÖK

A kód elemzése a programok végrehajtása nélkül történik. Erre a célra a Static Application Security Testing (SAST) eszközöket használjuk. Ezek az eszközök segítenek a forráskód biztonsági hibáinak felfedezésében. 

Az ezekkel az eszközökkel végzett elemzés a következő lépések egyikét vagy mindegyikét tartalmazhatja:

(I) Hozzon létre egy köztes reprezentációt (IR), például egy absztrakt szintaxisfát (AST) a részletes elemzéshez. 

(Ii) a Ki kell egészíteni az IR-t a statikus vezérlésből vagy a dátumfolyam-elemzésből és a formális ellenőrzési technikákból nyert elegendő információval; ezek a technikák a következők: szimbolikus végrehajtás, absztrakt értelmezés és szimbolikus modellellenőrzés. 

De milyen eszközökkel lehet kódelemzést végezni a Smart Contract-on? 

Bár számos eszköz használható a biztonsági elemzés elvégzésére, az Oyente a legnépszerűbb. 

Hallgató használható biztonsági elemzés elvégzésére az EVM intelligens szerződésekhez. „Szimbolikus végrehajtást” használ négy gyakori hiba felfedezésére; tranzakció-megrendelés-függőség, időbélyeg-függőség, rosszul kezelt kivételek és újbóli belépés. 

Az Oyente architektúrája azt mutatja, hogy bájtkódot vesz fel, és bemenetként jeleníti meg az Ethereum globális állapotát. 

Az Oyente egyik másik oldala, hogy csak a biztonsági réseket észleli. Az Oyente által használt szimbolikus végrehajtási technika nem tárja fel az összes lehetséges utat. Így más eszközök, például biztonsági és kézi ellenőrzések iránti igény is felmerül. 

BIZTONSÁGI AUDIT

Ezt a részt ott kezdjük, ahol az előzőt hagytuk; a kézi ellenőrzéseket. 

Először azonban értsük meg a biztonsági audit szükségességét; Legyen szó a Ronin Network feltöréséről vagy a Poly Network feltöréséről, a nem auditált kód a legsebezhetőbb a feltörésekkel és kizsákmányolásokkal szemben. 

Hatalmas anyagi veszteségekhez vezetnek. Valójában nem csak a Web3 projekt auditálása, hanem szakértő szakemberek általi auditálása is számít, mivel ez az auditorok biztonsági auditok elvégzésére vonatkozó szakmai képességétől függ. 

Még egyszer, hol lehet megtalálni ezeket a szakmai szakértőket? Nem kell sehova mennie, ha megbízható auditorokat keres; kattintson https://t.me/quillhash hogy felvegye a kapcsolatot valamelyikükkel! 

Az ideális intelligens szerződés-audit a kézi és az automatizált kódelemzés kombinációja; Amint azt az előző pontban tárgyaltuk, annak ellenére, hogy az Oyente-hoz hasonló eszközökből származó automatizált kódelemzést követve fennáll a lehetőség azonosítatlan sérülékenységekre a szerződésben. 

Így ennek kiküszöbölésére a biztonsági auditorok manuálisan elemezhetik a kód minden sorát, és tesztelhetik azokat a lehetséges sebezhetőségek ellen. 

4. MONITORING ÉS ELEMZÉS

Emlékszel a Blockchain folyamatosan fejlődő elvére, amelyről az elején beszéltünk? 

Ez a szakasz ugyanazon a témán alapul; a szerződés telepítése és futtatása után az új kiadások és a gyakori frissítések miatt előfordulhatnak bizonyos, az előző szakaszokban észrevétlenül hagyott sebezhetőségek, amelyek később a szerződések hatékonyságát csökkentik. 

El tudjuk végezni; bug bounty, biztonsági megfigyelés és post hoc elemzés az akadályok leküzdésére. 

BUG BOUNTY

Mivel a szerződésekkel kapcsolatos telepítés utáni biztonsági problémákat mérlegeljük, a Bug Bounties hasznos lehet. A korábban tárgyalt formális ellenőrzési technika egy statikus elemzési technika. A bug bounty viszont egy dinamikus elemzési technika. 

A Bug bounty mögötti koncepció egyszerű; a hackerek hibákat fedeznek fel, és cserébe némi anyagi jutalmat kapnak. Úgy néz ki, mint egy win-win helyzet, igaz? De nem az!

A fogás itt az; hogy a hibák értéke magasabb lehet, mint a szürke piacokon a jutalom, és fennáll annak a lehetősége, hogy a hackerek kihasználják vagy eladják a hibákat, hogy magas árat kapjanak. 

Néha a projekttulajdonosok megtagadják a jutalom kifizetését, hacsak nem erősítik meg a hibákat; A hackerek a hibák feltárását követően a fizetések bizonytalansága miatt is aggódnak. 

Ennek kiküszöbölésére egy bug bounty keretet javasoltak, amely „Hydra” néven ismert. 

A Hydra az N-of-N-verzió programozás (NNVP) elnevezésű exploit gap technológiát alkalmazza a blokklánc hibajavító rendszereként. 

BIZTONSÁGI FELÜGYELET

Statikus kódelemzést használhatunk a biztonsági rések felderítésére, de ezt a módszert az intelligens szerződések telepítése előtt használjuk. 

De ahhoz, hogy valós időben megtaláljuk a hibákat és a lehetséges sebezhetőségeket, figyelnünk kell és elemeznünk kell a tranzakciós adatokat a blokkláncon. 

Ezeket az intelligens szerződések elemzése során felfedezett sebezhetőségeket nyomkövetési sebezhetőségnek nevezhetjük. Három típusú szerződés áll ezeknek a nyomkövetési sebezhetőségeknek a középpontjában; 

(I) Mohó szerződések (olyan szerződések, amelyek életben maradnak, és határozatlan időre bezárják az Ethert).

(Ii) a Tékozló szerződések (olyan szerződések, amelyek hanyagul önkényes felhasználókhoz juttatják a pénzeszközöket) és

(Iii) Öngyilkos szerződések (olyan szerződések, amelyeket bármely önkényes felhasználó megölhet). 

Még a hatékonyan visszahívásmentes (ECF) objektumok fogalmát is javasolták a sebezhetőségek azonosítására az ECF-objektumok megfigyelésével. 

Ezzel összefüggésben egy online algoritmust is bemutattak; segített felfedezni az ismeretlen sebezhetőségeket. Ugyanebben a javaslatban azt javasolták, hogy kössön intelligens szerződéseket a Testneten a Mainnet hálózaton történő telepítés előtt. 

A Monitoring UI egy React.js-t használó blokklánc-megfigyelési platform. Ezen a platformon lehet tranzakciókat lebonyolítani, vagyontárgyakat ellenőrizni, és érdeklődni a Blockchain állapotáról. 

Az intelligens szerződések biztonságos monitorozásában erre a platformra nem támaszkodhatunk, de mivel az intelligens szerződésekkel kapcsolatos tranzakciós adatok többsége megtalálható, így az eszközök átadásának nyomon követésével valós időben tudjuk észlelni a kihasználásokat. 

POST-HOC ELEMZÉS

A Post Hoc Analysis a blokklánc tranzakciós adatait használja a blokklánc potenciális fenyegetéseinek elemzésére, felfedezésére vagy nyomon követésére, laikus kifejezésekkel élve. 

Ha a Graph elemzést tárgyaljuk, akkor azt az összes tranzakciós adat (ideértve az intelligens szerződésekből származó belső tranzakciókat is) összegyűjtésére tervezték. 

Ezen adatok segítségével három grafikont készítettek; 

(I) Pénzáramlási grafikon (MFG)

(Ii) a Szerződés létrehozási grafikon (CCG) és

(Iii) Szerződéshívási grafikon (CIG)

A fent említett grafikonok elemzése alapján számos új megállapítás született, például több, egymással kölcsönhatásban álló szerződés közötti biztonsági problémák megoldása. 

A Ponzi-séma egyike azon klasszikus csalási rendszereknek, amelyeken keresztül nagyszámú alap szerezhető meg, és hatással van a natív blokkláncra. A csalás elleni küzdelem érdekében egy osztályozó mechanizmust javasoltak a Ponzi-sémák észlelésére az Ethereumon. 

Ez a mechanizmus adatbányászatot és gépi tanulást használ a Ponzi-szerződések észlelésére. Ez a folyamat akkor is működik, ha az intelligens szerződések forráskódja nem érhető el. 

Kulcs elvihető

Ennyi, igen, egyenlőre ennyi!

Ha eddig velünk volt, megköszönnénk. Anélkül, hogy tovább nyúlnánk, záró megjegyzésként csak annyit mondanánk, hogy az intelligens szerződések ökoszisztémája decentralizált, és nehéz befoltozni a hibákat. 

Megpróbáltuk lebontani az intelligens szerződések biztonságát a szoftver életciklusa szempontjából. 

Először megvitattuk a blokklánc legfontosabb jellemzőit, amelyekért felelősek biztonsági kérdések az intelligens szerződésekben. Az intelligens szerződések biztonsági megoldásait négy fázisba soroltuk. Reméljük, hogy még több bejegyzést hozunk, hogy megelőzzük a növekvő Web3 ökoszisztéma kihívásait. 

Mi a véleménye erről az agilis SDLC-megközelítésről az intelligens szerződésbiztonság érdekében? Ossza meg gondolatait az alábbi megjegyzésekben!

A poszt Intelligens szerződésbiztonság: Agilis SDLC-megközelítés  jelent meg először Blog.quillhash.

• Coinsmart. Európa legjobb Bitcoin- és kriptográfiai tőzsdéje.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. SZABAD HOZZÁFÉRÉS.
• CryptoHawk. Altcoin radar. Ingyenes próbaverzió.
• Forrás: https://blog.quillhash.com/2022/04/22/smart-contract-security-an-agile-sdlc-approach/