Nem ritkán tízmillió dolláros veszteségeket okoznak az okosszerződések (egy látványos esetről például itt írtunk). De nem csak a hekkertámadások jelentenek problémát, hanem az is, ha például hibásan kódolják egy szerződés pénzügyi feltételeit. Az okosszerződések fejlesztői közömbösek a kód biztonságával szemben, és gyakran nem is rendelkeznek megfelelő technikai erőforrásokkal, hogy ne silány minőségű kód kerüljön ki a kezük közül.
A kód nem okos, hangsúlyozza az a kutatás, melyet az Illinois Egyetemen készítettek (letölthető az arXiv-ról pdf-ben). Az okosság ugyanis a szoftverfejlesztőnél kezdődik. Egy átlagos szoftver kódjában 100 sorra kb. egy hiba jut. Mitől lenne jobb az arány egy okosszerződés kódjában?
Bár a szerződési forma egyelőre közel sem általános, 2021-ben 680 millió dollár értékű, okosszerződések által ellenőrzött digitális eszköz veszett el biztonsági rések miatt. A tanulmány szerzői ezért okosszerződés-fejlesztőkkel (szám szerint 29-cel a világ minden tájáról az USA-tól Ghánán át Új-Zélandig) készítettek interjúkat, hátha azokból fény derül az okosszerződések biztonsági hiányosságainak okaira.
A válaszokból kiderült: a fejlesztők több mint négyötödénél a biztonság nem prioritás. A leggyakrabban három magyarázat hangzott el. Gyorsan kell szállítani, és akkor az a lényeg, hogy működjön, és nem az, hogy biztonságos is legyen. A fejlesztők nem a nulláról építkeztek, hanem olyan népszerű projekteket forkoltak, amelyeket a fejlesztői közösség (elvileg) már ellenőrzött. És végül előkerült magyarázatként az is, hogy a biztonsági auditot valaki más végzi, ezért az ilyen kérdésekkel nem is foglalkoznak.
A fejlesztők többsége emiatt főleg a funkcionális korrektségre törekszik (ezt állította kétharmaduk), de felük az erőforrás-optimalizálást is prioritásként kezeli.
Hiányzik a megfelelő technikai háttér
Az interjúkból kiderült, hogy a fejlesztők közel harmada egyszerűen kézi módszerekkel próbálja keresni a biztonsági problémákat, míg másik harmaduk használ erre okosszerződésekhez készített speciális eszközöket. Igaz, azt is megjegyezték többen, hogy azokat nehéz használni. Az egyébként hamar kiderült, hogy a kézi vizsgálat mennyire lutri. Amikor a fejlesztőknek az interjú során egy mintakódban biztonsági hibát kellet azonosítaniuk, 16-an csak egy hibát találtak meg a kettőből, és csak 6-nak sikerült helyesen javítani. (Öten egyik hibát sem találták meg.)
Ha belépnek a képbe az auditorok, akik ellenőrzik a kódot biztonsági szempontból, a fejlesztők a jelzett hiányosságokat általában kézzel, támogató eszközök nélkül javítják – sokszor rosszul.
A fejlesztők közül többen megjegyezték, hogy az okosszerződéseknél leggyakrabban használt nyelv, a Solidity csak korlátozottan segíti a biztonságos kód létehozását. (A programozási nyelv pár éve még kitalálóját, Gavin Woodot is alaposan megtréfálta.) Mint a The Register megjegyzi a kutatásról készített összefoglalójában, már évek óta ismert, hogy emiatt az Ethereum blokkláncon futó okosszerződések sérülékenyek.
A NIS2-megfelelőség néhány technológiai aspektusa
A legtöbb vállalatnál a megfeleléshez fejleszteni kell a védelmi rendszerek kulcselemeit is.
CIO KUTATÁS
TECHNOLÓGIÁK ÉS/VAGY KOMPETENCIÁK?
Az Ön véleményére is számítunk a Corvinus Egyetem Adatelemzés és Informatika Intézetével közös kutatásunkban »
Kérjük, segítse munkánkat egy 10-15 perces kérdőív megválaszolásával!
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak