Sichern Sie das Solana-Ökosystem (4) – Kontovalidierung

0. Rückblick

1. Überblick

Im vorherigen Blogbeitrag haben wir besprochen, wie ein Programm aktualisiert werden kann. In diesem Beitrag werden wir die Probleme im Zusammenhang mit der Zugriffskontrolle einführen, die eines der häufigsten und grundlegendsten Sicherheitsthemen im Bereich DeFi darstellen.

2. Anweisungen

In Solana exportiert jedes Programm einen einzigen entrypoint, der mit entrypoint! definiert ist. Im Gegensatz zu Ethereum können Clients nur eine einzige Funktion aufrufen, die als Einstiegspunkt definiert ist und normalerweise process_instruction genannt wird. Die Einstiegspunktfunktion empfängt drei Parameter: die Programm-ID des Smart Contracts, die Konten, auf denen das Programm operieren wird, und die Instruktionsdaten. Die Instruktionsdaten geben an, welche Instruktion aufgerufen wird. Die folgende Abbildung zeigt ein Beispiel. Durch das Entpacken der Instruktionsdaten werden verschiedene Instruktionen (z. B. Lock, Unlock) ausgewählt. Somit sind die vom Einstiegspunkt aus erreichbaren Instruktionen für jeden öffentlich und können mit angegebenen Instruktionsdaten ausgeführt werden.

3. Kontenvalidierung

Wie erwähnt, empfängt das Programm die Konten, die es lesen oder schreiben muss. Dieses Design wirft zwei Fragen auf. Bei Konten, die gelesen werden sollen, wie kann garantiert werden, dass die in den Konten gespeicherten Daten vertrauenswürdig sind? Bei Konten, in die geschrieben werden soll, wie kann garantiert werden, dass nur privilegierte Benutzer die Anweisungen aufrufen können, um in die Konten zu schreiben? Im Folgenden erläutern wir das Problem der Zugriffskontrolle. Alle Testcodes finden Sie hier.

3.1 Code-Überprüfung (PrivilegeOwner)

Wir definieren zunächst zwei Strukturen: Door und Config. Nur das in der Struktur door angegebene Schlüsselkonto (Zeile 17) kann die erstellte door öffnen. Die Tür kann jedoch nicht geöffnet werden, wenn der Systemstatus gesperrt ist, was in der Struktur Config (Zeile 81) angegeben ist.

Wie erwähnt, gibt das Config-Konto an, ob die Tür geöffnet werden kann. In diesem Fall sollte nur ein Config-Konto im Programm vorhanden sein. Um dies zu erreichen, verwenden wir PDA, um die Daten von Config zu speichern. Nach der Initialisierung des Config-Kontos setzen wir das Attribut is_initialized auf true, damit es nicht erneut von Angreifern initialisiert werden kann (Zeilen 108–110).

Die Instruktion Open() wird zum Öffnen der Türen verwendet. Die Instruktion empfängt mehrere Konten, darunter das zu öffnende Tür-Konto, das config-Konto und das owner-Konto, das die Tür öffnen möchte. Um zu gewährleisten, dass die Tür zum Programm gehört und die Konfiguration gültig ist, überprüfen wir den Eigentümer des door-Kontos und des config-Kontos (Zeilen 204-205). Dies verhindert, dass bösartige Benutzer gefälschte Konten einspeisen. Dies beantwortet unsere erste Frage. Um zu gewährleisten, dass das zu lesende Konto vertrauenswürdig ist, müssen wir den Eigentümer des Kontos überprüfen! Beachten Sie, dass nur der Eigentümer des door-Kontos die Tür öffnen kann. In diesem Fall prüfen wir, ob das Eigentümer-Konto der tatsächliche owner der door ist und, was noch wichtiger ist, ob die Instruktion vom Eigentümer autorisiert wurde (Zeilen 217–219).

In der Funktion validate_owner() prüfen wir zunächst, ob die öffentlichen Schlüssel dieser beiden Konten identisch sind, und dann die Signatur des Eigentümers. Dies beantwortet die zweite Frage: Um zu gewährleisten, dass nur privilegierte Benutzer die open-Instruktion aufrufen können, müssen wir den Eigentümer und den Unterzeichner des Kontos überprüfen. Die close-Instruktion ist ähnlich wie open, und die Details finden Sie im Code.

Wir haben das Programm auf dem Testnet bereitgestellt und es ist unter dem folgenden Link zu finden:

https://explorer.solana.com/address/2Q7FFMWCthBvc6ubLQRx9TRswvaimmd66VaCAfHwsYuC?cluster=testnet

Alle Testtransaktionen sind unten aufgelistet. Der gesamte Prozess dieser Transaktion lautet: Allocate PDA()-> InitializeDoor()-> InitializeConfig()-> Unlock() -> Open() -> Close().

