Die BNB-Kette ist eine der beliebtesten Blockchains in der Web3-Welt. Ihre günstigen Gebühren, schnellen Transaktionen und ihr reichhaltiges Projekt-Ökosystem ziehen eine große Anzahl von Benutzern an. Wie bei jeder Blockchain sollten Entwickler der BNB-Kette während des Entwicklungsprozesses zunächst Sicherheitsfragen berücksichtigen: Denn jeder Geldverlust führt zu einer Schwächung des Vertrauens der Benutzer in das Protokoll und die Plattform, und Sicherheitslücken und Hackerangriffe sind eines der größten Risiken Entwicklern gegenüber.

In diesem Artikel geben wir zehn praktische Sicherheitstipps, damit Entwickler Risiken reduzieren und sicherere Smart Contracts auf der BNB Chain entwickeln können.

01 

╱Definition ╱

Replay-Angriffe, auch Replay-Angriffe oder Replay-Angriffe genannt, sind eine häufige Angriffsart im Blockchain-Umfeld. In der Cybersicherheit ist ein „Replay-Angriff“ eine Art Netzwerkangriff, bei dem eine gültige Datenübertragung böswillig oder betrügerisch wiederholt oder verzögert wird.

Im Kontext von Web3 und Smart Contracts bedeutet dies im Allgemeinen, dass ein Angreifer eine Transaktion oder Aktion in einem Smart Contract ohne die Erlaubnis des ursprünglichen Benutzers wiederholen kann. Dies kann zu verschiedenen Formen des Betrugs wie Doppelausgaben usw. führen.

Diese Angriffe können schwerwiegende Folgen für Benutzer und Entwickler haben, da sie es Angreifern ermöglichen, dieselbe Signatur wiederzuverwenden, um sich unbefugten Zugriff auf alle Gelder oder andere Vermögenswerte des Smart Contracts zu verschaffen.

Um Replay-Angriffe zu verhindern, müssen Entwickler ihren Smart-Contract-Code sorgfältig entwerfen und implementieren und die Signaturüberprüfung sowie die branchenweit besten Sicherheitsstandards befolgen.

02 

╱ Fallanalyse ╱

Der folgende Codeausschnitt stellt den Übertragungsimplementierungsprozess eines Tokens in der BNB-Kette dar. Der Code ist anfällig für Replay-Angriffe, sodass ein Angreifer dieselbe Signatur wiederverwenden kann.

Dieser Funktion fehlt der Nonce- oder Replay-Schutz, sodass ein Angreifer eine signierte Übertragung mehrmals „wiederholen“ kann. Ein Angreifer kann eine signierte Transaktion abfangen und sie erneut an denselben oder einen anderen Vertrag senden, wobei der Vertrag sie weiterhin als gültig betrachtet, sodass der Angreifer diese Schwachstelle ausnutzen kann, um Vermögenswerte zu stehlen.

03 

╱ Verbesserungsmethoden ╱

Fügen Sie der Signatur eine Nonce hinzu oder verwenden Sie Zuordnungsvariablen, um die Signatur aufzuzeichnen. Die spezifischeren Lösungen variieren je nach Projektdesign.

01 

╱Definition ╱

Ein Wiedereintrittsangriff liegt vor, wenn ein böswilliger Vertrag wiederholt einen anfälligen Vertrag aufruft, bevor der erste Aufruf abgeschlossen ist. Mit anderen Worten: Ein Angreifer kann einen anfälligen Vertrag „austricksen“, indem er denkt, dass er eine Transaktion abgeschlossen hat und mit der nächsten fortfahren kann, in Wirklichkeit jedoch immer noch den Schadcode des Angreifers ausführt.

Dies könnte dazu führen, dass ein Angreifer den Vertragsstatus auf unerwartete Weise manipulieren und möglicherweise unautorisierte Gelder erhalten könnte.

02 

╱ Fallanalyse ╱

Im folgenden Codeausschnitt können Benutzer Geld von ihrem Konto abheben, indem sie die Auszahlungsfunktion aufrufen und den Betrag angeben, den sie abheben möchten. Da die Rückzugsfunktion jedoch keinen Schutz vor rekursiven Aufrufen der Funktion bietet, ist sie anfällig für Wiedereintrittsangriffe.

