Skip to main content

Wie sicher ist WebAssembly? 5 einzigartige Sicherheitsrisiken von WebAssembly

Artikel von

Marcelo Oliveira

feature Cloud Compliance

28. Juli 2023

0 Min. Lesezeit

WebAssembly, manchmal auch Wasm genannt, ist ein portables, maschinennahes Binärcode-Instruktionsformat, das in der virtuellen Maschine (VM) eines Webbrowsers ausgeführt wird. Damit können Entwickler leistungsstarken Code in verschiedenen Programmiersprachen schreiben, der parallel zu JavaScript ausgeführt wird. 

Entwickler setzen auf WebAssembly, weil sich damit komplexe Algorithmen beschleunigen, Gaming- und Multimedia-Anwendungen ermöglichen und eine sichere Sandbox-Umgebung für die Ausführung nicht vertrauenswürdigen Codes bereitstellen lassen. Bevor Sie WebAssembly einsetzen, sollten Sie jedoch unbedingt die Sicherheitsauswirkungen und Möglichkeiten zur Risikominderung berücksichtigen.

Die wichtigsten Sicherheitsrisiken von WebAssembly

Entwickler können viele moderne Programmiersprachen in WebAssembly kompilieren. Trotz seiner Vorteile kann WebAssembly herkömmliche Sicherheitsmaßnahmen umgehen und möglicherweise schädlichen Code im Browser ausführen. 

Sehen wir uns die speziellen Sicherheitsprobleme von WebAssembly genauer an und erstellen dazu eine Beispiel-App mit Blazor, dem Open-Source-Webframework. Mit Blazor können wir für unsere Webseiten C#-Code statt JavaScript schreiben. Der C#-Code wird in dynamische Bibliotheken (DLLs) und WebAssembly-Dateien (.wasm) umgewandelt, die im Browser des Clients ausgeführt werden.  

Voraussetzungen

Stellen Sie vor dem Start dieses Tutorials sicher, dass Sie Folgendes haben:

  • Laden Sie entweder Visual Studio oder VS Code herunter und installieren Sie das Programm. Diese integrierte Entwicklungsumgebung (IDE) verwenden Sie, um den WebAssembly-Code zu schreiben und auszuführen. Wenn Sie VS Code auswählen, laden Sie anschließend das .NET SDK und die C#-Erweiterung herunter und installieren Sie sie.

  • Installieren Sie die Visual Studio-Erweiterung oder die Snyk-Erweiterung für VS Code. Dieses Plugin scannt unseren WebAssembly-Code und führt eine Sicherheitsanalyse durch.

  • Laden Sie das Beispielprojekt herunter.

Beispielprojekt ausführen

Wenn Sie Visual Studio als IDE ausgewählt haben, öffnen Sie den Visual Studio Installer und aktivieren Sie die Option .NET WebAssembly Build Tools:

Komponentenliste des Software-Installers mit ausgewählten .NET WebAssembly Build Tools

Öffnen Sie das Menü Tools > Options > Snyk und dann General Settings. Klicken Sie anschließend auf die Schaltfläche Connect Visual Studio to Snyk.io.

Fenster mit Visual-Studio-Optionen und den allgemeinen Snyk-Einstellungen, darunter Token, benutzerdefinierter Endpunkt, Organisation und Verbindungseinstellungen

Wenn Sie VS Code als IDE ausgewählt haben, klicken Sie in der linken Symbolleiste auf das Snyk-Symbol. Klicken Sie anschließend auf Arbeitsbereich vertrauen und verbinden.

Visual Studio Code zeigt ein Snyk-Willkommensfenster an, in dem Nutzer aufgefordert werden, dem Arbeitsbereich zu vertrauen und eine Verbindung herzustellen, um eine erste Sicherheitsanalyse durchzuführen.

Führen Sie das Programm in Visual Studio oder VS Code aus, um die Beispiel-App zu starten. Sie sieht wie der folgende Screenshot aus und enthält den Titel „Human Resources“, ein Bild und Text.

Illustration von drei Mitarbeitenden unterschiedlicher Herkunft über einer Personal-Webseite mit Navigationslinks zu Startseite, Daten abrufen, Personalwesen und Marketing

