An Analysis of Modern Web Security Vulnerabilities Inside WebAssembly Applications

Diese Arbeit zeigt auf, dass binäre Sicherheitslücken in WebAssembly-Modulen herkömmliche Web-Sicherheitsmechanismen untergraben und zu Angriffen wie SQL-Injection führen können, und bietet darauf aufbauend defensive Strategien zur Risikominderung.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschungsergebnisse, als würden wir sie an einem Kaffeehaustisch diskutieren – ohne technisches Fachchinesisch.

Das Grundproblem: Der schnelle, aber ungeschützte Gast

Stell dir eine moderne Webseite wie ein großes, luxuriöses Restaurant vor.
Bis vor kurzem wurde das Essen (die Logik der Webseite) fast ausschließlich von einem einzigen Koch zubereitet, der JavaScript heißt. Er ist langsam, aber er kennt die Regeln des Restaurants genau und ist sehr vorsichtig.

Dann kam WebAssembly (WASM) ins Spiel. WASM ist wie ein Super-Koch, der aus einem anderen Land kommt. Er kann Gerichte (Rechnungen, Spiele, Bildbearbeitung) unglaublich schnell zubereiten, viel schneller als der alte Koch. Deshalb nutzen ihn heute große Restaurants wie Google Earth oder Figma.

Das Problem: Dieser Super-Koch kommt aus einer Welt, in der die Sicherheitsregeln anders sind. Er ist extrem schnell, aber er trägt keinen Sicherheitsgurt und hat keinen Bodyguard. Wenn er einen Fehler macht, kann er das ganze Restaurant in Brand stecken, ohne dass die Feuerwehr (der Browser) sofort eingreifen kann.

Die Forscher haben herausgefunden: Auch wenn der Super-Koch (WASM) in einem sicheren Raum (dem Browser) arbeitet, kann ein kleiner Fehler in seiner Zubereitung dazu führen, dass die Gäste (die Webseite) vergiftet werden.

---

Wie funktioniert der Angriff? (Die drei Szenarien)

Die Forscher haben drei verschiedene Wege untersucht, wie ein kleiner Fehler im Code des Super-Kochs zu einem großen Chaos im Restaurant führt.

1. SQL-Injection: Der falsche Zettel im Teller

• Die Situation: Der Koch soll eine Bestellung an die Küche (die Datenbank) weiterleiten. Normalerweise schreibt er die Bestellung auf einen Zettel und gibt sie ab.
• Der Fehler: Stell dir vor, der Koch hat einen zerbrechlichen Teller (einen Puffer im Speicher). Wenn ein Gast zu viel Essen auf den Teller legt (zu viele Daten), läuft es über den Rand und verschmutzt den Zettel daneben.
• Das Chaos: Der Koch hat eigentlich einen sicheren Zettel ("Zeige mir nur meine Bestellung"). Aber durch das Überlaufen des Tellers wird dieser Zettel überschrieben. Plötzlich steht darauf: "Zeige mir die Geheimnisse aller Gäste!"
• Die Lehre: Selbst wenn das Restaurant sagt "Wir nutzen nur sichere Zettel", kann der Koch den Zettel trotzdem manipulieren, wenn er im Inneren des Kochbereichs einen Fehler macht.

2. SSTI (Server-Side Template Injection): Der vergiftete Brief

• Die Situation: Der Koch schreibt einen Brief (eine Vorlage) für den Gast. Er füllt eine Lücke mit einem zufälligen Code (einem "Nonce"), damit der Brief sicher aussieht.
• Der Fehler: Der Koch hat wieder einen zerbrechlichen Teller. Ein böser Gast gibt ihm zu viel Essen. Das Essen läuft über und verändert den Text des Briefes, den der Koch gerade schreibt.
• Das Chaos: Statt nur einen zufälligen Code zu schreiben, schreibt der Koch jetzt versehentlich einen Befehl hinein: "Führe diesen bösen Code aus!" Weil das Restaurant dem Koch blind vertraut ("Der Koch macht das ja richtig"), führt der Brief diesen Befehl aus.
• Die Lehre: Man darf dem Koch nicht blind vertrauen. Auch wenn er aus einem sicheren Raum kommt, kann sein Output manipuliert sein.