Ein Angreifer könnte die Sicherheitslücke ausnutzen, indem er einen böswilligen Vertrag erstellt, der die Auszahlungsfunktion mehrmals aufruft, bevor der Saldo tatsächlich von seinem Konto abgebucht wird. Die Funktion msg.sender.call sendet Gelder an den böswilligen Vertrag, und der Angreifer nutzt die Funktion „receive()“ des böswilligen Vertrags, um wiederholt Gelder abzuheben, bevor sein Guthaben auf Null reduziert wird, wodurch alle Gelder des Opfervertrags aufgebraucht werden.

03 

╱ Verbesserungsmethoden ╱

Führen Sie vor externen Anrufen Statusaktualisierungen durch.

Dieses Muster wird als „Check-Effects-Interact“-Muster bezeichnet und ist ein Entwurfsmuster, das zur Verhinderung von Wiedereintrittsangriffen in Smart Contracts verwendet wird. Dieses Muster trennt Statusänderungen von externen Aufrufen anderer Verträge, indem zunächst die Vorbedingungen überprüft und dann der Status aktualisiert wird, bevor externe Aufrufe durchgeführt werden. Wenn ein externer Anruf einen Rückruf auslöst, der versucht, den Vertrag zurückzurufen, der Status jedoch bereits aktualisiert wurde, werden auf diese Weise andere unerwartete Auswirkungen verhindert.

Durch die Befolgung dieses Musters können Entwickler sicherstellen, dass ihre Verträge sicherer und weniger anfällig für Wiedereintrittsangriffe sind.

Eine weitere mögliche Lösung besteht darin, einen Modifikator zu verwenden, um mehrere Aufrufe derselben Funktion zu beschränken, ähnlich wie ReentrancyGuard von OpenZeppelin.

01 

╱Definition ╱

Orakel können Smart Contracts dabei helfen, Informationen von außerhalb der Blockchain abzurufen. Normalerweise wird der Preis eines Vermögenswerts einer dezentralen Börse (DEX) durch den Preis bestimmt, den das Orakel aus der letzten erfolgreichen Transaktion auf dem DEX ermittelt hat.

Das Problem besteht jedoch darin, dass der Preis von jedermann leicht manipuliert werden kann, was zu Problemen mit dem Smart Contract führt. Wir sehen häufig Fälle, in denen Preisorakel durch Flash-Kredite manipuliert werden. Der Grund dafür ist, dass Flash-Kredite es Benutzern ermöglichen, riesige Geldbeträge ohne Sicherheiten zu leihen, solange sie den Kredit innerhalb desselben Blocks zurückzahlen. Dies macht es Angreifern leicht, Preise zu beeinflussen oder sogar zu manipulieren und von falschen Liquidationen, übermäßiger Kreditvergabe oder unfairem Handel zu profitieren.

02 

╱ Fallanalyse ╱

Nachfolgend finden Sie einen Codeausschnitt, der anfällig für Oracle-Manipulationsangriffe ist.

Mit diesem Vertrag können Benutzer mithilfe eines Routing-Vertrags Token A gegen Token B austauschen. Er ist jedoch auf ein externes Orakel (Uniswap-Pair-Vertrag) angewiesen, um Reserven an Token A und Token B zu erhalten und den Preis zu berechnen. Ein Angreifer konnte die Reserven des Uniswap-Pair-Vertrags sowie die getAmountOut-Funktion manipulieren, was letztendlich dazu führte, dass der Swap zu einem unangemessenen Preis ausgeführt wurde.

03 

╱ Verbesserungsmethoden ╱

Um diesen Angriff zu verhindern, sollten Entwickler ein dezentrales Oracle-Netzwerk verwenden, das den volumengewichteten Durchschnittspreis (VWAP) oder den zeitgewichteten Durchschnittspreis (TWAP) zentralisierter und dezentraler Börsen in der Kette ermitteln kann. Auf diese Weise werden Daten aus mehreren Quellen und über einen großen Zeitraum gesammelt, wodurch der Code weniger anfällig für Angriffe und Manipulationen wird. Für Entwickler ist es wichtig, alle Oracle-manipulierenden Angriffsvektoren aus Smart Contracts entfernen zu können, um potenzielle Schwachstellen zu verhindern.

01 

╱Definition ╱

