BNB Chain ir viena no populārākajām blokķēdēm Web3 pasaulē. Tās saprātīgās maksas, ātrie darījumi un bagātīgā projektu ekosistēma piesaista lielu lietotāju skaitu. Tāpat kā jebkuras blokķēdes gadījumā, BNB ķēdes izstrādātājiem izstrādes procesā vispirms ir jāapsver drošības jautājumi: jo jebkurš līdzekļu zaudējums novedīs pie lietotāju uzticības protokolam un platformai vājināšanās, un drošības ievainojamības un hakeru uzbrukumi ir viens no lielākajiem riskiem. izstrādātāji saskaras.
Šajā rakstā mēs sniedzam desmit praktiskus drošības padomus, lai izstrādātāji varētu samazināt riskus un izstrādāt drošākus viedos līgumus BNB ķēdē.
01
╱ Definīcija ╱
Atkārtošanās uzbrukumi (Replay Attacks) ir pazīstami arī kā atkārtotas uzbrukumi, tie ir izplatīts uzbrukuma veids blokķēdes vidē. Tīkla drošībā 'atkārtošanās uzbrukums' ir uzbrukuma veids, kurā derīga datu pārsūtīšana tiek ļaunprātīgi vai krāpnieciski atkārtota vai aizkavēta.
Web3 un viedlīgumu kontekstā tas parasti nozīmē, ka uzbrucēji var atkārtoti veikt darījumus vai operācijas viedlīgumos bez oriģinālā lietotāja atļaujas. Tas var novest pie dažādām krāpšanas formām, piemēram, dubultas maksāšanas utt.
Šie uzbrukumi var radīt nopietnas sekas lietotājiem un izstrādātājiem, jo tie ļauj uzbrucējiem atkārtoti izmantot to pašu parakstu, lai iegūtu neatļautu piekļuvi visiem līguma līdzekļiem vai citiem aktīviem.
Lai novērstu atkārtošanās uzbrukumus, izstrādātājiem jāpievērš uzmanība, projektējot un īstenojot savus viedlīgumu kodus, kā arī jāievēro parakstu verificēšana un nozares labākās drošības prakses.
02
╱ Gadījuma izpēte ╱
Zemāk redzamais koda fragments attēlo tokenu pārsūtīšanu BNB ķēdē, izmantojot transfer īstenošanu. Šis kods ir viegli pakļauts atkārtošanās uzbrukumiem, ļaujot uzbrucējiem atkārtoti izmantot to pašu parakstu.
Šai funkcijai trūkst nonce vai atkārtošanās aizsardzības, kas ļauj uzbrucējiem vairākkārt 'atkārtot' parakstītu pārskaitījumu darījumu. Uzbrucēji var noķert parakstītu darījumu un atkārtoti to nosūtīt uz to pašu līgumu vai citu līgumu, un līgums joprojām uzskatīs to par derīgu, tādējādi uzbrucēji varētu izmantot šo trūkumu, lai nozagtu aktīvus.
03
╱ Uzlabojumu metodes ╱
Parakstā pievienojot nonce vai izmantojot mapping mainīgo, lai reģistrētu parakstu. Konkrētākā risinājuma īstenošana var atšķirties atkarībā no projekta dizaina.
01
╱ Definīcija ╱
Kad ļaunprātīgs līgums atkārtoti izsauc viegli uzbrukušu līgumu pirms sākotnējā izsaukuma pabeigšanas, notiek atkārtošanās uzbrukums. Citiem vārdiem sakot, uzbrucējs var 'apmānīt' viegli pakļauto līgumu, liekot tam domāt, ka tas ir pabeidzis darījumu un var doties uz nākamo, bet patiesībā tas joprojām izpilda uzbrucēja ļaunprātīgo kodu.
Tas var novest pie tā, ka uzbrucēji var manipulēt ar līguma stāvokli negaidītā veidā, un, iespējams, iegūt neatļautu piekļuvi līdzekļiem.
02
╱ Gadījuma izpēte ╱
Zemāk redzamajā koda fragmentā lietotāji var izņemt naudu no saviem kontiem, izsaucot izņemšanas withdraw funkciju un norādot summu, ko viņi vēlas izņemt. Tomēr, jo withdraw funkcija nepieļauj atkārtotu izsaukumu, tā ir viegli pakļauta atkārtošanās uzbrukumiem.
Uzbrucēji var izmantot vājumu, izveidojot ļaunprātīgu līgumu, atkārtoti izsaucot withdraw funkciju, pirms atlikums patiešām tiek noņemts no viņu konta. Funkcija msg.sender.call nosūta līdzekļus ļaunprātīgajam līgumam, un uzbrucējs atkārtoti izņem līdzekļus, izmantojot ļaunprātīgā līguma receive() funkciju, pirms viņu atlikums samazinās līdz nullēm, tādējādi iztukšojot upura līguma visus līdzekļus.
03
╱ Uzlabojumu metodes ╱
Veikt stāvokļa atjaunināšanu pirms jebkādiem ārējiem izsaukumiem.
Šo modeli sauc par 'Check-Effects-Interact' modeli, un tas ir dizaina modelis, ko izmanto, lai novērstu atkārtotu iejaukšanās uzbrukumus viedlīgumos. Šis modelis vispirms pārbauda priekšnoteikumus un pēc tam atjaunina stāvokli pirms jebkādu ārējo izsaukumu veikšanas, tādējādi atdalot stāvokļa izmaiņas no citu līgumu ārējiem izsaukumiem. Tādējādi, ja kāds ārējs izsaukums aktivizē atpakaļsaišu, kas mēģina atgriezties pie līguma, bet stāvoklis jau ir atjaunots, tas var novērst citas neparedzētas sekas.
Ievērojot šo modeli, izstrādātāji var nodrošināt, ka viņu līgumi ir drošāki un mazāk pakļauti atkārtošanās uzbrukumiem.
Vēl viens iespējamais risinājums būtu izmantot modifier, lai ierobežotu atkārtotu izsaukumu uz to pašu funkciju, kas ir līdzīga OpenZeppelin ReentrancyGuard.
01
╱ Definīcija ╱
Orākuli var palīdzēt viedlīgumiem iegūt informāciju no ārpuses no blokķēdes. Parasti decentralizēto apmaiņu (DEX) aktīvu cenas nosaka orākuli, kas iegūst cenas no DEX pēdējās veiksmīgās tirdzniecības.
Tomēr rodas jautājums, ka šo cenu var viegli manipulēt, radot problēmas viedlīgumā. Mēs bieži redzam gadījumus, kad cenas orākuli tiek manipulēti ar zibens aizdevumiem, jo zibens aizdevumi ļauj lietotājiem aizņemties milzīgas summas bez nodrošinājuma, ja vien tās tiek atmaksātas tajā pašā blokā. Tādējādi uzbrucēji var viegli ietekmēt vai pat manipulēt cenas, gūstot peļņu no viltus likvidācijas, pārmērīgas aizdošanas vai netaisnīgas tirdzniecības.
02
╱ Gadījuma izpēte ╱
Zemāk ir koda fragments, kas ir viegli pakļauts orākulu manipulācijas uzbrukumiem.
Šis līgums ļauj lietotājiem apmainīt tokenus A pret tokeniem B, taču tas paļaujas uz ārējiem orākuliem (Uniswap Pair līgums), lai iegūtu tokenu A un tokenu B rezerves cenu aprēķināšanai. Uzbrucēji var manipulēt ar Uniswap Pair līguma rezervēm un getAmountOut funkciju, kas beigu beigās noved pie maiņas izpildes par nepamatotu cenu.
03
╱ Uzlabojumu metodes ╱
Lai novērstu šādu uzbrukumu, izstrādātājiem jāizmanto decentralizēta orākulu tīkls, kas piekļūst chain-on centralizēto un decentralizēto biržu apgrozījuma vidējai cenai (VWAP) vai laika svērtajai vidējai cenai (TWAP). Tādējādi dati tiks savākti no vairākiem datu avotiem un plaša laika posma, padarot kodu grūtāk pakļaut uzbrukumiem un manipulācijām. Izstrādātājiem ir svarīgi spēt novērst jebkādus uzbrukumus, kas manipulē ar orākuliem, lai novērstu potenciālos trūkumus.
01
╱ Definīcija ╱
Pareiza funkcijas redzamības iestatīšana var nodrošināt viedlīguma drošību un integritāti. Nepareiza funkciju redzamības iestatīšana var ļaut neparedzētiem lietotājiem manipulēt ar līguma stāvokli, izraisot nopietnus jautājumus, piemēram, zādzību vai līguma funkciju kontroli.
Iestatot funkcijas redzamību uz privātu vai iekšēju, var nodrošināt, ka izstrādātājiem ir ierobežota piekļuve noteiktām funkcijām, ko var izsaukt tikai pilnvarotiem lietotājiem. Privātās funkcijas var izsaukt tikai no paša līguma, bet iekšējās funkcijas var izsaukt arī no pašreizējā līguma. Tas ļauj izstrādātājiem saglabāt kontroli pār piekļuves atļaujām, vienlaikus radot sarežģītākus un jaudīgākus līgumus.
02
╱ Gadījuma izpēte ╱
Funkcija setAdmin() ļauj ikvienam iestatīt jebkuru adresi kā līguma administratoru. Atkarībā no līguma iekšējām tiesībām, kas piešķirtas pārvaldības adresēm, tas var novest pie tā, ka izstrādātājs zaudē kontroli pār līgumu vai pat zaudē līdzekļus.
Izmainot funkcijas redzamību uz internal, daži līguma funkcijas var iekšēji ļaut noteiktiem lietotājiem kļūt par administratoriem.
03
╱ Uzlabojumu metodes ╱
Piekļuves modifier ir svarīga drošības funkcija, kas nosaka, kas var piekļūt konkrētām funkcijām vai mainīgajiem līgumā. Šie modifier var tikt izmantoti, lai ierobežotu piekļuvi noteiktām funkcijām vai mainīgajiem, kas attiecas uz konkrētajām lomām vai adresēm, novēršot ļaunprātīgu rīcību un nepieļaujot neatļautu piekļuvi vai manipulāciju ar līguma stāvokli.
Piemēram, kādam līgumam var būt funkcija, kuru var izsaukt tikai līguma īpašnieks, vai arī ir mainīgais, uz kuru var piekļūt tikai noteiktu adresātu grupa.
Izmainot redzamību modifier uz external un piekļuves modifier uz onlyOwner, var ierobežot piekļuvi setAdmin funkcijai tikai līguma īpašnieka adresēm. Tas novērsīs ļaunprātīgu ārēju pušu kontroli pār noteiktām privilēģiju funkcijām.
Pareiza redzamības un ierobežojošā modifier izmantošana var padarīt līgumu pārvaldību vieglāku un samazināt bieži sastopamos jautājumus, piemēram, atkārtotas iejaukšanās uzbrukumus (uzbrucējs atkārtoti izsauc funkciju, lai manipulētu ar līguma stāvokli) vai priekšlaicīgas izpildes uzbrukumus (uzbrucējs uzrauga gaidošās transakcijas un pirms likumīgas transakcijas izpildes manipulē ar līguma stāvokli).
Izmantojot šīs funkcijas pareizu izmantošanu, izstrādātāji var uzlabot savu līgumu drošību un uzticamību, samazināt neatļautas piekļuves risku un uzlabot viņu koda vispārējo kvalitāti un uzturējamību.
01
╱ Definīcija ╱
Nolemjot par nākotnes līgumu uzlabošanu, sākotnēji rūpīgi jāpārdomā līguma dizains. Līguma uzlabojamība attiecas uz to, ka, kad viedlīgums tiek izvietots blokķēdē, tam ir iespējams mainīt vai atjaunināt tā loģiku. Lai gan uzlabojamība var nodrošināt daudzas priekšrocības (kā kļūdu labošana, efektivitātes paaugstināšana vai jaunu funkciju pievienošana), tā vienlaikus ievieš arī riskus. Līguma uzlabojumi var novest pie jaunu trūkumu ieviešanas, palielināt līguma sarežģītību vai radīt neparedzētas sekas.
Jo īpaši, ka pilnvarotais administrators var uzlabot līgumu bez kopienas konsensa, līguma uzlabojamība rada uzticības problēmas. Izstrādātājiem rūpīgi jāizsver uzlabojamības priekšrocības un trūkumi un jānosaka, vai viņu projekts patiešām prasa uzlabojamu līgumu ieviešanu. Dažos gadījumos ir drošāk izstrādāt līgumu, kuru no paša sākuma ir iecerēts, ka tas nav maināms, nevis paļauties uz turpmākām izmaiņu iespējām.
02
╱ Uzlabojumu metodes ╱
Kad runa ir par līguma uzlabojamību, ir vairāki svarīgi principi, kurus jāievēro. Pirmkārt, vissvarīgāk ir nemainīt proxy bibliotēku. Proxy līguma bibliotēka ir ļoti sarežģīta, īpaši glabāšanas pārvaldībā un uzlabošanas mehānismos. Pat nelielas kļūdas var ievērojami ietekmēt Proxy un loģikas līguma darbību. Patiesībā daudzas nopietnas kļūdas, kas saistītas ar proxy, kas atklātas auditos, ir radušās nepareizas proxy bibliotēkas modificēšanas dēļ.
Vēl viens svarīgs praksē par līguma uzlabojamību ir iekļaut pamata līgumā glabāšanas 'atstarpi'. Loģikas līgumam ir jāiekļauj glabāšanas atstarpe līguma kodā, lai ņemtu vērā jaunus mainīgos, kas var tikt ieviesti, kad tiek izvietota jauna loģikas īstenošana. Pievienojot jaunus stāvokļa mainīgos, kļūst arvien svarīgāk atjaunināt 'atstarpi' lielumu. Šī pieeja var nodrošināt, ka nākotnes uzlabojumi noritēs gludi un neradīs problēmas.
Visbeidzot, jāizvairās no selfdestruct() izmantošanas vai no neuzticamiem līgumiem, veicot delegatecall()/call(). Uzbrucēji var izmantot šīs funkcijas, lai izjauktu loģikas īstenošanu vai izpildītu pielāgotu loģiku. Lai novērstu šādu gadījumu, ir svarīgi verificēt lietotāju ievadi! Nepieļaujiet, ka līgums veic delegatecall()/call() uz neuzticamiem līgumiem. Turklāt nav ieteicams izmantot delegatecall() loģikas līgumā, jo vairāku līgumu glabāšanas izkārtojuma pārvaldīšana var būt grūta. Ievērojot šos principus, izstrādātāji var maksimāli samazināt trūkumus un riskus savās līguma uzlabošanās procesā.
01
╱ Definīcija ╱
Priekšlaicīga tirdzniecība (Front-Running) ir sarežģīts un grūti risināms jautājums, jo lietotāji var gūt peļņu no laika atšķirības starp darījuma iesniegšanu un darījuma apstiprināšanu blokķēdē. Šo laiku izraisa mempool.
mempool ir pagaidu glabāšanas zona, kurā tiek uzglabāti neapstiprināti darījumi, kas ir pārraidīti tīklā. Visiem tīkla mezgliem ir sava mempool, kas ļauj ikvienam redzēt gaidošos darījumus un potenciāli tos pārtraukt, gūstot peļņu no tiem. Mempool arī sniedz minerāļiem iespēju pārvietot darījumus, lai maksimizētu viņu peļņu, radot tā saukto minerālu (vai maksimālo) izņemamo vērtību (MEV).
02
╱ Gadījuma izpēte ╱
Šeit ir piemērs funkcijai, kas ir viegli pakļauta priekšlaicīgas tirdzniecības uzbrukumiem.
Šī funkcija ļauj lietotājiem izteikt piedāvājumus izsolē, taču tā var tikt pakļauta priekšlaicīgas tirdzniecības uzbrukumiem. Pieņemsim, ka ļaunprātīgs lietotājs uzrauga blokķēdi un redz, ka cits lietotājs ir iesniedzis augstu cenu, tad šis ļaunprātīgais lietotājs var ātri iesniegt vēl augstāku piedāvājumu un tikt apstrādāts pirmajā kārtā, beigu beigās uzvarot izsolē.
Šajos izstrādājumos lietotāji iesniedz nezināmās solīšanas cenas, kas tiek glabātas mapping. Solīšanas summas ir šifrētas līdz solīšanas perioda beigām.
03
╱ Uzlabojumu metodes ╱
Izsoles beigās lietotāji var atklāt savus piedāvājumus, iesniedzot sākotnējo piedāvājuma summu un slepeno vērtību. Līgums pārbauda, vai piedāvājuma summa un slepenās hasha vērtība atbilst glabātajam slepenajam piedāvājumam, nodrošinot, ka piedāvājums ir iesniegts pirms izsoles beigām. Ja piedāvājums ir augstāks par pašreizējo augstāko piedāvājumu, tas kļūst par jauno augstāko piedāvājumu. Maskējot piedāvājuma summu pirms izsoles beigām, šī funkcija var mazināt priekšlaicīgas tirdzniecības uzbrukumus.
Priekšlaicīgas tirdzniecības un MEV ir kļuvušas par galvenajām bažām blokķēdes kopienā, un dažādi risinājumi, piemēram, tirdzniecības un taisnīgas kārtības pakalpojumi (FSS), ir izstrādāti, lai risinātu šos jautājumus. Tirdzniecība var palīdzēt novērst priekšlaicīgas tirdzniecības, slēpjot tirdzniecības detaļas no citiem lietotājiem, līdz tirdzniecība tiek izpildīta blokķēdē. No otras puses, FSS var samazināt priekšlaicīgas tirdzniecības un MEV ietekmi, droši kārtējot tirdzniecību ārpus ķēdes.
Skaidra un visaptveroša reaģēšanas plāna izstrāde ir būtiska, lai apstrādātu steidzamus drošības incidentus. Šim plānam jābūt regulāri pārskatītam, atjauninātam un testētam par efektivitāti. Steidzamu drošības incidentu gadījumā laiks ir vissvarīgākais. Tādējādi plānam jābūt iepriekš izstrādātam un jāiekļauj detaļas par identifikāciju, kontroli un mazināšanu.
Šim plānam jābūt efektīviem, lai visiem ieinteresētajiem dalībniekiem būtu skaidra situācija. Tajā pašā laikā regulāri datu dublēšana ir svarīga, lai novērstu datu zudumu. Plānā ir jāapraksta atjaunošanas process, lai atjaunotu datus un sistēmu iepriekšējā stāvoklī. Komandas locekļiem jāsaņem apmācība par šo plānu, lai nodrošinātu, ka katrs zina savu lomu un atbildību.
Rūpīgi sagatavots reaģēšanas plāns var neglābt situāciju, bet tas var samazināt notikumu ietekmi un saglabāt uzticību lietotājiem un ieinteresētajām pusēm.
Regulāra koda audita veikšana ir būtiska, lai saglabātu lietojumprogrammu drošību. Sadarbība ar profesionāliem auditiem, kas specializējas viedlīgumu drošībā, ir svarīgs solis izstrādes procesā. Auditori pārbaudīs kodā esošos trūkumus un sniegs ieteikumus vispārējās drošības uzlabošanai.
Prioritāte ir identificēt un atrisināt atklātos jautājumus un saglabāt atklātu komunikāciju ar auditiem, kas ir būtiski drošības uzlabošanai.
Turklāt saziņa ar auditiem ir arī svarīga. Auditori var detalizēti izskaidrot problēmas un trūkumus, kurus viņi ir konstatējuši, kā arī sniegt norādījumus un praktisku palīdzību, kā risināt šos trūkumus. Sadarbība ar profesionālām auditēšanas iestādēm var uzlabot drošību.
BNB ķēdes izstrādātājiem regulāra audita veikšana ir neatņemama jebkuras visaptverošas drošības stratēģijas sastāvdaļa. Proaktīva kļūdu identificēšana un novēršana kodā var samazināt drošības trūkumus.
Bounty programmas izmantošana ir efektīvs veids, kā motivēt kopienas balto cepuru hakerus ziņot par drošības trūkumiem projektu kodā. Piedāvājot tādas motivācijas kā tokeni vai citas balvas, jebkurš projekts var mudināt pieredzējušus cilvēkus pārbaudīt kodu un ziņot par jebkādām potenciālajām problēmām.
Ir būtiski izstrādāt skaidru, caurspīdīgu kļūdu atlīdzības programmu. Šajā plānā ir jāiekļauj: kādas veida kļūdas ir tiesīgas saņemt atlīdzību, kā novērtēt šo kļūdu vērtību utt. Tajā pašā laikā, pievienojot uzticamu trešo pusi kļūdu atlīdzības programmā, var palīdzēt nodrošināt plāna vienmērīgu darbību un atlīdzību godīgu sadalījumu.
Tāpat ir svarīgi, lai būtu daudzveidīga 'atlīdzību mednieku' grupa. Atšķirīgiem balto cepuru hakeriem ir dažādas specializācijas jomas, kas var koncentrēties uz citu cilvēku varbūt izlaistajiem trūkumiem.
Visbeidzot, kad ir ziņots par trūkumiem, ir steidzami un efektīvi jāreaģē uz šo trūkumu novēršanu. Atlīdzību programmas var būt efektīvs rīks trūkumu identificēšanai, taču problēmu faktiski jānovērš izstrādātāju komandai, lai tas būtu nozīmīgs.
Drošības izglītība Web3 lietotājiem ir būtisks solis drošas ekosistēmas izveidē. Garantējot klientu drošību, tas palīdz nodrošināt platformas drošību. Lietotājiem jābūt izglītotiem par labākajām praksēm, lai aizsargātu savus kontus un sensitīvo informāciju.
Visnozīmīgākais solis ir iemācīties, kā izvairīties no krāpnieciskām makšķerēšanas shēmām.
Krāpnieciskie makšķerētāji var maldināt lietotājus, izlikoties par likumīgām vietnēm vai pakalpojumiem, lai panāktu, ka lietotāji atklāj savas privātās atslēgas vai paroles. CertiK iesaka lietotājiem vienmēr rūpīgi pārbaudīt jebkuru saņemto informāciju, piemēram, e-pastus, avotus un URL vietnes, un nekad neievadīt savas privātās atslēgas vai paroles neuzticamās vietnēs.
Vēl viens svarīgs elements ir drošs un spēcīgs parole. CertiK šeit iesaka lietotājiem izmantot unikālas un sarežģītas paroles katram kontam un izvairīties no paroļu atkārtotas izmantošanas dažādās pakalpojumu jomās. Tāpat ir ieteicams izmantot paroli pārvaldītājus vai citus drošus glabāšanas mehānismus, lai droši glabātu paroles.
Visbeidzot, ir ārkārtīgi svarīgi aizsargāt privātos atslēgas. Privātā atslēga ir līdzvērtīga lietotāja parakstam, un to jebkurā laikā jāpasargā no citu piekļuves. Lietotājiem jāizvairās no privātās atslēgas kopīgošanas ar citiem un jāglabā to drošā vietā.
Kopsavilkums
Izstrādātājiem, kas veido viedlīgumus un dApps BNB Chain, jāievieš visaptveroša drošības pieeja, lai nodrošinātu savu lietotāju līdzekļu un aktīvu drošību. Vēl svarīgāk ir proaktīvi rīkoties, risinot drošības trūkumus, nevis pasīvi reaģējot; plānam jābūt izstrādātam pat pirms trūkuma rašanās, un visām attiecīgajām lietotāju un ieinteresēto pušu drošības izglītībai jābūt piemērotai. Apvienojot visus iepriekš minētos pasākumus, var palīdzēt projektam ievērojami samazināt drošības trūkumus un hakeru uzbrukumu riskus.