Sicherheitsrisiko Nr. 1: Isolierung von WebAssembly-Modulen

Um die Sicherheit von Webanwendungen zu gewährleisten, die diese Technologie verwenden, müssen Sie WebAssembly-Module isolieren. Werden Module voneinander und von der Host-Umgebung isoliert, arbeiten sie unabhängig, ohne das Verhalten anderer Module oder der Host-Anwendung zu beeinträchtigen. Die Modulisolierung ist besonders wichtig, wenn nicht vertrauenswürdiger Code ausgeführt wird: Sie verhindert, dass schädlicher Code auf sensible Daten oder Ressourcen zugreift.

Zwei bewährte Methoden zur Modulisolierung sind Sandbox-Isolierung und Kompartimentierung.

Bei der Sandbox-Isolierung wird jedes Modul in einer separaten, isolierten Umgebung ausgeführt, die den Zugriff auf das Host-System und andere Module einschränkt. Das folgende Bild zeigt ein Projekt mit zwei WebAssembly-Modulen (Finance und Human Resources). Beim Kompilieren und Bereitstellen des Projekts im Webbrowser werden die WebAssembly-Module in einer Sandbox-Umgebung ausgeführt, die von der Host-Laufzeitumgebung getrennt ist.

Visual Studio Solution Explorer mit der SnykWebAssembly-Lösung und den Projekten Core, ModuleHumanResources und ModuleMarketing.

Bei der Kompartimentierung werden die Host-Anwendung und ihre Module in separate Bereiche unterteilt, von denen jeder über eigene Ressourcen und Zugriffsrechte verfügt. 

Sowohl Sandbox-Isolierung als auch Kompartimentierung schaffen eine sichere Umgebung, in der nicht vertrauenswürdiger Code ausgeführt werden kann, ohne die Sicherheit des Host-Systems oder anderer Module zu gefährden.

Verwenden Sie als Nächstes die Visual Studio Code-Erweiterung von Snyk, um zu prüfen, ob WebAssembly-Code anfällig ist. Öffnen Sie das Menü Extensions > Snyk und klicken Sie auf Scan.

Screenshot des Erweiterungsmenüs eines Code-Editors mit Snyk-Optionen zum Scannen, Stoppen, Bereinigen und für Einstellungen

Snyk analysiert die Datei und erkennt bekannte WebAssembly-Probleme mit der Codequalität sowie Schwachstellen im Zusammenhang mit Open-Source- und Code-Sicherheit. Werden Probleme oder Schwachstellen gefunden, stellt Snyk Details und Empfehlungen zur Behebung bereit.

Snyk-Dashboard mit null Open-Source-Schwachstellen, Code-Security-Schwachstellen und Codequalitätsproblemen

Sicherheitsrisiko Nr. 2: Lineares Speichermodell von WebAssembly

Das lineare Speichermodell ist eine Technik zur Speicheradressierung, bei der der Speicher in einem einzigen zusammenhängenden Adressraum organisiert wird. Dadurch kann die Verarbeitungseinheit direkt und sequenziell auf Speicheradressen zugreifen. Das folgende Bild zeigt ein Objekt, das von JavaScript- und WebAssembly-Code gemeinsam genutzt wird und Speicherplatz im linearen Speicher belegt.

Diagramm, das zeigt, wie JavaScript und WASM Objekte über gemeinsam genutzte, hervorgehobene Bereiche des linearen Speichers austauschen.

Mit dem linearen Speichermodell von WebAssembly können Module einen zusammenhängenden Speicherblock reservieren und darauf zugreifen – ähnlich wie bei einem herkömmlichen Array. Dieses Modell ermöglicht zwar eine schnelle und effiziente Speicherverwaltung in WebAssembly-Anwendungen, birgt aber auch Sicherheitsrisiken.

Greift ein Modul beispielsweise außerhalb des ihm zugewiesenen Bereichs auf den Speicher zu, könnte es den Speicher anderer Module oder des Host-Systems beschädigen. Das kann zu einem Absturz oder einer Sicherheitsverletzung führen.

