Millised on tuntud sildade turvaaugud?
Avaleht
Artiklid
Millised on tuntud sildade turvaaugud?

Millised on tuntud sildade turvaaugud?

EdasijÔudnud
Avaldatud Mar 22, 2023VĂ€rskendatud Jun 15, 2023
9m

See artikkel on kogukonna esitatud. Autor on Minzhi He, CertiK audiitor.

Selles artiklis kaasautori/autori vaated ei pruugi kajastada Binance'i akadeemia vaateid.

TL;DR

Plokiahela sillad on plokiahela ruumis koostalitlusvĂ”ime saavutamiseks kriitilise tĂ€htsusega. SeetĂ”ttu on plokiahela silla turvalisus ĂŒlimalt tĂ€htis. Levinumate sildade turvaaukude hulka kuuluvad nĂ”rk ahelasisene ja ahelavĂ€line valideerimine, natiivsete tokenite ebaĂ”ige kĂ€sitlemine ja valed konfiguratsioonid. Hea kontrollimise loogika tagamiseks on soovitatav testida silda kĂ”igi vĂ”imalike rĂŒndevektorite vastu.

Sissejuhatus 

Plokiahela sild on protokoll, mis ĂŒhendab kahte plokiahelat, et lubada nende vahelist suhtlust. Kui sul on Bitcoin, kuid soovid osaleda DeFi tegevuses Ethereumi vĂ”rgus, lubab plokiahela sild seda teha ilma oma Bitcoine mĂŒĂŒmata. 

Plokiahela sillad on plokiahela ruumis koostalitlusvĂ”ime saavutamiseks ĂŒliolulised. Need toimivad erinevate ahelasisese ja ahelavĂ€lise valideerimiste abil ning seetĂ”ttu on neil erinevad turvaaugud.

Miks on silla turvalisus kriitiline? 

Sild hoiab tavaliselt tokenit, mille kasutaja soovib ĂŒhest ahelast teise ĂŒle kanda. Nutilepingutena kasutusele vĂ”etud sildadel on tihti mĂ€rkimisvÀÀrne hulk tokeneid, kuna ahelatevahelised ĂŒlekanded kogunevad, muutes need hĂ€kkerite jaoks tulusateks sihtmĂ€rkideks. 

Lisaks on plokiahela sildadel suur rĂŒndepind, kuna need sisaldavad paljusid komponente. Seda silmas pidades on pahatahtlikud osapooled vĂ€ga motiveeritud sihtima ahelatevahelisi rakendusi, et saada suuri rahasummasid. 

RĂŒnnakud sildade vastu tekitasid 2022. aastal ĂŒle 1,3 miljardi USA dollari suuruse kahju, mis moodustas CertiKi hinnangul 36% aasta kogukahjust. 

Tuntud sildade turvaaugud

Sildade turvalisuse suurendamiseks on kasulik mÔista sildade levinumaid turvaauke ja enne kÀivitamist sildu testida. Need turvaauke vÔib liigitada nelja jÀrgmisesse valdkonda. 

NÔrk ahelasisene valideerimine

Lihtsate sildade puhul, eriti nende, mis on loodud konkreetsete DApp-ide jaoks, on ahelasisene valideerimine hoitud minimaalsena. Need sillad toetuvad tsentraliseeritud taustaprogrammile, et teostada pĂ”hitoiminguid, nagu vermimine, pĂ”letamine ja tokenite ĂŒlekandmine, samal ajal kui kĂ”ik kontrollid tehakse vĂ€ljaspool ahelat.

Seevastu muud tĂŒĂŒpi sillad kasutavad sĂ”numite kinnitamiseks ja ahelasiseseks kontrollimiseks nutilepinguid. Selle stsenaariumi korral, kui kasutaja kannab raha ahelasse, genereerib nutileping allkirjastatud sĂ”numi ja tagastab tehingus allkirja. See allkiri on sissemakse tĂ”end ja seda kasutatakse teises ahelas kasutaja vĂ€ljamaksetaotluse kontrollimiseks. See protsess peaks suutma Ă€ra hoida mitmesuguseid turvarĂŒnnakuid, sealhulgas kordusrĂŒnnakuid ja vĂ”ltsitud sissemaksekirjeid. 

