Den hÀr artikeln kommer frÄn vÄrt community. Författaren Àr Minzhi He, en revisor pÄ CerTiK.
à sikterna i den hÀr artikeln tillhör författaren och Äterspeglar inte nödvÀndigtvis Binance Academys Äsikter.
TL;DR
Blockkedjebroar Àr kritiska för att uppnÄ interoperabilitet i blockkedjevÀrlden. DÀrför Àr brosÀkerheten för blockkedjor vÀldigt viktigt. NÄgra vanliga sÀkerhetsproblem med broar Àr bland annat svag validering pÄ kedjan och utanför kedjan, felaktig hantering av inbyggda token och felkonfigurationer. Testa bron mot alla möjliga attackvektorer rekommenderas för att sÀkerstÀlla god verifieringslogik.
IntroduktionÂ
En blockkedjebro Ă€r ett protokoll som förbinder tvĂ„ blockkedjor för att möjliggöra interaktioner mellan dem. Om du Ă€ger bitcoin men vill delta i DeFi-aktivitet pĂ„ Ethereum-nĂ€tverket gör en blockkedjebro att du kan göra detta utan att du behöver sĂ€lja dina bitcoin.Â
Blockkedjebroar Àr grundlÀggande för att uppnÄ interoperabilitet i blockkedjevÀrlden. De fungerar med hjÀlp av olika valideringar pÄ och utanför kedjan och har dÀrför olika sÀkerhetsproblem.
Varför Ă€r brosĂ€kerhet kritiskt?Â
En bro innehĂ„ller vanligtvis den token som en anvĂ€ndare vill överföra frĂ„n en kedja till en annan. Broar distribueras ofta som smarta kontrakt och har en betydande mĂ€ngd token nĂ€r överföringarna för tvĂ€rkedjor ackumuleras, vilket gör dem till lukrativa mĂ„l för hackare.Â
Dessutom har blockkedje-broar en stor attackyta eftersom de involverar mĂ„nga komponenter. Med det i Ă„tanke Ă€r skadliga aktörer mycket motiverade att rikta in sig pĂ„ tvĂ€rkedjeapplikationer för att tömma stora summor tillgĂ„ngar.Â
Under 2022 ledde bro-attacker till förluster pĂ„ över 1,3 miljarder USD, vilket svarar för 36 % av Ă„rets totala förluster enligt CerTiks uppskattningar.Â
Vanliga sÀkerhetsproblem med broar
För att förbĂ€ttra broarnas sĂ€kerhet Ă€r det vĂ€rdefullt att förstĂ„ vanliga sĂ€kerhetsproblem för broar och testa broarna före lanseringen. Dessa sĂ„rbarheter kan kategoriseras i följande fyra omrĂ„den.Â
Svag validering pÄ kedjan
För enkla broar, sÀrskilt de som Àr utformade för specifika DApps hÄlls validering pÄ kedjan till ett minimum. Dessa broar förlitar sig pÄ en centraliserad backend för att utföra grundlÀggande operationer som myntning, brÀnning och tokenöverföringar medan alla verifieringar utförs utanför kedjan.
I kontrast anvĂ€nder andra typer av broar smarta kontrakt för att validera meddelanden och utföra verifieringar i kedjan. I detta scenario, nĂ€r en anvĂ€ndare sĂ€tter in pengar i en kedja, genererar det smarta kontraktet ett signerat meddelande och returnerar signaturen i transaktionen. Denna signatur fungerar som bevis pĂ„ insĂ€ttningen och anvĂ€nds för att verifiera anvĂ€ndarens uttagsbegĂ€ran i den andra kedjan. Denna process bör kunna förhindra olika sĂ€kerhetsattacker, inklusive replayattacker och förfalskade insĂ€ttningsregister.Â
Men om det finns en sÄrbarhet under valideringsprocessen pÄ kedjan kan angriparen orsaka allvarliga skador. Om en bro till exempel anvÀnder Merkle-trÀd för att validera transaktionsposten kan en angripare generera förfalskade bevis. Detta innebÀr att de kan kringgÄ bevisvalidering och mynta nya token till sitt konto om valideringsprocessen Àr sÄrbar.
Vissa broar implementerar begreppet âinslagna tokenâ. Till exempel, nĂ€r en anvĂ€ndare överför DAI frĂ„n Ethereum till BNB Chain, tas deras DAI frĂ„n Ethereum-kontraktet och motsvarande mĂ€ngd förpackad DAI utfĂ€rdas i BNB-kedjan.Â
Om den hĂ€r transaktionen inte valideras korrekt kan en angripare distribuera ett skadligt kontrakt för att dirigera inslagna token frĂ„n bron till en felaktig adress genom att manipulera funktionen.Â
Angriparna behöver ocksĂ„ offer för att godkĂ€nna broavtalet för att överföra token med funktionen âtransferFromâ för att tömma tillgĂ„ngar frĂ„n brokontraktet.Â
TyvÀrr förvÀrras detta eftersom mÄnga broar begÀr oÀndligt tokengodkÀnnande frÄn dApp-anvÀndare. Detta Àr en vanlig praxis som sÀnker gasavgifter, men skapar ytterligare risker genom att lÄta ett smart kontrakt fÄ tillgÄng till ett obegrÀnsat antal token frÄn anvÀndarens plÄnbok. Angripare kan utnyttja bristen pÄ validering och överdrivet godkÀnnande för att överföra token frÄn andra anvÀndare till sig sjÀlva.
Svag validering utanför kedjan
I vissa brosystem spelar backend-servern utanför kedjan en avgörande roll för att verifiera legitimiteten för meddelanden som skickas frĂ„n blockkedjan. I det hĂ€r fallet fokuserar vi pĂ„ verifiering av insĂ€ttningstransaktioner.Â
En blockkedje-bro med validering utanför kedjan fungerar enligt följande:Â
AnvÀndare interagerar med dApp för att sÀtta in token i det smarta kontraktet i kÀllkedjan.
DApp skickar sedan insÀttningstransaktionens hash till backend-servern via ett API.
Transaktionshash Àr föremÄl för flera valideringar av servern. Om det anses legitimt signerar en undertecknare ett meddelande och skickar signaturen tillbaka till anvÀndargrÀnssnittet via API:et.
Vid mottagandet av signaturen verifierar DApp den och tillÄter anvÀndaren att dra tillbaka sina token frÄn mÄlkedjan.
Backend-servern mÄste se till att insÀttningstransaktionen den behandlar faktiskt har intrÀffat och inte har förfalskats. Denna backend-server avgör om en anvÀndare kan ta ut token i mÄlkedjan och Àr dÀrför ett högt vÀrderat mÄl för angripare.
Backend-servern mĂ„ste validera strukturen för transaktionens utsĂ€nda hĂ€ndelse, liksom kontraktsadressen som avgav hĂ€ndelsen. Om den senare försummas kan en angripare distribuera ett skadligt kontrakt för att skapa en insĂ€ttningshĂ€ndelse med samma struktur som en legitim insĂ€ttningshĂ€ndelse.Â
Om backend-servern inte verifierar vilken adress som avgav hÀndelsen anser den att detta Àr en giltig transaktion och underteckna meddelandet. Angriparen kunde sedan skicka transaktionshash till backend, kringgÄ verifiering och lÄta dem dra tillbaka token frÄn mÄlkedjan.
Felaktig hantering av inbyggda token
Broar tar olika tillvĂ€gagĂ„ngssĂ€tt för att hantera inbyggda token och nyttokrypto. Den inbyggda token pĂ„ Etherum-nĂ€tverket Ă€r till exempel ETH och de flesta nyttokrypto följer ERC-20-standarden.Â
NĂ€r en anvĂ€ndare avser att överföra sin ETH till en annan kedja mĂ„ste de först sĂ€tta in det i brokontraktet. För att uppnĂ„ detta fĂ€ster anvĂ€ndaren helt enkelt ETH till transaktionen och mĂ€ngden ETH kan hĂ€mtas genom att lĂ€sa âmsg.valueâ -fĂ€ltet av transaktionen.
InsĂ€ttning av ERC-20-token skiljer sig avsevĂ€rt frĂ„n att sĂ€tta in ETH. För att sĂ€tta in en ERC-20-token mĂ„ste anvĂ€ndaren först tillĂ„ta brokontraktet att spendera hens token. Efter att de har godkĂ€nt detta och satt in token i brokontraktet kommer kontraktet antingen att brĂ€nna anvĂ€ndarens token med hjĂ€lp av" burnFrom()"-funktionen eller överföra anvĂ€ndarens token till kontraktet med funktionen "TransferFrom()".Â
Ett tillvÀgagÄngssÀtt för att skilja detta Àr att anvÀnda ett if-sats-uttalande inom samma funktion. Ett annat tillvÀgagÄngssÀtt Àr att skapa tvÄ separata funktioner för att hantera alla scenarier. Att försöka sÀtta in ETH med ERC-20-insÀttningsfunktionen kan leda till förlust av dessa tillgÄngar.
Vid hantering av ERC-20 insÀttningsförfrÄgningar anger anvÀndare vanligtvis tokenadressen som inmatning till insÀttningsfunktionen. Detta innebÀr en betydande risk eftersom opÄlitliga externa samtal kan intrÀffa under transaktionen. Att implementera en vitlista som endast innehÄller token som stöds av bron Àr en vanlig praxis för att minimera risken. Endast vitlistade adresser fÄr skickas som argument. Detta förhindrar externa samtal eftersom projektgruppen redan har filtrerat tokenadressen.
Problem kan dock ocksĂ„ uppstĂ„ nĂ€r broar hanterar överföring av inbyggd token pĂ„ tvĂ€rkedja, eftersom inbyggda token inte har nĂ„gon adress. En nolladress (0x000... 0) Ă€r representativ för denna inbyggda token. Detta kan vara problematiskt eftersom överföring av nolladressen till funktionen kan kringgĂ„ vitlistverifieringen Ă€ven om den implementeras felaktigt.Â
NĂ€r brokontraktet anvĂ€nder âTransferFromâ för att överföra anvĂ€ndartillgĂ„ngar till kontraktet, returnerar det externa samtalet till nolladressen falskt eftersom det inte finns nĂ„gon âTransferFromâ -funktion implementerad i nolladressen. Transaktionen kan dock fortfarande intrĂ€ffa om kontraktet inte hanterar returvĂ€rdet pĂ„ lĂ€mpligt sĂ€tt. Detta skapar en möjlighet för angripare att utföra transaktionen utan att överföra nĂ„gra token till kontraktet.
Felkonfigurering
I de flesta blockkedje-broar ansvarar en privilegierad roll för vitlistning eller svartlistning av token och adresser, tilldelning eller Àndring av signerare och andra kritiska konfigurationer. Att se till att alla konfigurationer Àr korrekta Àr avgörande, eftersom Àven till synes triviala övervakningar kan leda till betydande förluster.
Faktum Àr att det har förekommit en incident dÀr angriparen framgÄngsrikt kringgick verifieringen av en överföring pÄ grund av en felkonfiguration. Projektgruppen genomförde en protokolluppgradering nÄgra dagar före hackningen, dÀr bland annat en variabel Àndrades. Variabeln anvÀndes för att representera standardvÀrdet för det betrodda meddelandet. Denna förÀndring resulterade i att alla meddelanden automatiskt ansÄgs ha bevisats, vilket gjorde det möjligt för en angripare att skicka ett godtyckligt meddelande och bli godkÀnd i verifieringsprocessen.
FörbÀttra brosÀkerhet
De fyra vanliga brosĂ„rbarheterna som förklaras ovan visar utmaningarna för att sĂ€kerstĂ€lla sĂ€kerhet i ett sammankopplat blockkedje-ekosystem. Det finns viktiga övervĂ€ganden för att hantera var och en av dessa sĂ„rbarheter och inga instruktioner kan tillĂ€mpas pĂ„ alla.Â
Till exempel Ă€r det utmanande att tillhandahĂ„lla allmĂ€nna riktlinjer för att sĂ€kerstĂ€lla en felfri verifieringsprocess eftersom varje bro har unika verifieringskrav. Det mest effektiva sĂ€ttet att förhindra kringgĂ„ende av verifiering Ă€r att noggrant testa bron mot alla möjliga attackvektorer och se till att verifieringslogiken Ă€r sund.Â
Sammanfattningsvis Ă€r det viktigt att utföra rigorösa tester mot potentiella attacker och Ă€gna sĂ€rskild uppmĂ€rksamhet Ă„t de vanligaste sĂ€kerhetsproblemen i broar. Â
SammanfattningsvisÂ
PÄ grund av dess höga vÀrde har tvÀrkedjebroar lÀnge varit ett mÄl för angripare. Byggare kan stÀrka sina broars sÀkerhet genom att genomföra grundliga tester före distribution och delta i tredjepartsrevisioner, vilket minskar risken för de förödande hackarna som har plÄgat broar under de senaste Ären. Broar mÄste finnas i en vÀrld med flera kedjor, men sÀkerhet mÄste vara en primÀr prioritering vid utformandet och byggandet av en effektiv Web3-infrastruktur.
Mer information
Vad Àr tvÀrkedjeinteroperabilitet?
Tre populĂ€ra kryptobroar â sĂ„ hĂ€r fungerar de
Ansvarsfriskrivning och riskvarning: detta innehĂ„ll presenteras för dig âi befintligt skickâ och endast för allmĂ€n information och utbildningsĂ€ndamĂ„l, utan representation eller garanti av nĂ„got slag. Det ska inte tolkas som ekonomisk, juridisk eller annan professionell rĂ„dgivning. Det Ă€r inte heller avsett att rekommendera köp av nĂ„gon specifik produkt eller tjĂ€nst. Du bör söka efter din egen rĂ„dgivning frĂ„n lĂ€mpliga professionella rĂ„dgivare. I de fall dĂ„ artikeln har skrivits av en tredje part, tillhör Ă„sikterna som uttrycks denna tredje part och Ă„terspeglar inte nödvĂ€ndigtvis Binance Academys Ă„sikter. LĂ€s vĂ„r fullstĂ€ndiga ansvarsfriskrivning hĂ€r för mer information. Priserna pĂ„ digitala tillgĂ„ngar kan vara volatila. VĂ€rdet pĂ„ din investering kan gĂ„ ner eller upp och du kanske inte fĂ„r tillbaka det investerade beloppet. Du Ă€r sjĂ€lv ansvarig för dina investeringsbeslut och Binance Academy ansvarar inte för eventuella förluster som du kan Ă„dra dig. Detta material ska inte tolkas som ekonomisk, juridisk eller annan professionell rĂ„dgivning. Se vĂ„ra anvĂ€ndarvillkor och riskvarning för mer information.