Hogyan lehet megoldani a blokklánc infrastruktúra biztonsági problémáját egy dApp létrehozása közben

Megkezdődött a verseny a WEB3-ért. Kockázati tőkések, kriptovaluta startupok, mérnökök és látnokok fejlesztik a WEB3-at (vagy Web 3.0-t), amely a blokklánc alapú. Új határvonal jelent meg, demokratikusabb, decentralizáltabb, függetlenebb és ideális az adatok helyreállításához.

De vajon minden olyan tökéletes a decentralizáció és az infrastruktúrák biztonsága tekintetében? Nem, és az ember a közepén támadások számos esete bizonyítja ezt.

De a biztonsági probléma megoldásához emlékezzünk arra, hogy mi is az a WEB3. A WEB3 alapkoncepciója a központosítás okozta biztonsági problémák megoldása, valamint az adatok és azonosításuk feletti jogkör biztosítása az emberek számára. Tehát a technológia milyen szintjén történnek ezek a sajnálatos biztonsági incidensek a blokklánc-infrastruktúrában? Találjuk ki.

A WEB3 belső aspektusaira összpontosítva az olyan technológiák, mint az EVM, a Solidity és a JavaScript, továbbra is hatalmas szerepet játszanak. A háttérszolgáltatások megvitatásakor azonban csomópont- és WEB3 API-szolgáltatókat használunk.

Csomópont-szolgáltatók olyan cégek, amelyek lehetővé teszik a szolgáltatásaik használatát a csomópontok futtatása helyett. Ez nagyon kényelmes, mert ahelyett, hogy beállítaná a csomópontot, és megtapasztalná az ezzel járó stresszt és költséget, elküldheti dApp tranzakciós kéréseit az interneten keresztül a csomópont-szolgáltatónak. Ha érdekli az intelligens szerződések fejlesztése, használhat egy vagy két csomópont-szolgáltatót (redundancia céljából).

Sok WEB3 API szolgáltatók; azonban, ezek a cégek sok esetben a színfalak mögötti csomópontokkal dolgoznak. Ezekkel az eszközökkel a láncon bármilyen előre összeállított és előre kiszámított adatot megkaphat.

Ezen túlmenően ezeken a WEB3 API-kon keresztül egyszerű megbízható kommunikációt és interakciót létrehozni a különböző alkalmazások között. Ezenkívül a minőségi API-k konzisztens és stabil kódolást biztosítanak. Ezért az alkalmazások létrehozásakor leginkább a megbízható WEB3 API-kra hagyatkozunk.

???? Különbség a csomópont-szolgáltatók és a WEB3 API-szolgáltatók között: A WEB3-szolgáltató lehetővé teszi az alkalmazás számára, hogy kommunikáljon egy blokklánc-csomóponttal azáltal, hogy JSON-RPC-kérelmeket küld el a szervernek. A csomóponti szolgáltatók elosztott csomóponti klienseket futtatnak a színfalak mögött, és lehetővé teszik számukra, hogy API-kulcs segítségével írjanak egy blokkláncra, illetve olvassanak onnan.

Milyen biztonsági fenyegetést jelent a dApps fejlesztői számára?

A csomópontok még mindig viszonylag primitív technológiák, de még mindig értékesek. Például egy WEB3 csomópont nem tudja megmondani, hogy a felhasználók mit helyeztek el a számlájukon. A nyers blokklánc-információk egyszerű megadása mellett a csomópontok nem tudnak több intelligens szerződést feldolgozni. Ezenkívül a csomópontok korlátozott képességekkel rendelkeznek, és csak egy láncot tudnak feldolgozni. Szerencsére rendelkezésre állnak API-k, amelyek segítenek megkerülni ezt a korlátozást.

Az API-k meghatározzák és szabványosítják az alkalmazások interakcióit, lehetővé téve a nyers blokklánc-adatok használatát. Ez az oka annak, hogy a WEB3 API-k hasznosak a dApp fejlesztésében. A WEB3 API-k kulcsfontosságú összetevői a dApps fejlesztésének; amellett, hogy egyszerű kezelőfelületet kínálnak, lehetővé teszik, hogy egy szoftver együttműködjön más alkalmazásokkal. Mivel a megbízható API-k konzisztens kódolást tesznek lehetővé stabil környezetben, a dApp-fejlesztőknek nem kell újra feltalálniuk a kereket.

Ezen túlmenően ezen WEB3 szolgáltató API-k használatával könnyedén linkelhet csomópontokat. Ezért nem kell aggódnia a csomópontokhoz való csatlakozás miatt, amikor ezeket az API-kat használja. Amikor kapcsolatba lép ezekkel a szolgáltatókkal, mindenféle értékes előre kiszámított és előre összeállított láncon belüli adatot is kaphat.

Az ilyen szolgáltatások azonban nem zárják le teljesen a fejlesztői kéréseket a biztonsági tervekben, és a legtöbb esetben előre kell fizetni a használatukért.

A tény az, hogy egyre több olyan eset van, amikor a dApps-t feltörik a fent említett emberközép-támadás segítségével.

Ilyenkor a támadó a DNS-kiszolgálók biztonsági réseit használva (például) kiszolgálót váltott, hogy kiszolgálja a jsonrpc-végpontok forgalmát.

Egy áldozat ismert 16.5 WBTC-t veszítettek (~350,840 23 USD). És körülbelül XNUMX kriptovaluta projekt találkozott már hasonló DNS-támadással.