https://explorer.solana.com/tx/2X9CyMrHTNEvbzXTE95gem2j8spnvsQsabFeSpV8hiNpYjiQPPzLRqt5KN86ZYRjnQvydvs7y5eUjJK7no8knDhk?cluster=testnet
https://explorer.solana.com/tx/2XfVWiXeQeHbpqAEYm3AH2RU6hunnqtr155EC4EAM5Bq9VVZNP6QocAav9cPjEQdJFcQrbsSSxiKadr4HPMov8pz?cluster=testnet
https://explorer.solana.com/tx/5Em41sg7yFXeNpnEJnhUQJanfLWKwjMqiBeNAqEEzFrSN9P8zKKafcv5F7RKT2pseB171qeoa8Uz4fKgazzayCnW?cluster=testnet
https://explorer.solana.com/tx/2PMtzpSgjnKDLGmRWBdUSFBPimWnudCPekUYbWzPzokENFYa4N4ab4HCtynfGrzswFPTgGYKHU8PccUMHv3mXHkR?cluster=testnet
https://explorer.solana.com/tx/3kviP9MqkWGMV4yA7k7yPQ5BGfXmcYLcctmY1u2D7n56eT1nx8jMtDumkUNJy8yA3KkmzrmfQLjqpigc8ehGZzBN?cluster=testnet
https://explorer.solana.com/tx/38iEaJBzuGMLbfcszdVB8pkniezH8JrA3XGq7JdADZTQ4hNQC82GSTUA2bmcypdVy3t7htWnUzkZ4F8EakmNvqz8?cluster=testnet

3.2 Angriffstransaktion

Um die Bedeutung der Eigentümer- und Signaturprüfung zu verdeutlichen, verwenden wir zwei Angriffsszenarien als Beispiele.

Erstes Szenario

Das erste ist, dass der Eigentümer der "Tür" versucht, die Tür zu öffnen, wenn die config gesperrt ist. Um dies zu erreichen, erstellen wir in einem anderen Programm ein gefälschtes config-Konto und weisen dem Attribut is_lock den Wert false zu. Der Code des benutzerdefinierten Programms ist unten gezeigt.

Wir senden die Transaktion zum Erstellen des gefälschten Konfigurationskontos. Die öffentliche Schlüssel des gefälschten Konfigurationskontos lautet: 2MtSrbWp24VjPZQcSUkiWrvNro7qqKemVCsh3Yxc8LTy.

https://explorer.solana.com/tx/2qSyrL5gdQXmgGCFzmzMm1StFQRkDgWpss9A9jV11q2fgDGM5C1XRuXvbX1N5Dt3q2pRqnmyXHVtXGF5dqadAzpJ?cluster=testnet

Sobald das gefälschte config-Konto erstellt ist, speisen wir es in das Programm ein (Zeile 423).

Das Ergebnis ist unten gezeigt. Die Protokolle geben aus: incorrect program id for instruction, was bedeutet, dass der Eigentümer des config-Kontos das Programm sein muss. Somit kann der Angreifer diese Prüfung nicht umgehen.

Zweites Szenario

Das zweite Szenario ist, dass ein bösartiger Benutzer versucht, die Tür zu öffnen, wenn die Tür unverschlossen ist.

In diesem Fall speisen wir das echte Eigentümerkonto in das Programm ein (Zeile 419) und senden die Transaktion. Das Ergebnis ist unten gezeigt.

Es wird ausgegeben: Signature verification failed, was bedeutet, dass der tatsächliche Eigentümer die Transaktion zum Öffnen der Tür signieren muss, sodass unser zweiter Angriff ebenfalls fehlschlägt.

4. Zusammenfassung

In Solana implementieren Instruktionen spezifische Logik basierend auf verschiedenen Konten, die von Clients oder anderen Programmen eingespeist werden. Daher ist die ordnungsgemäße Prüfung der Konten von erheblicher Bedeutung.

In diesem Artikel stellen wir vor, wie das Konto ordnungsgemäß überprüft wird, und verwenden zwei Angriffsszenarien, um die Bedeutung dieser Prüfungen zu verdeutlichen. Bleiben Sie dran, weitere Artikel werden folgen.

Lesen Sie andere Artikel in dieser Serie:

Über BlockSec

BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit angesehener Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufstrebenden Web3-Welt, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Dienstleistungen für die Sicherheitsprüfung von Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die Sicherheitsentwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform zur Nachverfolgung und Untersuchung von Geldern sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu surfen.

Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden zweistellige Millionenbeträge von führenden Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital erhalten.

Offizielle Website: https://blocksec.com/

Offizieller Twitter-Account: https://twitter.com/BlockSecTeam