Durch die richtige Einstellung der Sichtbarkeit von Funktionen wird die Sicherheit und Integrität intelligenter Verträge gewährleistet. Die Verwendung falscher Einstellungen für die Funktionssichtbarkeit kann es unbeabsichtigten Benutzern ermöglichen, den Vertragsstatus zu manipulieren, was zu schwerwiegenden Problemen wie gestohlenen Geldern oder der Kontrolle der Vertragsfunktionalität führen kann.

Indem Sie die Sichtbarkeit einer Funktion auf „privat“ oder „intern“ festlegen, stellen Sie sicher, dass Entwickler nur begrenzten Zugriff auf bestimmte Funktionen haben und dass nur autorisiertes Personal diese Funktionen aufrufen kann. Private Funktionen können nur aus dem Vertrag selbst aufgerufen werden, während interne Funktionen auch aus dem aktuellen Vertrag aufgerufen werden können. Dadurch können Entwickler leistungsfähigere und komplexere Verträge erstellen und gleichzeitig die Kontrolle über den Zugriff auf Funktionen behalten.

02 

╱ Fallanalyse ╱

Mit der Funktion setAdmin() kann jeder als Vertragsadministrator eine beliebige Adresse festlegen. Abhängig von den im Vertrag gewährten Berechtigungen zur Adressverwaltung kann dies dazu führen, dass der Entwickler die Kontrolle über den Vertrag selbst verliert und sogar einen Verlust von Geldern zur Folge hat.

Durch Festlegen der Sichtbarkeit der Funktion auf internal können einige Vertragsfunktionen intern die Festlegung bestimmter Benutzer als Administratoren ermöglichen.

03 

╱ Verbesserungsmethoden ╱

Zugriffsmodifikatoren sind ein wichtiges Sicherheitsmerkmal, das vorschreibt, wer auf bestimmte Funktionen oder Variablen in einem Vertrag zugreifen kann. Diese Modifikatoren können verwendet werden, um die Sichtbarkeit bestimmter Funktionen oder Variablen auf bestimmte Rollen oder Adressen zu beschränken und böswillige Akteure daran zu hindern, unbefugten Zugriff zu erlangen oder den Vertragsstatus zu manipulieren.

Beispielsweise könnte ein Vertrag eine Funktion haben, die nur der Eigentümer des Vertrags aufrufen kann, oder eine Variable, auf die nur eine bestimmte Gruppe von Adressen zugreifen kann.

Der Zugriff auf die setAdmin-Funktion kann auf die Adresse des Vertragseigentümers beschränkt werden, indem der Sichtbarkeitsmodifikator auf „extern“ und der Zugriffsmodifikator auf „onlyOwner“ gesetzt wird. Dadurch wird verhindert, dass böswillige externe Parteien die Kontrolle über bestimmte privilegierte Funktionen übernehmen.

Die ordnungsgemäße Verwendung von Sichtbarkeit und restriktiven Modifikatoren kann die Vertragsverwaltung vereinfachen und häufige Angriffe wie Wiedereintritt (ein Angreifer ruft wiederholt eine Funktion auf, um den Vertragsstatus zu manipulieren) oder Front-Running-Angriffe (ein Angreifer überwacht ausstehende Transaktionen und manipuliert den Vertragsstatus, bevor er legal ist) reduzieren Transaktionen werden ausgeführt).

Durch die entsprechende Nutzung dieser Funktionen können Entwickler die Sicherheit und Zuverlässigkeit ihrer Verträge erhöhen, das Risiko unbefugten Zugriffs verringern und die Gesamtqualität und Wartbarkeit ihres Codes verbessern.

01 

╱Definition ╱

Bei der Entscheidung, ob ein Vertrag in Zukunft erweitert werden soll, ist es wichtig, zunächst die Vertragsgestaltung sorgfältig zu prüfen. Die Aktualisierbarkeit von Verträgen bezieht sich auf die Eigenschaft, dass die Logik eines Smart Contracts geändert oder aktualisiert werden kann, nachdem er in der Blockchain bereitgestellt wurde. Während die Aufrüstbarkeit viele Vorteile mit sich bringen kann (z. B. die Behebung von Fehlern, die Verbesserung der Effizienz oder das Hinzufügen neuer Funktionen), birgt sie auch einige Risiken. Vertragsaktualisierungen können neue Schwachstellen mit sich bringen, die Vertragskomplexität erhöhen oder unbeabsichtigte Folgen haben.