Kui aga ahelasisese valideerimise kĂ€igus ilmneb haavatavus, vĂ”ib rĂŒndaja pĂ”hjustada tĂ”sist kahju. NĂ€iteks kui sild kasutab tehingukirje kinnitamiseks rĂ€sipuud, vĂ”ib rĂŒndaja luua vĂ”ltsitud tĂ”endeid. See tĂ€hendab, et kui valideerimisprotsess on haavatav, saavad nad tĂ”endi kinnitamisest mööda minna ja oma kontole uusi tokeneid vermida.

Teatud sillad rakendavad „mĂ€hitud tokenite“ kontseptsiooni. NĂ€iteks kui kasutaja kannab DAI Ethereumist BNB ketti, vĂ”etakse tema Ethereumi lepingust DAI ja samavÀÀrne kogus pakitud DAI-d vĂ€ljastatakse BNB ketti. 

Kui see tehing pole aga korralikult kinnitatud, vĂ”ib rĂŒndaja funktsiooniga manipuleerides juurutada pahatahtliku lepingu, et suunata mĂ€hitud tokenid sillalt valele aadressile. 

RĂŒndajad vajavad ka ohvreid, kes kinnitaksid tokenite ĂŒlekandmiseks sillalepingu, kasutades funktsiooni „transferFrom”, et sillalepingust varasid vĂ”tta. 

Kahjuks on see veelgi hullemaks muutunud, kuna paljud sillad nĂ”uavad DApp-i kasutajatelt lĂ”pmatut tokeni kinnitust. See on levinud praktika, mis alandab gaasitasusid, kuid tekitab lisariske, vĂ”imaldades nutilepingul pÀÀseda ligi kasutaja rahakotis olevatele piiramatule tokenite kogusele. RĂŒndajad saavad kasutada Ă€ra valideerimise puudumist ja liigset heakskiitu, et teistelt kasutajatelt tokeneid endale ĂŒle kanda.

NÔrk ahelavÀline valideerimine

MĂ”nes sildsĂŒsteemis mĂ€ngib ahelavĂ€line taustaserver plokiahelast saadetud sĂ”numite legitiimsuse kontrollimisel kriitilist rolli. Antud juhul keskendume sissemaksete kontrollimisele. 

AhelavÀlise valideerimisega plokiahela sild toimib jÀrgmiselt: 

  1. Kasutajad suhtlevad tokenite lÀhteahela nutilepingusse hoiustamiseks DApp-iga.

  2. SeejÀrel saadab DApp API kaudu deposiiditehingu rÀsi taustaserverisse.

  3. Server peab tehingu rÀsi mitu korda kinnitama. Kui seda peetakse ÔiguspÀraseks, allkirjastab allkirjastaja sÔnumi ja saadab allkirja API kaudu kasutajaliidesesse tagasi.

  4. Allkirja saamisel DApp kontrollib seda ja lubab kasutajal oma tokenid sihtahelast eemaldada.

Taustserver peab tagama, et tema poolt töödeldav sissemakse on tegelikult toimunud ja seda ei ole vĂ”ltsitud. See taustaserver mÀÀrab, kas kasutaja saab sihtahelas tokeneid vĂ€lja vĂ”tta, ja on seetĂ”ttu rĂŒndajatele vÀÀrtuslik sihtmĂ€rk.

Taustaserver peab kinnitama nii tehingu vĂ€ljastatud sĂŒndmuse struktuuri kui ka sĂŒndmuse vĂ€ljastanud lepingu aadressi. Kui viimane jĂ€etakse tĂ€helepanuta, vĂ”ib rĂŒndaja juurutada pahatahtliku lepingu, et vĂ”ltsida sissemakset, millel on sama struktuur kui seaduslikul sissemaksel. 

Kui taustaserver ei kontrolli, milline aadress sĂŒndmuse vĂ€ljastas, loeb ta seda kehtivaks tehinguks ja allkirjastab sĂ”numi. RĂŒndaja vĂ”ib seejĂ€rel saata tehingu rĂ€si taustaprogrammi, minnes kontrollist mööda ja lubades neil tokenid sihtahelast eemaldada.