3. XS-Leaks: Das Lauschen durch die Zeit

• Die Situation: Ein Gast möchte herausfinden, was ein anderer Gast in seinem privaten Notizbuch steht, ohne den Raum zu betreten (was verboten ist).
• Der Fehler: Der Koch hat einen zerbrechlichen Teller. Der böse Gast füllt ihn so, dass der Koch eine sehr schwierige Rechenaufgabe bekommt (z. B. ein kompliziertes Muster suchen).
• Das Chaos: Der Koch versucht, das Muster zu lösen.
  • Wenn das Muster nicht passt, ist er schnell fertig (1 Sekunde).
  • Wenn das Muster passt, muss er viel länger rechnen (10 Sekunden), weil er jeden Buchstaben prüfen muss.
  • Der böse Gast misst die Zeit. Wenn der Koch lange braucht, weiß er: "Aha! Das Geheimwort beginnt mit 'A'!" Dann probiert er 'B', 'C' usw.
• Die Lehre: Selbst wenn der Koch nichts "herausgibt", verrät ihm die Zeit, die er braucht, alles. Das ist wie jemand, der an der Tür steht und durch das Klopfen hört, wie lange jemand im Inneren braucht, um die Tür zu öffnen.

---

Warum ist das so gefährlich?

Früher dachten viele: "WASM ist sicher, weil es im Browser isoliert ist."
Die Forscher sagen: Nein.

Stell dir vor, du hast eine Sicherheitsmauer um dein Haus gebaut. Aber du hast einen Gast, der eine zerbrechliche Vase in der Hand hält. Wenn der Gast stolpert und die Vase fällt, zerbricht sie nicht nur, sondern die Scherben fliegen durch die Wand und treffen die Gäste im Wohnzimmer.

Die Sicherheitsmauer (der Browser) hält den Gast fest, aber sie kann nicht verhindern, dass der Gast durch seine eigene Unvorsichtigkeit (Fehler im Code) die Sicherheit des Hauses (der Webseite) untergräbt.

Was können wir tun? (Die Lösungen)

Die Forscher geben einige einfache Ratschläge, wie man das Restaurant sicherer macht:

1. Vertraue niemandem blind: Auch wenn der Gast (WASM) aus dem "sicheren Raum" kommt, prüfe alles, was er zurückgibt. Was er sagt, ist nicht automatisch wahr.
2. Grenzen setzen: Gib dem Gast nur das Minimum an Werkzeugen. Wenn er keine Vase braucht, gib ihm keine.
3. Sicherheitsgurte anlegen: Man kann den Super-Koch zwingen, einen Sicherheitsgurt zu tragen (Compiler-Einstellungen). Das macht ihn etwas langsamer, aber er stolpert viel seltener.
4. Doppelt prüfen: Wenn der Gast Daten vom einen Raum in den anderen bringt, prüfe sie zweimal. Einmal im Raum des Kochs und einmal im Raum des Restaurants.

Fazit

WebAssembly ist ein genialer Super-Koch, der unsere Webseiten schneller macht. Aber wie jeder Super-Koch, der aus einer anderen Welt kommt, bringt er auch alte Fehler mit. Wenn wir diese Fehler ignorieren, können sie dazu führen, dass Hacker nicht nur den Koch, sondern das ganze Restaurant kaputt machen.

Die Botschaft ist klar: Sicherheit ist keine Option, die man einfach "einschaltet". Man muss sie von Anfang an mitdenken, auch bei den schnellsten Technologien.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „An Analysis of Modern Web Security Vulnerabilities Inside WebAssembly Applications" auf Deutsch:

1. Problemstellung

WebAssembly (WASM) hat sich als Standard für die Ausführung hochperformanter, ressourcenintensiver Anwendungen im Web etabliert und ersetzt zunehmend JavaScript in diesem Bereich. Obwohl WASM eine isolierte Laufzeitumgebung bietet, fehlt es den daraus generierten Binärdateien oft an den üblichen Low-Level-Schutzmechanismen, die bei nativen C/C++-Anwendungen Standard sind (z. B. Stack Canaries, ASLR, Safe Unlinking).