Die Möglichkeit zur Vertragsaktualisierung wirft auch Vertrauensprobleme auf, da Agentenadministratoren Verträge ohne Konsens der Community aktualisieren können. Entwickler müssen die Vor- und Nachteile der Aktualisierbarkeit sorgfältig abwägen und feststellen, ob die Einführung aktualisierbarer Verträge für ihr Projekt wirklich notwendig ist. In manchen Fällen ist es sicherer, einen Vertrag zu entwerfen, der von Anfang an unveränderlich ist, als sich auf die Möglichkeit zu verlassen, ihn später zu ändern.

02 

╱ Verbesserungsmethoden ╱

Wenn es um die Erweiterbarkeit von Verträgen geht, sind mehrere wichtige Vorgehensweisen zu beachten. Ändern Sie in erster Linie nicht die Proxy-Bibliothek. Die Proxy-Vertragsbibliothek ist äußerst komplex, insbesondere im Hinblick auf Speicherverwaltung und Upgrade-Mechanismen. Selbst kleine Fehler können den Betrieb von Proxy- und Logikverträgen stark beeinträchtigen. Tatsächlich wurden viele der kritischen Proxy-bezogenen Fehler, die während der Prüfung entdeckt wurden, durch unangemessene Änderungen an der Proxy-Bibliothek verursacht.

Ein weiterer wichtiger Aspekt der Vertragsaktualisierungsfähigkeit ist die Aufnahme einer Speicherlücke im Basisvertrag. Logikverträge müssen eine Speicherlücke im Vertragscode enthalten, um neue Variablen zu berücksichtigen, die bei der Bereitstellung neuer Logikimplementierungen eingeführt werden können. Nach dem Hinzufügen neuer Zustandsvariablen wird die Aktualisierung der Größe der „Lücke“ noch wichtiger. Durch diese Vorgehensweise wird sichergestellt, dass zukünftige Upgrades reibungslos und ohne Probleme ablaufen.

Schließlich müssen Sie die Verwendung von „selfdestruct()“ oder die Ausführung „delegatecall()/call()“ bei nicht vertrauenswürdigen Verträgen vermeiden. Ein Angreifer kann diese Funktionen ausnutzen, um die Logikimplementierung zu untergraben oder benutzerdefinierte Logik auszuführen. Um dies zu verhindern, ist es wichtig, die Eingaben des Benutzers zu validieren! Erlauben Sie Verträgen nicht, Delegatecall()/call() für nicht vertrauenswürdige Verträge auszuführen. Darüber hinaus wird die Verwendung von „delegatecall()“ in Logikverträgen nicht empfohlen, da die Verwaltung des Speicherlayouts über mehrere Verträge hinweg schwierig sein kann. Durch die Befolgung dieser Vorgehensweisen können Entwickler Schwachstellen und Risiken bei ihren Vertragsaktualisierungen minimieren.

01 

╱Definition ╱

Front-Running war schon immer ein hartnäckiges und schwer zu lösendes Problem, bei dem Benutzer von der Verzögerung zwischen der Übermittlung einer Transaktion und deren Bestätigung auf der Blockchain profitieren können. Diese Verzögerung wird durch Mempool verursacht.

Mempool ist ein temporärer Speicherbereich, der zum Speichern unbestätigter Transaktionen verwendet wird, die an das Netzwerk gesendet wurden. Alle Knoten im Netzwerk unterhalten einen Mempool, sodass jeder ausstehende Transaktionen sehen und sie möglicherweise abfangen und davon profitieren kann. Mempool bietet Minern auch die Möglichkeit, Transaktionen neu zu ordnen, um ihre Gewinne zu maximieren und so einen sogenannten Miner (oder Maximum) Extractable Value (MEV) zu schaffen.

02 

╱ Fallanalyse ╱

Nachfolgend finden Sie ein Beispiel für eine Auktionsgebotsfunktion, die dazu neigt, vorrangig zu agieren.

