150 millió dollár zárva van az Ethereum hálózaton - Hogyan lehet megvédeni magad

A komplexitás a biztonság ellensége

A Parity egy Rustban írt Ethereum-megvalósítás, melyet Ethereum nagyon tehetséges társa, Gavin Wood vezet. A megvalósítás könnyen használható grafikus felhasználói felületet biztosít a multi-sig pénztárcák létrehozásához. A többszörös szerződést, amely ezt a funkciót alátámasztja, 2017. július 19-én sebezhetővé tették, amely 30 millió dolláros veszteséget okozott. 2017. november 7-én egy második sebezhetőséget találtak a pénztárca-szerződésben, amelynek eredményeként 150 millió dollárt zároltak éterben. Noha az Ethereum nem kínál egyszerű megoldást a magas biztonságú pénztárcák számára, néhány lépést megtehet annak megakadályozására, hogy ilyen támadás áldozatává váljon.

A „támadó” által benyújtott hibajelentés

Hagyományos szoftver-környezetben képesek vagyunk a kódot egy nyilvános felületre, például egy webhelyre telepíteni. Ha úgy tűnik, hogy a kód nem felel meg annak a funkciónak, amelyet remélünk, akkor mi történik? Talán senki nem veszi észre, talán néhány ember panaszkodik, a nap végén frissíthetjük a kódot, és a kisebb kellemetlenségek megoldódnak. Az Ethereum világában, ha egyszer telepítünk egy kódot, örökre ott van, hogy mindenki láthassa és játszhasson. Ideális világban csak Önnek van hozzáférése ehhez a kódhoz, a blockchain világában mindenkinek van hozzáférése hozzá. Ez azt jelenti, hogy ha egy darab kódot telepítenek az Ethereum hálózatra, akkor a legtöbb esetben nem lehet frissíteni.

Beszélgetés a „támadóval”

Ha egy millió dollárt étert teszünk intelligens szerződésbe, és az intelligens szerződésnek sebezhetőséget talál, akkor néhány dolog fordulhat elő. Előfordulhat, hogy észrevétlenül veszi észre egy hackert, aki úgy dönt, hogy kihasználja, vagy a szerződés tulajdonosa fedezi fel, és képesek lesznek visszafizetni a pénzeszközöket. Ebben az esetben azt egy egyén kihasználta, aki azt állította, hogy „kutatja” az előző paritás hack-et.

A „támadó”

Szóval hogyan tudjuk megvédeni magunkat?

KISS alapelv - Tartsa egyszerűen hülyebbé

A legtöbb intelligens szerződés a sebezhetőségeket azáltal, hogy megpróbálja figyelembe venni a sarkok eseteit és az optimalizálást. Az első Paritás-sérülékenység a végrehajtás során felhasznált gáz mennyiségének optimalizálására tett kísérlet eredménye. A jelenlegi Paritás-sebezhetőséget az új, nem tesztelt könyvtári funkciók beépítése okozta. Egy kezelhető intelligens szerződés tartalmazza a feladat elvégzéséhez szükséges minimális funkcionalitást. A korai megoldás optimalizálására szolgáló kód bevezetése növeli a szerződés bonyolultságát, csökkentve ezzel a biztonságot.

Egység tesztek

A közös szoftverfejlesztés és az intelligens szerződésfejlesztés során kényelmes lehet figyelmen kívül hagyni a megfelelő egységteszteket. Ha a kód nem vonható vissza, miután elérte a termelést, akkor magasabb szintű gondosságra van szükség. A hüvelykujj szabálya, hogy az intelligens szerződésnek megfelelő egységteszteket kell tartalmaznia az intelligens szerződés funkcionalitásának és a saroktestek ellenőrzéséhez.

Intelligens szerződéses ellenőrzések

Minden, a gyártáshoz elküldött intelligens szerződést biztonsági ellenőrzésnek kell alávetni. Egy jó intelligens szerződésbiztonsági auditornak tapasztalata van valós intelligens szerződések felépítésében, rengeteg projektben a GitHubon, és meg fogja osztani a keresett általános biztonsági rések ellenőrző listáját. Győződjön meg arról, hogy a könyvvizsgáló megbeszélést folytathat az intelligens szerződéssel kapcsolatos különböző támadási vektorokról. Lehet, hogy ez nem tűnik formális megközelítésnek, azonban az ipar még mindig nagyon fiatal és így működik ebben a pillanatban.

Ezen iránymutatások betartása csökkentheti az intelligens szerződéseknek az Ethereum Mainnet felé történő küldésével járó kockázatot és szorongást.

Tesztelés, ellenőrzés, telepítés.