Egy nagyon egyszerű megoldás lehetővé teszi, hogy megvédje magát az ilyen „ember-in-the-middle” támadásoktól. És erre még visszatérünk.

Továbbá, ha van fejlesztőcsapata, járhatja a saját útját, és megpróbálhatja felépíteni a megoldását, de ehhez hasonló gondolkodású emberekből álló szuperképzett csapatra van szüksége.

Ennek a folyamatnak az a nehézsége, hogy jelentősen túlbecsülheti az erejét. Egy könnyűnek tűnő feladat ekkor sok kérdést vet fel, amelyekre a sok éves munkatapasztalat megválaszol. Ezért ha sok időd és erőforrásod van, akkor el kell fogadnod ezt az utat.

3 fő blokklánc-elv megsértése a WEB-ben3

Tehát most vegyünk egy lélegzetet, és nézzük meg a WEB3 világának jelenlegi biztonsági kihívásait infrastruktúra szemszögéből.

A blokklánc fő alapelvei a következők

• decentralizálás
• átláthatóság
• bizalmatlanság

De működik a gyakorlatban? Vessen egy pillantást a legnépszerűbb dApp architektúra.

Láthatjuk, hogy a felhasználói felületen lévő felhasználók kéréseket küldenek a JSON-RPC szolgáltatóknak (ez lehet az Infura, Alchemy, Quicknode stb.).

Így a kérések egy megosztott környezetbe kerülnek, ahol nincs befolyásunk az adatátalakításra az API-átjáróban, a gyorsítótárban, a blokklánc csomópontokban vagy bármi másban.

És itt merül fel az első probléma, mert a A megosztott környezet azt jelenti, hogy sok felhasználó, bot és hacker dolgozik ugyanabban a környezetben. Ez egy igazi fekete doboz a fejlesztő számára, amely túl sok figyelmet vonz a támadókból.

Nos, ez a megközelítés ellentmond a WEB3 mindhárom alapelvének, mert:

1. Központosítja a hozzáférést a Blockchainhez, mindent megosztott környezetben továbbítva;
2. Nem átlátható – nem tudjuk ellenőrizni az ilyen API-ból érkező válaszokat;
3. Ezért nem nevezhető valódi bizalmatlanságnak, mivel egy ilyen infrastruktúra biztonsági kérdései egyszerűen a bizalomra épülnek. Győződjön meg saját szemével a következő ábrán.

A második probléma a leírt infrastruktúra verzió lehetővé teszi az ember a középső támadásokat, amelyet a bűnözők rendszeresen használnak.

A következő szolgáltatásokat lehet megtámadni:

• • Domain vagy DNS regisztrátorok
  • JSON-RPC szolgáltatók
  • Bármely harmadik fél összesített szolgáltatása

A blokklánc-csomópontok önkiszolgáló klasztere az egyetlen megoldás

De van megoldás? Igen – konfigurált helyszíni környezet.

Először is, blokklánc-csomópontok önkiszolgáló klaszterét használja. Az összes csomópontot a hivatalos genezisből inicializálják, és a p2p használatával szinkronizálják. Ez biztosítja az adatok konzisztenciáját.

A csomópontokat rendszeresen frissíteni kell csökkentett pillanatképekkel a lehető leghatékonyabb működés érdekében. Az ideális megoldás az, ha nagyításkor automatikusan új csomópontokat hoz létre a kicsinyített pillanatfelvételből. Ha a csomópontot a semmiből inicializálja, ez a megközelítés lehetővé teszi, hogy több napon belül 30 percen belül új csomópontot kapjon.

Egy másik kritikus pont a blokklánc szoftver automatikus frissítése a megjelenés után – ez is megtehető. A lényeg az, hogy az új verzióval készítsünk pillanatképet (mivel ez néha bizonyos adatműveleteket igényelhet, ami időbe telhet), majd az új csomópontoknak automatikusan el kell indulniuk az új pillanatfelvétellel és a frissített szoftverrel.

Az alábbiakban látható egy infrastruktúra diagram, amely a legtöbb leírt problémát megoldja.

Szintén fontos figyelni a szinkronizálási állapotot, és kizárni azokat a csomópontokat, amelyek az upstream áramlás mögött vannak. Ez megtehető például egészségügyi ellenőrzések segítségével.

Amellett, hogy IP-címmel korlátozható a hozzáférés, érdemes megemlíteni, hogy a jó öreg JWT token védhet a domain regisztrátor vagy DNS támadások ellen. A JWT token könnyen integrálható a web3js-ba és más könyvtárakba, és a blokklánc-fürtünk API-átjáró oldalán kell megvalósítani.

Ily módon biztonságossá és decentralizálttá tesszük a blokklánc végpontját.

Összegezve

A Web3 még a kezdeti szakaszban van. De a verseny a decentralizációért már folyik. És látni fogja, hogy a legbiztonságosabb alkalmazások valószínűleg azok, amelyek a leginnovatívabb és nyílt forráskódú megközelítéseket használják.

Ezért nem szabad figyelmen kívül hagynia a WEB3 alapelveit, mert akkor az újonnan létrehozott dApp nem nyújt biztonságot a többi résztvevő számára. Az egyetlen jelenleg elérhető lehetőség a földrajzilag elosztott blokklánc csomópontok autonóm klasztere.

Szerző:

Daniel Yavorovycho

Társalapító és technológiai igazgató RPCFast és a Dysnix