Mit dieser Funktion können Benutzer in Auktionen bieten, sie kann jedoch anfällig für Angriffe im Vorfeld sein. Angenommen, ein böswilliger Benutzer überwacht die Blockchain und stellt fest, dass ein anderer Benutzer ein hohes Gebot abgegeben hat. Der böswillige Benutzer kann schnell ein höheres Gebot abgeben und priorisiert werden, wodurch er letztendlich die Auktion gewinnt.

In der folgenden Version geben Benutzer unbekannte Gebotspreise ab und diese Gebote werden in einem Mapping gespeichert. Gebotsbeträge werden bis zum Ende des Gebotszeitraums verschlüsselt.

03 

╱ Verbesserungsmethoden ╱

Am Ende des Gebotszeitraums können Nutzer ihr Gebot unter Angabe des ursprünglichen Gebotsbetrags und eines geheimen Wertes offenlegen. Der Vertrag überprüft, ob der Gebotsbetrag und der geheime Hash mit dem gespeicherten geheimen Gebot übereinstimmen, und stellt so sicher, dass das Gebot vor dem Ende des Auktionszeitraums abgegeben wurde. Wenn dieses Gebot höher ist als das aktuelle Höchstgebot, wird es zum neuen Höchstgebot. Diese Funktion schwächt Frontangriffe ab, indem Gebotsbeträge bis zum Ende des Auktionszeitraums maskiert werden.

Front-Running und MEV sind zu wichtigen Anliegen in der Blockchain-Community geworden, und es wurden verschiedene Lösungen wie Transaktionen und Fair Ordering Services (FSS) vorgeschlagen, um diese Probleme anzugehen. Transaktionen können dabei helfen, Front-Running zu verhindern, indem sie Transaktionsdetails vor anderen Benutzern verbergen, bis die Transaktion auf der Blockchain ausgeführt wird. Andererseits kann FSS die Auswirkungen von Front-Running und MEV durch sichere Off-Chain-Transaktionsbestellung reduzieren.

Ein klarer und umfassender Reaktionsplan ist für die Bewältigung von Sicherheitsvorfällen von entscheidender Bedeutung. Der Plan sollte regelmäßig überprüft, aktualisiert und auf Wirksamkeit getestet werden. Wenn ein Sicherheitsnotfall eintritt, ist Zeit von entscheidender Bedeutung. Der Plan sollte daher im Voraus angepasst werden und detaillierte operative Schritte zur Identifizierung, Kontrolle und Schadensbegrenzung enthalten.

Der Plan sollte effektiv umgesetzt werden, um alle Beteiligten auf dem Laufenden zu halten. Gleichzeitig ist eine regelmäßige Datensicherung wichtig, um Datenverlusten vorzubeugen. Der Plan muss den Wiederherstellungsprozess umreißen, um Daten und Systeme wieder in ihren vorherigen Zustand zu versetzen. Die Teammitglieder sollten eine systematische Schulung zum Plan erhalten, um sicherzustellen, dass jeder seine Rollen und Verantwortlichkeiten versteht.

Ein gut vorbereiteter Reaktionsplan kann das Problem möglicherweise nicht beheben, aber er kann die Auswirkungen des Vorfalls minimieren und das Vertrauen bei Benutzern und Stakeholdern aufrechterhalten.

Regelmäßige Code-Audits sind für die Aufrechterhaltung der Sicherheit Ihrer Anwendung von entscheidender Bedeutung. Die Zusammenarbeit mit einem professionellen Prüfer, der auf die Sicherheit intelligenter Verträge spezialisiert ist, ist ein wichtiger Schritt im Entwicklungsprozess. Prüfer untersuchen den Code auf Schwachstellen und geben Empfehlungen zur Verbesserung der Gesamtsicherheit.

Die Priorisierung und Lösung identifizierter Probleme sowie die Aufrechterhaltung einer offenen Kommunikation mit Prüfern sind für die Verbesserung der Sicherheit von entscheidender Bedeutung.

Darüber hinaus ist auch die Kommunikation mit den Prüfern von entscheidender Bedeutung. Prüfer können die von ihnen entdeckten Probleme und Schwachstellen detailliert erläutern und Anleitungen und praktische Hilfe zur Behebung der Schwachstelle geben. Durch die Zusammenarbeit mit professionellen Prüfstellen/Personal wird die Sicherheit „auf das nächste Level gehoben“.

