Back to Blog

Sichere das Solana-Ökosystem (7) — Typenkonfusion

April 29, 2022
4 min read

0. Rückblick

1. Überblick

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

2. Deserialisierung/Serialisierung

In Solana werden die Programmzustände in Konten gespeichert. Das Problem der Typverwechslung tritt während der Deserialisierung/Serialisierung von Konten auf. Die Logik des Programms basiert normalerweise auf den Datenstrukturen. Das Programm prüft jedoch möglicherweise nicht korrekt den Typ der Konten während des Deserialisierungs-/Serialisierungsprozesses. Dies kann von Angreifern ausgenutzt werden und zu unerwarteten Verlusten führen.

3. Code-Überprüfung (Typverwechslung)

Im Folgenden veranschaulichen wir das Problem der Typverwechslung anhand eines einfachen Programms. Den Testcode finden Sie hier.

Im Testprogramm implementieren wir zwei Datenstrukturen, eine ist User und die andere ist 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 Verifizierungslogik 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, wird das Programm zurückgesetzt (Zeile 93 - Zeile 96). Die letzte Prüfung stellt sicher, dass das autorisierte Konto die Transaktion signiert hat. Wenn jedoch ein Angreifer das kontrollierte Metadata-Konto übergibt, können alle Prüfungen immer noch umgangen werden. Der Grund dafür ist, dass das Programm den Typ der Konten nicht prü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, und es kann unter diesem Link gefunden werden.

3.1 Transaktion senden

Nachdem das Programm bereitgestellt wurde, schreiben wir das Skript, um die drei im Programm bereitgestellten Anweisungen nacheinander aufzurufen.

Wir rufen zuerst InitializeUser und InitializeMeta auf. Beachten Sie, dass wir unseren eigenen öffentlichen Schlüssel als das im Metadata-Konto gespeicherte account-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 Prüfungen können umgangen werden.

Wir senden die Transaktion und sie kann hier gefunden werden. Das Programm gab Erfolg zurück, was bedeutet, dass wir die Prüfung mit dem ungeprüften Kontotyp erfolgreich bestanden haben.

4. Zusammenfassung

In diesem Artikel stellen wir das Problem der Typverwechslung 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 immer das Typattribut prüfen, bevor es vom/ins Konto liest/schreibt, das übergeben wird. Bleiben Sie dran, und wir werden in den kommenden Beiträgen mehr teilen.

Lesen Sie andere Artikel in dieser Reihe:

Über BlockSec

BlockSec ist ein wegweisendes Unternehmen für Blockchain-Sicherheit, 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 Massenadaption zu erleichtern. Zu diesem Zweck bietet BlockSec Dienstleistungen wie Sicherheitsaudits für Smart Contracts und EVM-Chains, die Phalcon-Plattform für die Sicherheitsentwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform für die Geldverfolgung und Untersuchung sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu navigieren.

Bis heute hat das Unternehmen über 300 namhafte 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, zweistellige Millionenbeträge erhalten.

Offizielle Website: https://blocksec.com/

Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam

Sign up for the latest updates
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.