Natiivsete tokenite ebaÔige kÀsitlemine

Sillad kasutavad natiivsete ja kasutustokenite kÀsitlemisel erinevaid lÀhenemisviise. NÀiteks Ethereumi vÔrgus on natiivseks tokeniks ETH ja enamik kasutustokeneid jÀrgib ERC-20 standardit. 

Kui kasutaja kavatseb oma ETH teise ketti ĂŒle kanda, peab ta selle esmalt sillalepingusse kandma. Selle tegemiseks lisab kasutaja tehingule lihtsalt ETH ja ETH summa saab kĂ€tte, lugedes „msg.value“ tehingu vĂ€lja.

ERC-20 tokenite sissemaksmine erineb oluliselt ETH sissemaksmisest. ERC-20 tokeni sissemaksmiseks peab kasutaja esmalt lubama sillalepingul oma tokenid kulutada. PÀrast seda, kui nad on selle heaks kiitnud ja tokenid sillalepingusse lisanud, pÔletab leping kasutaja tokenid kasutades funktsiooni "burnFrom()" vÔi kannab kasutaja tokenid lepingusse, kasutades funktsiooni "transferFrom()". 

Üks viis selle eristamiseks on kasutada samas funktsioonis if-else fraasi. Teine lĂ€henemisviis on luua iga stsenaariumi kĂ€sitlemiseks kaks eraldi funktsiooni. Proovides teha ETH sissemakset kasutades ERC-20 sissemaksefunktsiooni vĂ”ib see pĂ”hjustada nende vahendite kadumise.

Kasutajad annavad tavaliselt ERC-20 sissemaksetaotluste kÀsitlemisel sissemaksefunktsiooni sisendiks tokeni aadressi. See kujutab endast mÀrkimisvÀÀrset ohtu, kuna tehingu ajal vÔivad toimuda ebausaldusvÀÀrsed vÀliskÔned. Riski minimeerimise tavaline praktika on valge nimekirja rakendamine, mis sisaldab ainult silla toetatud tokeneid. Argumentidena on vÔimaldatud edastada ainult lubatud aadresse. See hoiab Àra vÀliskÔnede tekke, kuna projektimeeskond on tokeni aadressi juba filtreerinud.

Probleemid vÔivad aga tekkida ka siis, kui sillad tegelevad natiivse tokeni ahelatevahelise edastamisega, kuna algsel loal puudub aadress. Natiivset tokenit esindab nullaadress (0x000...0). See vÔib olla problemaatiline, kuna funktsioonile nullaadressi edastamine vÔib lubatud nimekirja kinnitamisest mööda minna, isegi kui see on valesti rakendatud. 

Kui sillaleping kutsub kasutaja varade lepingusse ĂŒlekandmiseks vĂ€lja funktsiooni „transferFrom“, tagastab vĂ€liskutse nullaadressile vÀÀrtuse VÀÀr, kuna nullaadressis pole ĂŒhtegi funktsiooni „transferFrom“. Kui leping ei kĂ€sitle tagastusvÀÀrtust nĂ”uetekohaselt, vĂ”ib tehing siiski aset leida. See loob rĂŒndajatele vĂ”imaluse teha tehingut ilma tokeneid lepingusse ĂŒle kandmata.

Vale konfiguratsioon

Enamikus plokiahela sildades vastutab privilegeeritud roll tokenite ja aadresside valgesse vĂ”i musta nimekirja lisamise, allkirjastajate mÀÀramise vĂ”i muutmise ning muude kriitiliste konfiguratsioonide eest. Ülioluline on tagada kĂ”igi konfiguratsioonide tĂ€psus, sest isegi nĂ€iliselt tĂŒhised möödalaskmised vĂ”ivad kaasa tuua mĂ€rkimisvÀÀrseid kahjusid.