Mit den folgenden bewährten Methoden können Sie die Sicherheitsrisiken des linearen Speichermodells in WebAssembly-Anwendungen mindern: 

  • Verwenden Sie eine Bereichsprüfung, damit Module nur auf den ihnen zugewiesenen Speicher zugreifen. 

  • Vermeiden Sie unsichere Funktionen, um Schwachstellen durch Speicherbeschädigung zu verhindern. 

  • Implementieren Sie Speicherschutzmechanismen wie die Randomisierung des Adressraumlayouts (ASLR) und die Datenausführungsverhinderung (DEP).

Sicherheitsrisiko Nr. 3: JIT-Kompilierung von WebAssembly

Bei der Just-in-Time-Kompilierung (JIT) von WebAssembly wird Wasm-Code zur Laufzeit in Maschinencode kompiliert, statt vorab. Das bringt zwar erhebliche Leistungsvorteile, birgt aber auch potenzielle Sicherheitsrisiken.

Die dynamische Natur der JIT-Kompilierung erschwert es, Angriffe zu erkennen und zu verhindern. Angreifer können schädlichen Code in den Kompilierungsprozess einschleusen und in der Host-Umgebung ausführen. So könnte ein Hacker beispielsweise eine harmlos wirkende Konstante in einer höheren Programmiersprache erstellen:

var a = (0x11223344^0x44332211^0x44332211^ ...);

Anschließend wandelt der JIT-Compiler diese Anweisung in eine Reihe nativer x86-Maschinencode-Anweisungen um:

0000:  b8 44 33 22 11      mov $0x11223344,%eax    mov eax,0x11223344
0005:  35 11 22 33 44      xor $0x44332211,%eax    xor eax,0x44332211
000a:  35 11 22 33 44      xor $0x44332211,%eax    xor eax,0x44332211

Der Angreifer nutzt einen bekannten Fehler aus, um den Ausführungszeiger auf die Adresse 0001 zu verschieben. Dadurch wird eine Reihe schädlicher Anweisungen ausgeführt, die sorgfältig erstellt und in die obige Konstante eingeschleust wurden.

Diagramm, das zeigt, wie ein Angreifer eine Konstante in WebAssembly einschleust und die JIT-Kompilierung ausnutzt, um den Ausführungspointer zu verschieben und bösartigen Code auszuführen.

Um die Sicherheitsrisiken der JIT-Kompilierung in WebAssembly-Anwendungen zu mindern, sollten Sie die folgenden bewährten Methoden für die Verwaltung des Kompilierungsprozesses anwenden:

  • Verwenden Sie die Ahead-of-Time-Kompilierung (AOT), um Wasm-Code vor der Laufzeit in Maschinencode zu kompilieren. Dadurch entfallen die Risiken der dynamischen Kompilierung. 

  • Installieren Sie Sicherheitspatches für bekannte Schwachstellen in JIT-Compilern.

Sicherheitsrisiko Nr. 4: Web-APIs und Cross-Site-Scripting (XSS)

WebAssembly kann mit Web-APIs interagieren, um auf Ressourcen und Daten von Webbrowsern, Servern und anderen Plattformen zuzugreifen. Diese Interaktionen können jedoch Sicherheitsrisiken wie Cross-Site-Scripting-Angriffe (XSS) mit sich bringen. Bei XSS-Angriffen schleusen Hacker schädlichen Code in Webseiten oder Anwendungen ein. Später führen Nutzer diesen möglicherweise unwissentlich aus, wodurch unbefugter Zugriff oder Datendiebstahl ermöglicht wird.

Diagramm eines XSS-Angriffs: Ein Angreifer schleust ein Skript in eine Webanwendung ein. Dieses wird für die Nutzer ausgeführt und sendet ihre sensiblen Daten an den Angreifer.

Um die Risiken von XSS-Angriffen zu mindern, sollten Sie bewährte Methoden zur Eingabevalidierung und Ausgabekodierung anwenden:

  • Bei der Eingabevalidierung werden Nutzereingaben auf potenziell schädlichen Code oder Zeichen geprüft und alle Eingaben abgelehnt, die bestimmte Kriterien nicht erfüllen. 

  • Bei der Ausgabekodierung werden Nutzereingaben oder -ausgaben kodiert, um die Ausführung schädlichen Codes zu verhindern. 