Das Kernproblem, das diese Arbeit adressiert, ist die Lücke zwischen der Sicherheitsebene des Binärcodes und der Sicherheitsebene der Webanwendung. Forscher haben zwar bereits gezeigt, dass klassische Binärfehler wie Pufferüberläufe (Buffer Overflows) und Use-After-Free (UAF) in WASM-Modulen ausnutzbar sind, um die Kontrolle über den Programmfluss zu übernehmen. Es fehlte jedoch an Untersuchungen, die aufzeigen, wie diese Low-Level-Fehler zu klassischen Web-Sicherheitslücken führen können. Die Autoren argumentieren, dass unsichere WASM-Module die Sicherheit der gesamten Webanwendung kompromittieren können, selbst wenn die Webanwendung selbst korrekt implementiert ist.

2. Methodik

Die Autoren entwickelten eine reproduzierbare Methodik, um die Kette von Binärfehlern zu Webangriffen nachzuvollziehen.

• Auswahl der Binärfehler: Basierend auf früheren Arbeiten (McFadden, Lehmann, Massidda) konzentrierten sie sich auf vier spezifische Schwachstellen, die Schreib- oder Lesezugriffe auf den Speicher ermöglichen:
  • Stack-basierte Pufferüberläufe (Arbitrary Write).
  • Use After Free (Arbitrary Write).
  • Integer-Overflows (Arbitrary Write).
  • Unkontrollierte Formatstrings (Arbitrary Read/Write).
• Auswahl der Web-Schwachstellen: Sie kategorisierten die Angriffe in „Direkt/Kettenreaktion" und „Blind/Nicht-blind" und wählten drei Szenarien aus:
  • SQL-Injection (SQLi): Direkter, nicht-blinder Angriff.
  • Server-Side Template Injection (SSTI): Kettenreaktion, nicht-blind.
  • Cross-Site Leaks (XS-Leaks): Direkter, blinder Angriff (via Timing).
• Experimentelles Setup: Es wurden Proof-of-Concept (PoC) Webdienste entwickelt, die einen Node.js/Express-Frontend-Server mit einem in C geschriebenen und via Emscripten kompilierten WASM-Backend verbinden. Das Backend interagiert mit einer SQLite-Datenbank, Template-Engines (Pug) oder Regex-Engines (PCRE2).

3. Wichtige Beiträge

Die Arbeit leistet folgende wesentliche Beiträge:

1. Analyse der Angriffsvektoren: Sie zeigt auf, wie spezifische Speicherfehler (Stack-Overflows, UAF, Integer-Overflows, Formatstrings) genutzt werden können, um SQLi, SSTI und XS-Leaks zu initiieren.
2. Verknüpfung von Ebenen: Es wird eine Methodik vorgestellt, die Binärcode-Fehler direkt mit Auswirkungen auf die Web-Ebene verknüpft, was bisher kaum untersucht wurde.
3. Reproduzierbare PoCs: Die Autoren stellen vollständige, reproduzierbare Beispiele (inkl. Docker-Container und Skripte) bereit, die demonstrieren, wie ein Binärfehler eine Web-Sicherheitslücke ausnutzt (z. B. SQLi durch einen überlaufenen Puffer, der eine vorbereitete Abfrage überschreibt).
4. Sicherheitsleitfaden: Sie identifizieren unterschätzte Angriffsflächen und bieten konkrete Empfehlungen für Entwickler zur Absicherung von WASM-Modulen.

4. Ergebnisse und Experimente

A. SQL-Injection (SQLi)

• Mechanismus: Selbst bei Verwendung von vorbereiteten Statements (Prepared Statements) kann ein Angreifer die SQL-Abfrage manipulieren, wenn der Binärcode fehlerhaft ist.
• Beispiel: Ein Stack-basierter Pufferüberlauf kann den Speicherbereich überschreiben, in dem die SQL-Abfrage-String-Variable liegt, bevor sie an die Datenbank gesendet wird.
• Integer-Overflow: Ein besonders gefährlicher Vektor ist die Diskrepanz zwischen JavaScripts 64-Bit-Floats und C's 32-Bit-Ints. Ein Wert wie $2^{32}-1$ wird im JS-Frontend als gültig (nicht 0) geprüft, überläuft jedoch im WASM-Modul zu 0 und greift so auf gesperrte Datensätze zu.
• Ergebnis: Vorbereitete Statements bieten keinen Schutz, wenn die Abfrage selbst im Speicher manipuliert werden kann.

