Back to Blog

Sicheres Solana-Ökosystem (7) – Typenverwechslung

April 29, 2022

0. Rückblick

1. Übersicht

Im vorherigen Blog haben wir die Implementierung eines allgemeinen Multi-Sig vorgestellt. In diesem Beitrag werden wir ein weiteres Sicherheitsproblem diskutieren: Type Confusion.

2. Deserialisierung/Serialisierung

In Solana werden die Programmzustände in Konten gespeichert. Das Problem der Typenverwechslung tritt während der Deserialisierung/Serialisierung von Konten auf. Die Programmlogik stützt sich normalerweise auf Datenstrukturen. Das Programm überprüft jedoch möglicherweise den Typ der Konten während des Deserialisierungs-/Serialisierungsprozesses nicht richtig. Dies kann von Angreifern ausgenutzt werden und zu unerwarteten Verlusten führen.

3. Code-Review (Type Confusion)

Im Folgenden erläutern wir das Problem der Typenverwechslung anhand eines einfachen Programms. Den Testcode finden Sie hier.

Im Testprogramm implementieren wir zwei Datenstrukturen, User und Metadata. Beide speichern den öffentlichen Schlüssel eines Kontos (eines anderen Kontos).

Das Programm hat drei verschiedene Anweisungen. Die Anweisung InitializeUser ist für die Erstellung des User-Kontos und die Festlegung eines autorisierten Kontos (d. h. authority) konzipiert. Ebenso wird die Anweisung InitializeMeta zur Erstellung des MetaData-Kontos und zur Festlegung eines normalen Kontos (d. h. account) aufgerufen. Die Anweisung Test zeigt, dass der Angreifer die Überprüfungslogik des Programms umgehen und Angriffe mit kontrolliertem MetaData durchführen kann.

Betrachten wir die Anweisung Test(). Das Programm stellt sicher, dass der Eigentümer des übergebenen User-Kontos das Programm selbst ist (Zeile 86 - Zeile 89). Nach der Deserialisierung (Zeile 92) vergleicht das Programm den öffentlichen Schlüssel des übergebenen authority-Kontos mit dem im User-Konto gespeicherten öffentlichen Schlüssel. Wenn sie nicht übereinstimmen, bricht das Programm ab (Zeile 93 - Zeile 96). Die letzte Überprüfung dient dazu, sicherzustellen, dass das autorisierte Konto die Transaktion signiert hat. Wenn ein Angreifer jedoch das kontrollierte Metadata-Konto übergibt, können alle Überprüfungen trotzdem umgangen werden. Der Grund dafür ist, dass das Programm den Typ der Konten nicht überprüft. Es empfängt ein Byte-Array und deserialisiert es direkt in verschiedene Arten von im Programm definierten Strukturen.

Wir stellen das Testprogramm für weitere Tests bereit, das unter diesem Link zu finden ist.

3.1 Transaktion senden

Nach der Bereitstellung des Programms schreiben wir das Skript, um die drei im Programm bereitgestellten Anweisungen nacheinander aufzurufen.

Wir rufen zunächst InitializeUser und InitializeMeta auf. Beachten Sie, dass wir unseren eigenen öffentlichen Schlüssel als account-Konto im Metadata-Konto festlegen.

In der Funktion test() übergeben wir das Metadata-Konto als User-Konto und unser eigenes Konto als authority_info (Zeile 347 - Zeile 348). Das Programm deserialisiert die Metadata mit der Struktur User, und alle Überprüfungen können umgangen werden.

Wir senden die Transaktion, die hier zu finden ist. Das Programm gab Erfolg zurück, was bedeutet, dass wir die Überprüfung mit dem nicht überprüften Kontotyp erfolgreich bestanden haben.

4. Zusammenfassung

In diesem Artikel stellen wir das Problem der Typenverwechslung in Solana vor. Es gibt viele Möglichkeiten, dieses Problem zu vermeiden. Wir können zum Beispiel ein Attribut hinzufügen, um den Typ des Kontos in der Struktur zu speichern, und das Programm sollte das Typattribut immer überprüfen, bevor Daten von dem übergebenen Konto gelesen oder dorthin geschrieben werden. Bleiben Sie dran, und wir werden in den kommenden Beiträgen mehr dazu berichten.

Lesen Sie andere Artikel dieser Serie:


Über BlockSec

BlockSec ist ein führendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufstrebenden Web3-Welt, um deren Massenadoption zu ermöglichen. Zu diesem Zweck bietet BlockSec Dienstleistungen für die Sicherheitsprüfung von Smart Contracts und EVM-Chains, die Phalcon-Plattform für die Sicherheitsentwicklung und die proaktive Abwehr von Bedrohungen, die MetaSleuth-Plattform für die Verfolgung und Untersuchung von Geldern sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu navigieren.

Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden von namhaften Investoren, darunter Matrix Partners, Vitalbridge Capital und Fenbushi Capital, Millionen von US-Dollar erhalten.

Offizielle Website: https://blocksec.com/

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

Sign up for the latest updates
Tether Freezes $6.76M USDT Linked to Iran's IRGC & Houthi Forces: Why On-Chain Compliance is Now a Geopolitical Battlefield
Security Insights

Tether Freezes $6.76M USDT Linked to Iran's IRGC & Houthi Forces: Why On-Chain Compliance is Now a Geopolitical Battlefield

Looking ahead, targeted freezing events like this $6.76M USDT action will only become more common. On-chain data analysis is improving. Stablecoin issuers are also working closely with regulators. As a result, hidden illicit financial networks will be exposed.

Weekly Web3 Security Incident Roundup | Mar 2 – Mar 8, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Mar 2 – Mar 8, 2026

During the week of March 2 to March 8, 2026, seven blockchain security incidents were reported with total losses of ~$3.25M. The incidents occurred across Base, BNB Chain, and Ethereum, exposing critical vulnerabilities in smart contract business logic, token deflationary mechanics, and asset price manipulation. The primary causes included a double-minting logic flaw during full token deposits that allowed an attacker to exponentially inflate their balances through repeated burn-and-mint cycles, a price manipulation vulnerability in an AMM-based lending market where artificially inflated vault shares created divergent price anchors to incorrectly force healthy positions into liquidation, and a flawed access control implementation relying on trivially spoofed contract interfaces that enabled attackers to bypass authorization to batch-mint and dump arbitrary tokens.

Weekly Web3 Security Incident Roundup | Feb 23 – Mar 1, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Feb 23 – Mar 1, 2026

During the week of February 23 to March 1, 2026, seven blockchain security incidents were reported with total losses of ~$13M. The incidents affected multiple protocols, exposing critical weaknesses in oracle design/configuration, cryptographic verification, and core business logic. The primary drivers included oracle manipulation/misconfiguration that led to the largest loss at YieldBloxDAO (~$10M), a crypto-proof verification flaw that enabled the FOOMCASH (~$2.26M) exploit, and additional token design and logic errors impacting Ploutos, LAXO, STO, HedgePay, and an unknown contract, underscoring the need for rigorous audits and continuous monitoring across all protocol layers.