Für BNB-Kettenentwickler ist die Durchführung regelmäßiger Audits ein wesentlicher Bestandteil jeder umfassenden Sicherheitsstrategie. Durch die proaktive Identifizierung und Behebung von Schwachstellen in Ihrem Code können Sie das Risiko von Sicherheitsverletzungen minimieren.

Der Einsatz eines Kopfgeldprogramms ist eine wirksame Möglichkeit, White-Hat-Hacker in der Community zu motivieren, Sicherheitslücken im Code eines Projekts zu melden. Durch die Bereitstellung von Anreizen wie Token oder anderen Belohnungen kann jedes Projekt erfahrene Personen dazu ermutigen, den Code zu überprüfen und potenzielle Probleme zu melden.

Es ist wichtig, ein klares und transparentes Bug-Bounty-Programm zu haben. Der Plan muss Folgendes umfassen: Welche Arten von entdeckten Schwachstellen kommen für Belohnungen in Frage, wie ist der Wert dieser Schwachstellen zu bewerten usw. Gleichzeitig kann die Einbeziehung eines seriösen Dritten in ein Bug-Bounty-Programm dazu beitragen, den reibungslosen Ablauf des Programms und die gerechte Verteilung der Belohnungen sicherzustellen.

Gleichzeitig ist es wichtig, eine vielfältige „Kopfgeldjägergruppe“ zu haben. Verschiedene White-Hat-Hacker verfügen über unterschiedliche Fachgebiete und können sich auf die Suche nach Problemen konzentrieren, die andere möglicherweise übersehen.

Schließlich müssen nach der Meldung von Schwachstellen schnell und effektiv Maßnahmen ergriffen werden, um diese zu beheben. Bounty-Programme können ein wirksames Instrument zur Identifizierung von Schwachstellen sein, sie machen jedoch nur dann Sinn, wenn das Entwicklungsteam das Problem tatsächlich behebt.

Die Aufklärung von Web3-Benutzern über Sicherheit ist ein wichtiger Schritt beim Aufbau eines sicheren Ökosystems. Die Gewährleistung der Sicherheit der Kunden trägt dazu bei, die Sicherheit der Plattform zu gewährleisten. Benutzer sollten über Best Practices zum Schutz ihrer Konten und sensiblen Informationen informiert werden.

Der wichtigste Teil besteht darin, zu lernen, wie man Phishing-Betrug vermeidet.

Phishing-Betrüger verleiten Benutzer dazu, ihre privaten Schlüssel oder Passwörter preiszugeben, indem sie vorgeben, eine legitime Website oder ein seriöser Dienst zu sein. CertiK empfiehlt Benutzern, beim Empfang von Informationen immer alle verwendeten E-Mail-Adressen, Quellen usw. Website-URLs zu überprüfen und niemals private Schlüssel oder Passwörter auf nicht vertrauenswürdigen Websites einzugeben.

Und ein weiterer wichtiger Teil sind sichere und sichere Passwörter. CertiK empfiehlt hiermit, dass Benutzer für jedes Konto eindeutige und komplexe Passwörter verwenden und die Wiederverwendung von Passwörtern für verschiedene Dienste vermeiden. Außerdem sollten Passwörter mit einem Passwort-Manager oder einem anderen sicheren Speichermechanismus sicher gespeichert werden.

Schließlich ist der Schutz privater Schlüssel äußerst wichtig. Der private Schlüssel entspricht dem Passwort des Benutzers und sollte zu keinem Zeitpunkt für andere zugänglich sein. Benutzer sollten ihre privaten Schlüssel nicht mit anderen teilen und sie an einem sicheren Ort aufbewahren.

Zusammenfassen

Entwickler, die intelligente Verträge und dApps auf der BNB-Kette erstellen, müssen einen umfassenden Sicherheitsansatz verfolgen, um die Gelder und Vermögenswerte ihrer Benutzer zu schützen. Wichtiger ist es, beim Umgang mit Sicherheitsverstößen proaktiv statt reaktiv vorzugehen; einen Plan zu haben, wenn oder sogar bevor es zu einem Verstoß kommt, und allen relevanten Benutzern und Interessenvertretern angemessene Sicherheitsschulungen anzubieten. Durch die Kombination aller oben genannten Maßnahmen kann Projekten dabei geholfen werden, das Risiko von Sicherheitsverletzungen und Hackerangriffen deutlich zu reduzieren.