BNB Chain este unul dintre cele mai populare blockchain-uri din lumea Web3. Taxele sale rezonabile, tranzacțiile rapide și ecosistemul bogat de proiecte atrag un număr mare de utilizatori. Ca și în cazul oricărui blockchain, dezvoltatorii de pe BNB Chain ar trebui să ia în considerare mai întâi problemele de securitate în timpul procesului de dezvoltare: deoarece orice pierdere de fonduri va duce la o slăbire a încrederii utilizatorilor în protocol și platformă, iar vulnerabilitățile de securitate și atacurile hackerilor sunt unul dintre cele mai mari riscuri. se confruntă dezvoltatorii.
În acest articol, oferim zece sfaturi practice de securitate, astfel încât dezvoltatorii să poată reduce riscurile și să dezvolte contracte inteligente mai sigure pe BNB Chain.
01
╱Definiție ╱
Atacurile de reluare, cunoscute și ca atacuri de reluare și atacuri de reluare, sunt un tip comun de atac în mediul blockchain. În securitatea cibernetică, un „atac de reluare” este un tip de atac de rețea în care o transmisie de date validă este repetată sau amânată în mod rău intenționat sau fraudulos.
În contextul Web3 și al contractelor inteligente, acest lucru înseamnă, în general, că un atacator este capabil să repete o tranzacție sau o acțiune într-un contract inteligent fără permisiunea utilizatorului inițial. Acest lucru poate duce la diverse forme de fraudă, cum ar fi cheltuieli duble etc.
Aceste atacuri pot avea consecințe grave pentru utilizatori și dezvoltatori, deoarece le permit atacatorilor să refolosească aceeași semnătură pentru a obține acces neautorizat la toate fondurile sau alte active din contractul inteligent.
Pentru a preveni atacurile de reluare, dezvoltatorii trebuie să proiecteze și să implementeze cu atenție codul de contract inteligent și să urmeze verificarea semnăturii, precum și cele mai bune standarde de securitate din industrie.
02
╱ Analiza de caz ╱
Următorul fragment de cod reprezintă procesul de implementare a transferului unui token pe lanțul BNB. Codul este vulnerabil la atacurile de reluare, permițând unui atacator să refolosească aceeași semnătură.
Această caracteristică nu are protecția neîntreruptă sau reluare, permițând unui atacator să „relueze” un transfer semnat de mai multe ori. Un atacator poate intercepta o tranzacție semnată și o poate trimite din nou către același contract sau alt contract, iar contractul o va considera în continuare valabilă, astfel încât atacatorul poate exploata această vulnerabilitate pentru a fura active.
03
╱ Metode de îmbunătățire ╱
Adăugați un nonce la semnătură sau utilizați variabile de mapare pentru a înregistra semnătura. Soluțiile mai specifice vor varia în funcție de designul proiectului.
01
╱Definiție ╱
Un atac de reintrare are loc atunci când un contract rău intenționat apelează în mod repetat un contract vulnerabil înainte ca apelul inițial să fie finalizat. Cu alte cuvinte, un atacator poate „păcăli” un contract vulnerabil să creadă că a finalizat o tranzacție și că este liber să treacă la următoarea, dar în realitate încă execută codul rău intenționat al atacatorului.
Acest lucru ar putea duce la posibilitatea ca un atacator să manipuleze starea contractului în moduri neașteptate și, eventual, să obțină fonduri neautorizate.
02
╱Analiza de caz╱
În fragmentul de cod de mai jos, utilizatorii pot retrage fonduri din contul lor apelând funcția de retragere și specificând suma pe care doresc să o retragă. Cu toate acestea, deoarece funcția de retragere nu protejează împotriva apelurilor recursive către funcție, este vulnerabilă la atacurile de reintrare.
Un atacator ar putea exploata vulnerabilitatea prin crearea unui contract rău intenționat care apelează funcția de retragere de mai multe ori înainte ca soldul să fie efectiv debitat din contul său. Funcția msg.sender.call trimite fonduri către contractul rău intenționat, iar atacatorul folosește funcția de primire() a contractului rău intenționat pentru a retrage în mod repetat fonduri înainte ca soldul acestuia să fie redus la zero, epuizând astfel toate fondurile contractului victimă.
03
╱ Metode de îmbunătățire ╱
Efectuați actualizări de stare înainte de orice apeluri externe.
Acest model se numește modelul „Verificare-Efecte-Interacționare” și este un model de design utilizat pentru a preveni atacurile de reintrare în contractele inteligente. Acest model separă schimbările de stare de la apelurile externe la alte contracte, verificând mai întâi condițiile preliminare și apoi actualizând starea înainte de a efectua orice apeluri externe. În acest fel, dacă un apel extern declanșează un apel invers care încearcă să apeleze înapoi la contract, dar starea a fost deja actualizată, alte efecte neașteptate sunt prevenite.
Urmând acest model, dezvoltatorii se pot asigura că contractele lor sunt mai sigure și mai puțin susceptibile la atacuri de reintrare.
O altă soluție posibilă este utilizarea unui modificator pentru a limita apelurile multiple la aceeași funcție, la fel ca ReentrancyGuard a lui OpenZeppelin.
01
╱Definiție ╱
Oracolele pot ajuta contractele inteligente să recupereze informații din afara blockchain-ului. De obicei, prețul unui activ de schimb descentralizat (DEX) este determinat de prețul extras de oracol din ultima tranzacție reușită pe DEX.
Totuși, problema este că prețul poate fi ușor manipulat de oricine, provocând probleme cu contractul inteligent. Adesea vedem cazuri în care oracolele de preț sunt manipulate prin împrumuturi flash Motivul este că împrumuturile flash permit utilizatorilor să împrumute sume uriașe de bani fără garanții, atâta timp cât rambursează împrumutul în același bloc. Acest lucru facilitează atacatorilor să influențeze sau chiar să manipuleze prețurile, profitând din lichidări false, împrumuturi excesive sau tranzacții neloiale.
02
╱ Analiza de caz ╱
Mai jos este un fragment de cod care este vulnerabil la atacurile de manipulare a oracolului.
Acest contract permite utilizatorilor să schimbe jetonul A cu jetonul B folosind contractul de rutare, dar se bazează pe un oracol extern (contract Uniswap Pair) pentru a obține rezerve de jeton A și jeton B pentru a calcula prețul. Un atacator a reușit să manipuleze rezervele contractului Uniswap Pair, precum și funcția getAmountOut, determinând în cele din urmă ca schimbul să fie executat la un preț nerezonabil.
03
╱ Metode de îmbunătățire ╱
Pentru a preveni acest atac, dezvoltatorii ar trebui să utilizeze rețele oracle descentralizate care pot obține prețul mediu ponderat în volum (VWAP) sau prețul mediu ponderat în timp (TWAP) al schimburilor centralizate și descentralizate în lanț. În acest fel, datele vor fi colectate din mai multe surse și pe o gamă largă de timp, făcând codul mai puțin susceptibil la atacuri și manipulare. Este important ca dezvoltatorii să poată elimina orice vector de atac care manipulează oracolul din contractele inteligente pentru a preveni potențialele vulnerabilități.
01
╱Definiție ╱
Setarea corectă a vizibilității funcțiilor asigură securitatea și integritatea contractelor inteligente. Utilizarea setărilor incorecte de vizibilitate a funcției poate permite utilizatorilor neintenționați să manipuleze starea contractului, ceea ce duce la probleme grave, cum ar fi fonduri furate sau controlul funcționalității contractului.
Setând vizibilitatea unei funcții la privat sau intern, vă asigurați că dezvoltatorii au acces limitat la anumite funcții și că numai personalul autorizat poate apela aceste funcții. Funcțiile private pot fi apelate doar din contractul în sine, în timp ce funcțiile interne pot fi apelate și din contractul curent. Acest lucru permite dezvoltatorilor să creeze contracte mai puternice și mai complexe, păstrând în același timp controlul asupra accesului la funcționalitate.
02
╱ Analiza de caz ╱
Funcția setAdmin() permite oricui să seteze orice adresă ca administrator de contract. În funcție de permisiunile acordate în cadrul contractului pentru gestionarea adreselor, acest lucru poate determina dezvoltatorul să piardă controlul asupra contractului în sine și chiar să provoace o pierdere de fonduri.
Setând vizibilitatea funcției la intern , unele funcții contractuale pot permite intern anumitor utilizatori să fie setati ca administratori.
03
╱ Metode de îmbunătățire ╱
Modificatorii de acces sunt o caracteristică de securitate importantă care dictează cine poate accesa anumite funcții sau variabile dintr-un contract. Acești modificatori pot fi utilizați pentru a limita vizibilitatea anumitor funcții sau variabile la anumite roluri sau adrese și pentru a preveni accesul neautorizat al actorilor rău intenționați sau manipularea stării contractului.
De exemplu, un contract poate avea o funcție pe care numai proprietarul contractului o poate apela sau o variabilă care poate fi accesată doar de un anumit set de adrese.
Accesul la funcția setAdmin poate fi restricționat la adresa proprietarului contractului prin schimbarea modificatorului de vizibilitate la extern și setarea modificatorului de acces la onlyOwner. Acest lucru va împiedica părțile externe rău intenționate să preia controlul asupra anumitor funcții privilegiate.
Utilizarea corectă a vizibilității și modificatorilor restrictivi poate face gestionarea contractelor mai ușoară și poate reduce atacurile obișnuite, cum ar fi reintrarea (un atacator apelează în mod repetat o funcție pentru a manipula starea contractului) sau atacurile anticipate (un atacator monitorizează tranzacțiile în așteptare și manipulează starea contractului). înainte ca tranzacţiile juridice să fie executate).
Folosind aceste funcții în mod corespunzător, dezvoltatorii pot spori securitatea și fiabilitatea contractelor lor, pot reduce riscul accesului neautorizat și pot îmbunătăți calitatea generală și mentenabilitatea codului lor.
01
╱Definiție ╱
Când decideți dacă să actualizați un contract în viitor, este important să luați în considerare cu atenție designul contractului inițial. Actualizarea contractului se referă la proprietatea că logica unui contract inteligent poate fi modificată sau actualizată după ce acesta este implementat pe blockchain. În timp ce actualizarea poate oferi multe avantaje (cum ar fi remedierea erorilor, îmbunătățirea eficienței sau adăugarea de noi funcționalități), aceasta introduce și unele riscuri. Actualizările contractului pot introduce noi vulnerabilități, pot crește complexitatea contractului sau pot provoca consecințe nedorite.
Actualizarea contractelor ridică, de asemenea, probleme de încredere, deoarece administratorii agenților pot actualiza contractele fără consensul comunității. Dezvoltatorii trebuie să cântărească cu atenție avantajele și dezavantajele upgradabilității și să stabilească dacă introducerea contractelor actualizabile este cu adevărat necesară pentru proiectul lor. În unele cazuri, este mai sigur să proiectați un contract care este imuabil de la început, decât să vă bazați pe capacitatea de a-l modifica ulterior.
02
╱ Metode de îmbunătățire ╱
Când vine vorba de upgrade-ul contractului, există câteva practici importante de urmat. În primul rând, nu modificați biblioteca proxy. Biblioteca de contracte Proxy este extrem de complexă, mai ales în ceea ce privește gestionarea stocării și mecanismele de upgrade. Chiar și erorile mici pot afecta foarte mult funcționarea Proxy-ului și a contractelor logice. De fapt, multe dintre erorile critice legate de proxy descoperite în timpul auditului au fost cauzate de modificări neadecvate ale bibliotecii proxy.
Un alt aspect cheie al upgradeabilității contractului este includerea unui „decalaj” de stocare în contractul de bază. Contractele logice trebuie să includă un spațiu de stocare în codul contractului pentru a ține cont de noile variabile care pot fi introduse la implementarea noilor implementări logice. După adăugarea de noi variabile de stare, actualizarea dimensiunii „decalajului” devine și mai importantă. Această practică asigură că actualizările viitoare vor decurge fără probleme și fără probleme.
În cele din urmă, trebuie să evitați să utilizați selfdestruct() sau să efectuați delegatecall()/call() în contractele neîncrezătoare. Un atacator poate exploata aceste funcții pentru a submina implementarea logicii sau pentru a executa logica personalizată. Pentru a preveni acest lucru, este important să validați intrarea utilizatorului! Nu permiteți contractelor să efectueze delegatecall()/call() pe contracte care nu sunt de încredere. În plus, nu este recomandat să utilizați delegatecall() în contractele logice, deoarece gestionarea aspectului de stocare în mai multe contracte poate fi dificilă. Urmând aceste practici, dezvoltatorii pot minimiza vulnerabilitățile și riscurile în upgrade-urile contractelor lor.
01
╱Definiție ╱
Front-running a fost întotdeauna o problemă încăpățânată și greu de rezolvat, în care utilizatorii pot profita de întârzierea dintre trimiterea unei tranzacții și confirmarea acesteia pe blockchain. Această întârziere este cauzată de mempool.
mempool este o zonă de stocare temporară folosită pentru a stoca tranzacții neconfirmate care au fost transmise în rețea. Toate nodurile din rețea mențin un mempool, permițând oricui să vadă tranzacțiile în așteptare și, eventual, să intercepteze și să profite de pe urma acestora. Mempool oferă, de asemenea, minerilor o oportunitate de a rearanja tranzacțiile pentru a-și maximiza profiturile, creând ceea ce este cunoscut sub denumirea de valoare extractibilă minară (sau maximă) (MEV).
02
╱ Analiza de caz ╱
Mai jos este un exemplu de caracteristică de licitare la licitație care este predispusă la avans.
Această funcție permite utilizatorilor să liciteze în licitații, dar poate fi supusă unor atacuri de front. Să presupunem că un utilizator rău intenționat monitorizează blockchain-ul și vede că un alt utilizator a depus o ofertă mare. Utilizatorul rău intenționat poate trimite rapid o ofertă mai mare și poate fi prioritizat, câștigând în cele din urmă licitația.
În versiunea următoare, utilizatorii trimit prețuri licitate necunoscute, iar aceste sume licitate sunt stocate într-o mapare . Sumele licitate sunt criptate până la sfârșitul perioadei de licitare.
03
╱ Metode de îmbunătățire ╱
La sfârșitul perioadei de licitare, utilizatorii își pot dezvălui oferta prin trimiterea sumei licitate inițiale și a unei valori secrete. Contractul verifică dacă suma ofertei și hash-ul secret se potrivesc cu oferta secretă stocată, asigurându-se că oferta a fost depusă înainte de sfârșitul perioadei de licitație. Dacă acea ofertă este mai mare decât suma licitată maximă actuală, aceasta devine noua sumă licitată maximă. Această funcție atenuează atacurile inițiale prin mascarea sumelor licitate până la sfârșitul perioadei de licitație.
Front-running și MEV au devenit preocupări majore în comunitatea blockchain și au fost propuse diverse soluții, cum ar fi tranzacțiile și serviciile de comandă corectă (FSS), pentru a aborda aceste probleme. Tranzacțiile pot ajuta la prevenirea avansării prin ascunderea detaliilor tranzacției de la alți utilizatori până când tranzacția este executată pe blockchain. Pe de altă parte, FSS poate reduce impactul front-running și MEV prin comandarea sigură a tranzacțiilor în afara lanțului.
A avea un plan de răspuns clar și cuprinzător este esențial pentru gestionarea incidentelor de securitate de urgență. Planul ar trebui să fie revizuit, actualizat și testat în mod regulat pentru eficacitate. Când apare o urgență de securitate, timpul este esențial. Prin urmare, planul ar trebui să fie personalizat în prealabil și să includă pași operaționali detaliați pentru identificare, control și atenuare.
Planul ar trebui pus în aplicare în mod eficient pentru a informa toate părțile interesate. În același timp, backup-ul regulat al datelor este, de asemenea, important pentru a preveni pierderea datelor. Planul trebuie să sublinieze procesul de recuperare pentru a restabili datele și sistemele la starea lor anterioară. Membrii echipei ar trebui să primească instruire sistematică cu privire la plan pentru a se asigura că toată lumea își înțelege rolurile și responsabilitățile.
Un plan de răspuns bine pregătit poate să nu poată rezolva problema, dar poate minimiza impactul incidentului și poate menține încrederea cu utilizatorii și părțile interesate.
Auditurile regulate ale codului sunt esențiale pentru menținerea securității aplicației dvs. Lucrul cu un auditor profesionist care este specializat în securitatea unui contract inteligent este un pas important în procesul de dezvoltare. Auditorii vor examina codul pentru vulnerabilități și vor oferi recomandări pentru îmbunătățirea securității generale.
Prioritizarea și rezolvarea problemelor identificate și menținerea comunicării deschise cu auditorii sunt esențiale pentru îmbunătățirea securității.
În plus, comunicarea cu auditorii este de asemenea critică. Auditorii pot explica în detaliu problemele și vulnerabilitățile pe care le-au descoperit și pot oferi îndrumări și ajutor practic cu privire la modul de rezolvare a vulnerabilității. Prin cooperarea cu agenții/personal profesionist de audit, securitatea va fi „dusă la următorul nivel”.
Pentru dezvoltatorii lanțului BNB, efectuarea de audituri regulate este o parte integrantă a oricărei strategii cuprinzătoare de securitate. Identificarea și rezolvarea proactivă a vulnerabilităților din codul dvs. poate minimiza riscul de încălcare a securității.
Utilizarea unui program de recompense este o modalitate eficientă de a stimula hackerii de pălărie albă din comunitate să raporteze vulnerabilitățile de securitate în codul unui proiect. Oferind stimulente, cum ar fi jetoane sau alte recompense, orice proiect poate încuraja oamenii experimentați să revizuiască codul și să raporteze eventualele probleme pe care le găsesc.
Este important să aveți un program de recompensă pentru erori clar și transparent. Planul trebuie să includă: ce tipuri de vulnerabilități descoperite sunt eligibile pentru recompense, cum se evaluează valoarea acestor vulnerabilități etc. În același timp, includerea unei terțe părți reputate într-un program de recompense pentru erori poate ajuta la asigurarea funcționării bune a programului și a distribuirii corecte a recompenselor.
În același timp, este important să existe un „grup de vânători de recompense” divers. Diferiți hackeri cu pălărie albă au diferite domenii de expertiză și se pot concentra pe găsirea unor probleme pe care alții le-ar putea rata.
În cele din urmă, odată ce vulnerabilitățile sunt raportate, trebuie luate măsuri rapid și eficient pentru a le rezolva. Programele Bounty pot fi un instrument eficient pentru identificarea vulnerabilităților, dar are sens doar dacă echipa de dezvoltare remediază problema.
Educarea utilizatorilor Web3 despre securitate este un pas cheie în construirea unui ecosistem sigur. Asigurarea siguranței clienților va contribui la asigurarea siguranței platformei. Utilizatorii ar trebui să fie educați cu privire la cele mai bune practici pentru protejarea conturilor și a informațiilor sensibile.
Cea mai importantă parte este să înveți cum să eviți înșelătoriile de tip phishing.
Escrocii de tip phishing îi păcălesc pe utilizatori să-și dezvăluie cheile private sau parolele pretinzând că sunt un site web sau un serviciu legitim. CertiK recomandă utilizatorilor să verifice întotdeauna orice e-mail, sursă etc. URL-ul site-ului web utilizat atunci când primesc informații și să nu introducă niciodată chei private sau parole pe site-uri web neîncrezătoare.
Și o altă parte importantă este să ai parole sigure și puternice. CertiK recomandă utilizatorilor să utilizeze parole unice și complexe pentru fiecare cont și să evite reutilizarea parolelor în diferite servicii. De asemenea, parolele ar trebui să fie stocate în siguranță folosind un manager de parole sau alt mecanism de stocare securizat.
În cele din urmă, protejarea cheilor private este extrem de importantă. Cheia privată este echivalentă cu parola utilizatorului și ar trebui să se garanteze că nu va fi accesată de alții în orice moment. Utilizatorii ar trebui să evite să-și partajeze cheile private cu oricine și să le păstreze într-un loc sigur.
Rezuma
Dezvoltatorii care construiesc contracte inteligente și dApp-uri pe BNB Chain trebuie să adopte o abordare cuprinzătoare de securitate pentru a păstra fondurile și activele utilizatorilor în siguranță. Ceea ce este mai important este să fii mai degrabă proactiv decât reactiv atunci când te confrunți cu încălcările de securitate, să ai un plan în vigoare atunci când sau chiar înainte de producerea unei încălcări și să oferi educație adecvată în materie de securitate tuturor utilizatorilor și părților interesate relevante. Prin combinarea tuturor măsurilor de mai sus, proiectele pot fi ajutate să reducă semnificativ riscul de încălcare a securității și atacuri de hacker.