Tegelikult on toimunud juhtum, kus rĂŒndaja lĂ€ks vale konfiguratsiooni tĂ”ttu edukalt mööda ĂŒlekandekirje kontrollist. Projektimeeskond tegi paar pĂ€eva enne hĂ€kkimist protokolli uuenduse, mis sisaldas muutuja muutmist. Muutujat kasutati usaldusvÀÀrse sĂ”numi vaikevÀÀrtuse esitamiseks. Selle muudatuse tulemusena loeti kĂ”ik sĂ”numid automaatselt tĂ”estatuks, mis vĂ”imaldas seega rĂŒndajal suvalise sĂ”numi saata ja kinnitusprotsess lĂ€bida.

Kuidas parandada sildade turvalisust

Neli eespool kirjeldatud levinumat silla haavatavust nĂ€itavad vĂ€ljakutseid, mis on seotud turvalisuse tagamisega omavahel ĂŒhendatud plokiahela ökosĂŒsteemis. KĂ”igi nende haavatavuste kĂ€sitlemisel pööratakse suurt tĂ€helepanu ja ĂŒkski tegevuskava ei kehti nende kĂ”igi kohta. 

NĂ€iteks ĂŒldiste juhiste andmine veatu kinnitamisprotsessi tagamiseks on keeruline, kuna igal sillal on kordumatud kinnitamise nĂ”uded. KĂ”ige tĂ”husam viis kontrollimisest möödavaatamise vĂ€ltimiseks on silla pĂ”hjalik testimine kĂ”igi vĂ”imalike rĂŒndevektorite vastu ja kontrolliloogika hea toimimine. 

KokkuvĂ”tteks vĂ”ib öelda, et vĂ”imalike rĂŒnnakute suhtes on oluline teostada rangeid teste ja pöörata erilist tĂ€helepanu sildade levinuimatele turvaaukudele.  

LÔppmÀrkused 

Ahelatevahelised sillad on oma kĂ”rge vÀÀrtuse tĂ”ttu olnud pikka aega rĂŒndajate sihtmĂ€rgiks. Arendajad saavad tugevdada oma sildade turvalisust, tehes pĂ”hjalikke kasutuselevĂ”tueelseid teste ja osaledes kolmandate osapoolte auditites, vĂ€hendades seelĂ€bi sildu viimase paari aasta jooksul tabanud laastavate hĂ€kkimiste ohtu. Sillad on mitmeahelalises maailmas kriitilise tĂ€htsusega, kuid tĂ”husa Web3 infrastruktuuri kavandamisel ja ehitamisel peab esmatĂ€htis olema turvalisus.

Lisalugemist

Mis on plokiahela sild (Blockchain Bridge)?

Mis on ahelateĂŒlene koostalitlusvĂ”ime?

Kolm populaarset krĂŒptosilda ja kuidas need toimivad

Mis on mÀhitud tokenid?

LahtiĂŒtlus ja riskihoiatus: seda sisu esitatakse sellisel kujul, nagu see on, ainult ĂŒldiseks teabeks ning hariduslikel eesmĂ€rkidel, ilma igasuguse esinduse vĂ”i garantiita. Seda ei tohiks tĂ”lgendada kui finants-, juriidilist vĂ”i muud professionaalset nĂ”ustamist ega kui soovitust konkreetse toote vĂ”i teenuse ostmiseks. Peaksid kĂŒsima nĂ”u asjakohastelt professionaalsetelt nĂ”ustajatelt. Kui artiklit on koostanud kolmandast osapoolest kaastööline, pane tĂ€hele, et vĂ€ljendatud seisukohad kuuluvad kolmandast osapoolest kaastöölisele ja ei pruugi kajastada Binance'i Akadeemia omasid. Lisateabe saamiseks lugege meie tĂ€ielikku lahtiĂŒtlust siit. Digitaalsete varade hinnad vĂ”ivad olla kĂ”ikuvad. Sinu investeeringu vÀÀrtus vĂ”ib langeda vĂ”i tĂ”usta ning sa ei pruugi investeeritud summat tagasi saada. Sina vastutad ainuisikuliselt oma investeerimisotsuste eest ja Binance'i Akadeemia ei vastuta vĂ”imalike kahjude eest. Seda materjali ei tohiks tĂ”lgendada finants-, juriidilise vĂ”i muu professionaalse nĂ”ustamisena. Lisateabe saamiseks loe meie kasutustingimusi ja riskihoiatust.