B. Server-Side Template Injection (SSTI)

• Mechanismus: Ein Angreifer manipuliert die Ausgabe eines WASM-Moduls (z. B. einen Nonce-Wert), sodass diese Template-Syntax (z. B. #{7*7}) enthält. Das Frontend vertraut dieser Ausgabe blind und rendert sie, was zur Ausführung von beliebigem Code führt.
• Vektoren:
  • Stack-Overflow: Überschreiben der Nonce-Variable auf dem Stack.
  • Formatstrings: Überschreiben statischer Speicherbereiche.
  • Use After Free: Manipulation des Heap-Speichers, um eine freigegebene Variable mit schädlichem Inhalt neu zu belegen.
• Ergebnis: Die Annahme, dass WASM-Ausgaben vertrauenswürdig sind, ist ein kritischer Fehler.

C. Cross-Site Leaks (XS-Leaks)

• Mechanismus: Ein „Blinder" Angriff, bei dem keine direkte Datenleakage stattfindet, sondern Informationen über Antwortzeiten (Timing Attacks) extrahiert werden.
• Szenario: Ein WASM-Modul führt Regex-Suchen durch. Ein Angreifer nutzt einen Binärfehler (z. B. Pufferüberlauf), um ein bösartiges Regex-Muster (ReDoS-Vektor) in den Speicher zu injizieren.
• Ausnutzung: Durch Messung der Antwortzeit kann der Angreifer ableiten, ob das Regex-Muster erfolgreich war (lange Verzögerung) oder nicht (sofortige Antwort). So können schrittweise geheime Benutzerdaten rekonstruiert werden.
• Ergebnis: Auch ohne direkten Zugriff auf den DOM oder die Daten kann über Timing-Side-Channels sensibler Inhalt ausgelesen werden. Formatstrings erwiesen sich hier als instabil, während Pufferüberläufe und UAF funktionsfähig waren.

D. Schwierigkeitsgrad der Ausnutzung

• Pufferüberläufe: Relativ einfach auszunutzen, da die Größe des Puffers oft durch Trial-and-Error erraten werden kann.
• Use After Free: Schwieriger, erfordert genaues „Heap Shaping", aber machbar.
• Formatstrings: Am schwierigsten, da sie präzise Speicheradressen benötigen und oft zu Abstürzen führen, bevor sie erfolgreich sind.

5. Bedeutung und Empfehlungen

Die Studie zeigt, dass die Sicherheit von Webanwendungen nicht mehr nur auf der Ebene von JavaScript und Server-Logik betrachtet werden darf. Unsichere Binärmodule (C/C++ zu WASM) stellen eine direkte Bedrohung für die Web-Sicherheit dar, da sie etablierte Schutzmechanismen (wie Prepared Statements) umgehen können.

Empfohlene Gegenmaßnahmen (Best Practices):

1. Vertrauenswürdigkeit: Alle Daten, die die Grenze zwischen JavaScript und WASM überqueren, müssen als unvertrauenswürdig behandelt und validiert werden (Typen, Bereiche, String-Längen).
2. Schnittstellenminimierung: Exportierte Funktionen und Speicherbereiche sollten auf das absolut Notwendige reduziert werden, um die Angriffsfläche zu verringern.
3. Compiler-Härtung: Nutzung von Compiler-Optionen (z. B. in Emscripten) für Stack-Smashing-Erkennung und Out-of-Bounds-Checks, auch wenn dies einen Performance-Overhead verursacht.
4. Defense in Depth: Auch wenn WASM unsicher ist, sollten Web-Standard-Schutzmaßnahmen (Input Sanitization, Output Encoding) weiterhin auf der Web-Ebene angewendet werden.

Fazit: Die Arbeit demonstriert, dass WASM keine „Sicherheitsgarantie" ist, sondern eine neue Angriffsfläche eröffnet, die Low-Level-Speicherfehler in hochrangige Web-Angriffe übersetzt. Entwickler müssen WASM-Module mit derselben Sicherheitsstrenge behandeln wie native Anwendungen.