Verwenden Sie außerdem HTTPS, um Daten bei der Übertragung zwischen Server und Client zu verschlüsseln und Angreifer daran zu hindern, sie abzufangen oder zu verändern.

Sicherheitsrisiko Nr. 5: Unsichere Bereitstellung von WebAssembly-Inhalten

Eine sichere Bereitstellung von Inhalten ist für WebAssembly-Anwendungen entscheidend. Sie stellt sicher, dass Nutzer authentischen, unveränderten Code über einen vertrauenswürdigen Kanal erhalten. Eine unsichere Bereitstellung kann Sicherheitsrisiken wie Man-in-the-Middle-Angriffe (MITM) und Code-Manipulation mit sich bringen. 

Bei MITM-Angriffen fangen Angreifer Code ab und verändern ihn, während er zwischen Server und Client übertragen wird. So können Angreifer schädlichen Code in die Anwendung einschleusen, der anschließend vom Browser oder der Wasm-Laufzeitumgebung ausgeführt wird.

Diagramm eines Man-in-the-Middle-Angreifers, der Verbindungen zwischen Nutzern und einer Webanwendung abfängt.

Befolgen Sie diese bewährten Methoden, um die Bereitstellung von Inhalten in WebAssembly-Anwendungen abzusichern:

  • Verwenden Sie HTTPS, um Daten zwischen Server und Client zu verschlüsseln und eine sichere, unveränderte Codeübertragung zu gewährleisten.

  • Prüfen Sie mithilfe von Integritätsprüfungen wie Prüfsummen oder digitalen Signaturen, ob der Code authentisch ist. 

  • Implementieren Sie Zugriffskontrollen, damit nur berechtigte Nutzer auf den Code zugreifen können.

Sicher entwickeln und bereitstellen

Entwickler haben WebAssembly begeistert angenommen – eine Technologie, mit der sich leistungsstarke Anwendungen für Webbrowser schreiben lassen. Die Vorteile von WebAssembly gehen jedoch mit erheblichen Sicherheitsrisiken einher.

In diesem Artikel haben wir einige Sicherheitsprobleme von WebAssembly behandelt: unzureichende Modulisolierung, fehlender Schutz im linearen Speichermodell, Schwachstellen in JIT-Compilern, Cross-Site-Scripting-Angriffe und die unsichere Bereitstellung von WebAssembly-Inhalten.

Glücklicherweise gibt es bewährte Methoden, mit denen sich die von WebAssembly verursachten Schwachstellen mindern lassen. Wenn Sie diese Sicherheitsmaßnahmen befolgen, schützen Sie Ihre Nutzer und WebAssembly-Apps.

Um Ihre Systeme und Nutzer zu schützen, ist es außerdem wichtig, über aktuelle Sicherheitsbedrohungen für WebAssembly informiert zu bleiben. Entwicklungstools helfen dabei. Die Snyk-Plattform pflegt beispielsweise einen umfangreichen Katalog bekannter Schwachstellen und bietet konkrete Handlungsempfehlungen zur Risikominderung. Mit Tools wie Snyk Code und Snyk Open Source erkennen und beheben Sie Code-Sicherheitsprobleme schnell. Erstellen Sie noch heute kostenlos ein Konto.

Sichern Sie Ihre JavaScript-Apps ab sofort

Finden und beheben Sie JavaScript-Schwachstellen kostenlos mit Snyk. 

Keine Kreditkarte erforderlich.

Oder registrieren Sie sich mit Azure AD Docker ID Bitbucket

Mit der Nutzung von Snyk erklären Sie sich mit unseren Richtlinien einverstanden, einschließlich unserer Nutzungsbedingungen und Datenschutzerklärung.

Weiterlesen

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Warum KI-Coding-Agenten immer wieder fehlerhafte Zugriffskontrollen schreiben

KI-Coding-Agenten können Autorisierungslogik erzeugen, die kompiliert und die Prüfung besteht, dabei aber die Daten eines Mandanten für einen anderen offenlegt. Erfahren Sie, warum fehlerhafte Zugriffskontrollen schwer zu erkennen sind und wie Sie sie verhindern.