BNB Chain je jedním z nejpopulárnějších blockchainů ve světě Web3 jeho rozumné poplatky, rychlé transakce a bohatý projektový ekosystém přitahují velké množství uživatelů. Stejně jako u každého blockchainu by vývojáři na BNB Chain měli nejprve zvážit bezpečnostní problémy během procesu vývoje: protože jakákoli ztráta finančních prostředků povede k oslabení důvěry uživatelů v protokol a platformu a zranitelnosti zabezpečení a útoky hackerů jsou jedním z největších rizik. tvář vývojářů.
V tomto článku poskytujeme deset praktických bezpečnostních tipů, aby vývojáři mohli snížit rizika a vyvinout bezpečnější chytré smlouvy na BNB Chain.
01
╱Definice ╱
Replay Attacks, také známé jako replay útoky a replay útoky, jsou běžným typem útoku v prostředí blockchainu. V kybernetické bezpečnosti je „útok opakovaného přehrávání“ typ síťového útoku, při kterém se platný přenos dat zlomyslně nebo podvodně opakuje nebo zdržuje.
V kontextu Web3 a smart kontraktů to obecně znamená, že útočník je schopen zopakovat transakci nebo akci v chytrém kontraktu bez svolení původního uživatele. To může vést k různým formám podvodů, jako jsou dvojí výdaje atd.
Tyto útoky mohou mít vážné důsledky pro uživatele a vývojáře, protože umožňují útočníkům znovu použít stejný podpis k získání neoprávněného přístupu ke všem prostředkům nebo jiným aktivům na smart kontraktu.
Aby vývojáři zabránili opakovaným útokům, musí pečlivě navrhnout a implementovat svůj kód inteligentní smlouvy a dodržovat ověřování podpisů i nejlepší bezpečnostní standardy v oboru.
02
╱ Analýza případů ╱
Následující fragment kódu představuje proces implementace přenosu tokenu v řetězci BNB. Kód je zranitelný vůči opakovaným útokům, což umožňuje útočníkovi znovu použít stejný podpis.
Tato funkce postrádá ochranu nonce nebo replay, což umožňuje útočníkovi „přehrát“ podepsaný přenos vícekrát. Útočník může zachytit podepsanou transakci a odeslat ji znovu na stejnou smlouvu nebo jinou smlouvu a smlouva ji bude stále považovat za platnou, takže útočník může tuto chybu zabezpečení zneužít ke krádeži majetku.
03
╱ Metody zlepšování ╱
Přidejte k podpisu nonce nebo použijte mapovací proměnné k zaznamenání podpisu. Konkrétnější řešení se budou lišit v závislosti na návrhu projektu.
01
╱Definice ╱
K reentrancy útoku dochází, když škodlivá smlouva opakovaně volá zranitelnou smlouvu před dokončením počátečního hovoru. Jinými slovy, útočník může „oklamat“ zranitelnou smlouvu tak, že si myslí, že dokončil jednu transakci a může volně přejít k další, ale ve skutečnosti stále spouští útočníkův škodlivý kód.
To by mohlo vést k tomu, že by útočník mohl neočekávaným způsobem manipulovat se stavem smlouvy a případně získat neoprávněné finanční prostředky.
02
╱ Analýza případů ╱
V níže uvedeném úryvku kódu mohou uživatelé vybírat prostředky ze svého účtu zavoláním funkce výběru a zadáním částky, kterou chtějí vybrat. Protože však funkce stažení nechrání před rekurzivními voláními funkce, je zranitelná vůči útokům typu reentrancy.
Útočník by mohl tuto chybu zabezpečení zneužít vytvořením škodlivé smlouvy, která několikrát volá funkci stažení, než bude zůstatek skutečně odepsán z jeho účtu. Funkce msg.sender.call posílá prostředky na škodlivou smlouvu a útočník používá funkci přijmout() škodlivé smlouvy k opakovanému výběru prostředků, než se její zůstatek sníží na nulu, čímž vyčerpá všechny prostředky smlouvy oběti.
03
╱ Metody zlepšování ╱
Aktualizujte stav před jakýmkoli externím hovorem.
Tento vzor se nazývá vzor „Check-Effects-Interact“ a jde o návrhový vzor používaný k zabránění reentrancy útokům v inteligentních kontraktech. Tento vzor odděluje změny stavu od externích volání na jiné smlouvy tím, že nejprve zkontroluje předběžné podmínky a poté aktualizuje stav před provedením jakýchkoli externích volání. Tímto způsobem, pokud externí volání spustí zpětné volání, které se pokusí zavolat zpět ke smlouvě, ale stav již byl aktualizován, je zabráněno dalším neočekávaným efektům.
Dodržováním tohoto vzoru mohou vývojáři zajistit, že jejich smlouvy jsou bezpečnější a méně náchylné k reentrancy útokům.
Další možnou opravou je použití modifikátoru k omezení více volání na stejnou funkci, podobně jako OpenZeppelin's ReentrancyGuard.
01
╱Definice ╱
Oracle mohou pomoci chytrým kontraktům získat informace mimo blockchain. Obvykle je cena aktiva decentralizované burzy (DEX) určena cenou extrahovanou věštcem z poslední úspěšné transakce na DEX.
Problém je však v tom, že s cenou může kdokoli snadno manipulovat a způsobit tak problémy s chytrým kontraktem. Často se setkáváme s případy manipulace cenových věštců prostřednictvím bleskových půjček Důvodem je, že bleskové půjčky umožňují uživatelům půjčovat si obrovské množství peněz bez zajištění, pokud půjčku splácejí ve stejném bloku. Díky tomu mohou útočníci snadno ovlivňovat nebo dokonce manipulovat s cenami, profitovat z falešných likvidací, nadměrného půjčování nebo nekalého obchodování.
02
╱ Analýza případů ╱
Níže je uveden fragment kódu, který je zranitelný vůči útokům věštecké manipulace.
Tato smlouva umožňuje uživatelům vyměnit token A za token B pomocí směrovací smlouvy, ale spoléhá na externí orákulum (smlouva Uniswap Pair), aby získal rezervy tokenu A a tokenu B pro výpočet ceny. Útočníkovi se podařilo manipulovat s rezervami smlouvy Uniswap Pair a také s funkcí getAmountOut, což nakonec způsobilo, že swap byl proveden za nepřiměřenou cenu.
03
╱ Metody zlepšování ╱
Aby se tomuto útoku zabránilo, měli by vývojáři použít decentralizovanou síť Oracle, která dokáže získat objemově váženou průměrnou cenu (VWAP) nebo časově váženou průměrnou cenu (TWAP) centralizovaných a decentralizovaných burz v řetězci. Tímto způsobem budou data shromažďována z více zdrojů a v širokém časovém rozmezí, takže kód bude méně náchylný k útokům a manipulaci. Pro vývojáře je důležité, aby byli schopni z chytrých kontraktů odstranit všechny útočné vektory manipulující s orákulem, aby se předešlo potenciálním zranitelnostem.
01
╱Definice ╱
Správné nastavení viditelnosti funkcí zajišťuje bezpečnost a integritu smart kontraktů. Použití nesprávného nastavení viditelnosti funkcí může umožnit nezamýšleným uživatelům manipulovat se stavem smlouvy, což vede k vážným problémům, jako jsou odcizení finančních prostředků nebo kontrola funkčnosti smlouvy.
Nastavením viditelnosti funkce na soukromou nebo interní zajistíte, že vývojáři budou mít omezený přístup k určitým funkcím a že tyto funkce budou moci volat pouze oprávněné osoby. Soukromé funkce lze volat pouze ze smlouvy samotné, zatímco interní funkce lze volat také z aktuální smlouvy. To umožňuje vývojářům vytvářet výkonnější a komplexnější smlouvy při zachování kontroly nad přístupem k funkcím.
02
╱Analýza případu╱
Funkce setAdmin() umožňuje komukoli nastavit libovolnou adresu jako správce smlouvy. V závislosti na oprávněních ke správě adres udělených v rámci smlouvy to může způsobit, že vývojář ztratí kontrolu nad samotnou smlouvou a dokonce může způsobit ztrátu finančních prostředků.
Nastavením viditelnosti funkce na hodnotu internal mohou některé funkce smlouvy interně umožnit nastavení určitých uživatelů jako správců.
03
╱ Metody zlepšování ╱
Modifikátory přístupu jsou důležitou bezpečnostní funkcí, která určuje, kdo může přistupovat ke konkrétním funkcím nebo proměnným ve smlouvě. Tyto modifikátory lze použít k omezení viditelnosti určitých funkcí nebo proměnných na konkrétní role nebo adresy a zabránit zlomyslným aktérům v získání neoprávněného přístupu nebo manipulaci se stavem smlouvy.
Smlouva může mít například funkci, kterou může volat pouze vlastník smlouvy, nebo proměnnou, ke které lze přistupovat pouze z konkrétní sady adres.
Přístup k funkci setAdmin lze omezit na adresu vlastníka smlouvy změnou modifikátoru viditelnosti na externí a nastavením modifikátoru přístupu na onlyOwner. To zabrání škodlivým externím stranám převzít kontrolu nad určitými privilegovanými funkcemi.
Správné použití viditelnosti a omezujících modifikátorů může usnadnit správu smluv a omezit běžné útoky, jako je reentrancy (útočník opakovaně volá funkci, aby manipuloval se stavem smlouvy) nebo front-running útoky (útočník sleduje čekající transakce a manipuluje se stavem smlouvy před právními předpisy). transakce jsou prováděny).
Vhodným používáním těchto funkcí mohou vývojáři zvýšit bezpečnost a spolehlivost svých smluv, snížit riziko neoprávněného přístupu a zlepšit celkovou kvalitu a udržovatelnost svého kódu.
01
╱Definice ╱
Při rozhodování, zda v budoucnu upgradovat smlouvu, je důležité nejprve pečlivě zvážit návrh smlouvy. Upgradovatelnost smlouvy se týká vlastnosti, že logiku chytré smlouvy lze upravit nebo aktualizovat po jejím nasazení na blockchain. Ačkoli upgradovatelnost může poskytnout mnoho výhod (jako je oprava chyb, zlepšení efektivity nebo přidání nových funkcí), přináší také určitá rizika. Upgrady smluv mohou přinést nové zranitelnosti, zvýšit složitost smlouvy nebo způsobit nezamýšlené následky.
Upgradovatelnost smluv také vyvolává problémy s důvěrou, protože správci agentů mohou upgradovat smlouvy bez shody komunity. Vývojáři musí pečlivě zvážit výhody a nevýhody upgradovatelnosti a určit, zda je zavedení upgradovatelných smluv pro jejich projekt skutečně nutné. V některých případech je bezpečnější navrhnout smlouvu, která je neměnná od začátku, než se spoléhat na možnost později ji upravit.
02
╱ Metody zlepšování ╱
Pokud jde o upgradovatelnost smlouvy, je třeba dodržovat několik důležitých postupů. V první řadě neupravujte knihovnu proxy. Knihovna Proxy kontraktů je extrémně složitá, zejména pokud jde o správu úložiště a mechanismy upgradu. I malé chyby mohou výrazně ovlivnit fungování proxy a logických kontraktů. Ve skutečnosti bylo mnoho kritických chyb souvisejících s proxy zjištěných během auditu způsobeno nevhodnými úpravami knihovny proxy.
Dalším klíčovým aspektem upgradovatelnosti smlouvy je zahrnutí „mezery“ úložiště do základní smlouvy. Logické smlouvy musí obsahovat mezeru v úložišti v kódu smlouvy, aby bylo možné zohlednit nové proměnné, které mohou být zavedeny při nasazování nových logických implementací. Po přidání nových stavových proměnných se aktualizace velikosti „mezery“ stává ještě důležitější. Tato praxe zajišťuje, že budoucí upgrady budou probíhat hladce a bez problémů.
Nakonec se musíte vyvarovat použití selfdestruct() nebo provádění delegáta volání()/call() u nedůvěryhodných kontraktů. Útočník může tyto funkce zneužít k podvrácení implementace logiky nebo spuštění vlastní logiky. Abyste tomu zabránili, je důležité ověřit vstup uživatele! Nedovolte, aby smlouvy prováděly delegát()/call() u nedůvěryhodných smluv. Navíc se nedoporučuje používat v logických kontraktech delegát call(), protože správa rozložení úložiště napříč více kontrakty může být obtížné. Dodržováním těchto postupů mohou vývojáři minimalizovat zranitelnosti a rizika při upgradech smluv.
01
╱Definice ╱
Front-running byl vždy tvrdohlavý a obtížně řešitelný problém, kdy uživatelé mohou profitovat ze zpoždění mezi odesláním transakce a jejím potvrzením na blockchainu. Toto zpoždění je způsobeno mempoolem.
mempool je dočasná úložná oblast používaná k ukládání nepotvrzených transakcí, které byly vysílány do sítě. Všechny uzly v síti udržují mempool, který umožňuje komukoli vidět čekající transakce a potenciálně je zachytit a profitovat z nich. Mempool také poskytuje těžařům příležitost přeskupit transakce tak, aby maximalizovali své zisky, a vytvořit to, co je známé jako těžařská (nebo maximální) vytěžitelná hodnota (MEV).
02
╱ Analýza případů ╱
Níže je uveden příklad funkce aukčního nabízení, která je náchylná k předstihu.
Tato funkce umožňuje uživatelům přihazovat v aukcích, ale může být vystavena útokům zepředu. Předpokládejme, že uživatel se zlými úmysly sleduje blockchain a vidí, že jiný uživatel podal vysokou nabídku. Uživatel se zlými úmysly může rychle odeslat vyšší nabídku a získat prioritu, čímž nakonec vyhraje aukci.
V následující verzi uživatelé zadávají neznámé nabídkové ceny a tyto nabídky jsou uloženy v mapování . Částky nabídek jsou šifrovány až do konce nabídkového období.
03
╱ Metody zlepšování ╱
Na konci nabídkového období mohou uživatelé odhalit svou nabídku zadáním původní částky nabídky a tajné hodnoty. Smlouva ověřuje, že se výše nabídky a tajný hash shodují s uloženou tajnou nabídkou, čímž je zajištěno, že nabídka byla podána před koncem aukčního období. Pokud je tato nabídka vyšší než aktuální maximální nabídka, stane se novou maximální nabídkou. Tato funkce zmírňuje útoky zepředu tím, že maskuje částky nabídek až do konce aukčního období.
Front-running a MEV se staly hlavními problémy v blockchainové komunitě a pro řešení těchto problémů byla navržena různá řešení, jako jsou transakce a služby Fair Ordering Services (FSS). Transakce mohou pomoci zabránit front-runningu tím, že skryjí podrobnosti o transakci před ostatními uživateli, dokud nebude transakce provedena na blockchainu. Na druhou stranu může FSS snížit dopad front-runningu a MEV prostřednictvím bezpečného objednávání transakcí mimo řetězec.
Mít jasný a komplexní plán reakce je zásadní pro řešení mimořádných bezpečnostních incidentů. Plán by měl být pravidelně kontrolován, aktualizován a testován na účinnost. Když nastane bezpečnostní nouzová situace, čas je rozhodující. Plán by proto měl být předem přizpůsoben a zahrnovat podrobné provozní kroky pro identifikaci, kontrolu a zmírnění.
Plán by měl být účinně zaveden, aby byly všechny zúčastněné strany informovány. Zároveň je důležité i pravidelné zálohování dat, aby nedocházelo ke ztrátě dat. Plán musí nastínit proces obnovy pro obnovení dat a systémů do předchozího stavu. Členové týmu by měli absolvovat systematické školení o plánu, aby bylo zajištěno, že každý rozumí svým rolím a povinnostem.
Dobře připravený plán reakce nemusí být schopen problém vyřešit, ale může minimalizovat dopad incidentu a udržet důvěru uživatelů a zainteresovaných stran.
Pravidelné audity kódu jsou zásadní pro zachování bezpečnosti vaší aplikace. Spolupráce s profesionálním auditorem, který se specializuje na zabezpečení chytrých smluv, je důležitým krokem v procesu vývoje. Auditoři prozkoumají zranitelnost kódu a poskytnou doporučení pro zlepšení celkové bezpečnosti.
Stanovení priorit a řešení identifikovaných problémů a udržování otevřené komunikace s auditory jsou zásadní pro zlepšení bezpečnosti.
Kromě toho je důležitá také komunikace s auditory. Auditoři mohou podrobně vysvětlit problémy a zranitelná místa, která objevili, a poskytnout pokyny a praktickou pomoc, jak zranitelnost vyřešit. Díky spolupráci s profesionálními auditorskými agenturami/personálem se bezpečnost „posune na další úroveň“.
Pro vývojáře řetězců BNB je provádění pravidelných auditů nedílnou součástí jakékoli komplexní bezpečnostní strategie. Proaktivní identifikace a řešení slabých míst ve vašem kódu může minimalizovat riziko narušení bezpečnosti.
Použití bounty programu je účinný způsob, jak podnítit white hat hackery v komunitě, aby hlásili bezpečnostní zranitelnosti v kódu projektu. Poskytováním pobídek, jako jsou tokeny nebo jiné odměny, může jakýkoli projekt povzbudit zkušené lidi, aby si kód přečetli a nahlásili jakékoli potenciální problémy, které najdou.
Je důležité mít jasný a transparentní bug bounty program. Plán musí obsahovat: jaké typy objevených zranitelností mají nárok na odměny, jak hodnotit hodnotu těchto zranitelností atd. Zahrnutí renomované třetí strany do bug bounty programu zároveň může pomoci zajistit hladký chod programu a spravedlivé rozdělení odměn.
Zároveň je důležité mít různorodou „skupinu lovců odměn“. Různí white hat hackeři mají různé oblasti odborných znalostí a mohou se zaměřit na hledání problémů, které by ostatním mohly uniknout.
A konečně, jakmile jsou zranitelnosti nahlášeny, je třeba rychle a účinně přijmout opatření k jejich vyřešení. Bounty programy mohou být účinným nástrojem pro identifikaci zranitelností, ale smysl mají pouze v případě, že vývojový tým problém skutečně opraví.
Vzdělávání uživatelů Web3 o bezpečnosti je klíčovým krokem při budování bezpečného ekosystému. Zajištění bezpečnosti zákazníků pomůže zajistit bezpečnost platformy. Uživatelé by měli být poučeni o osvědčených postupech ochrany svých účtů a citlivých informací.
Nejdůležitější částí je naučit se, jak se vyhnout phishingovým podvodům.
Phishingoví podvodníci přimějí uživatele k odhalení jejich soukromých klíčů nebo hesel tím, že předstírají legitimní web nebo službu. CertiK doporučuje, aby uživatelé vždy dvakrát zkontrolovali jakýkoli e-mail, zdroj atd. URL webových stránek, které používají při přijímání jakýchkoli informací, a nikdy nezadávali soukromé klíče nebo hesla na nedůvěryhodné webové stránky.
A další důležitou součástí je mít bezpečná a silná hesla. CertiK tímto doporučuje, aby uživatelé používali jedinečná a složitá hesla pro každý účet a vyhýbali se opakovanému používání hesel v různých službách. Hesla by také měla být bezpečně uložena pomocí správce hesel nebo jiného mechanismu bezpečného úložiště.
A konečně, ochrana soukromých klíčů je nesmírně důležitá. Soukromý klíč je ekvivalentní heslu uživatele a mělo by být zaručeno, že k němu nikdo nikdy nebude mít přístup. Uživatelé by se měli vyvarovat sdílení svých soukromých klíčů s kýmkoli a uchovávat je na bezpečném místě.
Shrnout
Vývojáři vytvářející chytré smlouvy a dApps na BNB Chain musí zaujmout komplexní bezpečnostní přístup, aby udrželi prostředky a majetek svých uživatelů v bezpečí. Důležitější je být při řešení narušení bezpečnosti proaktivní spíše než reaktivní mít připravený plán, když k narušení dojde nebo dokonce ještě předtím, a poskytnout všem relevantním uživatelům a zúčastněným stranám odpovídající bezpečnostní vzdělání. Kombinací všech výše uvedených opatření lze projektům pomoci výrazně snížit riziko narušení bezpečnosti a útoků hackerů.