An Analysis of Modern Web Security Vulnerabilities Inside WebAssembly Applications

Dit artikel analyseert hoe binaire kwetsbaarheden in WebAssembly-modules, zoals bufferoverlopen en use-after-free-fouten, kunnen leiden tot webveiligheidsproblemen zoals SQL-injecties en XS-Leaks, en biedt daarvoor best practices en verdedigingsstrategieën.

De kern

Stel je voor dat het internet een enorme, drukke stad is. Vroeger werden alle gebouwen (websites) gebouwd met JavaScript. Dit is als een flexibele, maar soms wat trage en onhandige bouwstijl. Alles was veilig, maar het kon niet zwaar werk verzetten.

Toen kwam WebAssembly (WASM) op het toneel. Je kunt WASM zien als een superkrachtige, snelle robot die je in de stad plaatst. Deze robot kan zware taken uitvoeren (zoals 3D-grafiek of videobewerking) die de normale bouwstijl niet aankan. Bedrijven als Google en Figma gebruiken deze robots al.

Het probleem?
Deze robots zijn niet gebouwd door de stadswachters (de webontwikkelaars), maar door oude, strenge ingenieurs (programmeurs in C of C++). En die oude ingenieurs hebben een slechte gewoonte: ze bouwen soms geheime, onveilige deurtjes in hun robots.

Dit paper (onderzoek) waarschuwt: "Pas op! Als je die robot een foutje laat maken, kan dat de hele stad in gevaar brengen, zelfs als de robot zelf niet direct met de burgers praat."

Hier is hoe dat werkt, vertaald naar alledaagse situaties:

1. De "Geheime Deurtjes" (Binary Vulnerabilities)

De robots hebben interne fouten, zoals:

• Buffer Overflow: Stel je een robot voor die een briefje moet lezen. Als je de robot een briefje geeft dat te lang is, stroomt de tekst over naar het volgende vakje. In plaats van alleen je naam te lezen, leest de robot nu ook de instructies die daarachter staan en doet hij iets wat jij wilt.
• Use After Free: De robot haalt een oude, kapotte stoel weg (vrijgeven van geheugen), maar vergeet de sleutel eruit te halen. Jij plaatst een nieuwe, giftige stoel op die plek. Als de robot later weer naar die plek kijkt, denkt hij dat het nog de oude stoel is, maar hij zit nu op je giftige stoel.

2. Hoe de Robot de Stad (Website) in gevaar brengt

Het onderzoek laat zien dat deze interne robot-fouten leiden tot drie grote problemen voor de website:

A. De "Valse Bestelling" (SQL Injection)

• De situatie: De robot moet een bestelling naar een database sturen (bijv. "Haal klant 100 op").
• De aanval: Door de robot-fout (zoals de te lange brief), kan een hacker de tekst van de bestelling veranderen voordat de robot hem verstuurt.
• Het resultaat: In plaats van "Haal klant 100", stuurt de robot nu: "Haal alle klanten en geef hun wachtwoorden door". De website denkt: "Oh, dit is een normale bestelling van de robot," en geeft alles weg. De beveiliging (voorbereide statements) werkt niet meer omdat de robot de opdracht zelf heeft vervalst.

B. De "Vervuilde Brief" (Server-Side Template Injection)

• De situatie: De robot maakt een veiligheidscode (een 'nonce') die de website gebruikt om een pagina te bouwen.
• De aanval: De hacker gebruikt een robot-fout om die veiligheidscode te vervalsen. In plaats van een willekeurig getal, komt er nu een opdracht in: "Trek een streep door de pagina en voer mijn code uit."
• Het resultaat: De website vertrouwt de robot blindelings. Als de robot een giftige code terugstuurt, bouwt de website die code direct in. Het is alsof je een bezorger vertrouwt die je huisbrieven inlevert, maar die bezorger plotseling je eigen huis in breekt en je meubels verplaatst.

C. De "Luisterende Muur" (XS-Leaks / Timing Attacks)

• De situatie: De robot zoekt naar een geheim (bijv. een wachtwoord) in zijn geheugen.
• De aanval: De hacker kan de robot niet direct zien wat hij doet (de robot zit in een gesloten kamer). Maar de hacker kan wel luisteren naar hoe lang het duurt.
• Het resultaat: Als de robot een moeilijk woord moet raden, duurt het even. Als het woord niet klopt, is het snel. Door duizenden keren te proberen en te kijken of de robot "traag" of "snel" reageert, kan de hacker het wachtwoord letterlijk opbouwen, letter voor letter. Het is alsof je een slot op een deur probeert te kraken door te luisteren naar het geluid van het slot: als het klik lang duurt, weet je dat je op de juiste weg bent.

3. Waarom is dit gevaarlijk?

Vroeger dachten ontwikkelaars: "WASM is veilig, het zit in een zandbak (sandbox) en kan niets doen."
Dit onderzoek zegt: "Nee, dat is niet waar."

Als de robot (WASM) een fout heeft, kan hij de regels van de zandbak omzeilen. Hij kan de website dwingen om fouten te maken die normaal onmogelijk zouden zijn. Het is alsof je een onveilige machine in je keuken zet; als die machine een fout maakt, kan hij je hele huis in brand steken, niet alleen de keuken.

4. Wat moeten we doen? (De Oplossing)

De auteurs geven een paar simpele adviezen om de stad veilig te houden:

1. Vertrouw niemand: Behandel alles wat de robot naar de website stuurt als verdacht. Controleer het dubbel, ook al komt het van "binnen".
2. Maak de robot slimmer: Gebruik speciale gereedschappen (compiler-opties) die de robot dwingen om veilig te bouwen. Dit maakt de robot misschien iets trager, maar dan breekt hij niet zomaar.
3. Beperk de macht: Geef de robot alleen de tools die hij echt nodig heeft. Als hij geen toegang heeft tot de database, kan hij die ook niet stelen.

Kortom: WebAssembly is een krachtige tool, maar als je de onderliggende code (de robot) niet goed bouwt, kan die kracht de hele website platleggen. We moeten stoppen met denken dat "WASM = Veilig" en gaan denken aan "WASM = Krachtig, maar met strikte bewaking".

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "An Analysis of Modern Web Security Vulnerabilities Inside WebAssembly Applications" in het Nederlands.

Probleemstelling

De adoptie van WebAssembly (WASM) is sterk toegenomen omdat het complexe, rekenintensieve applicaties (zoals Figma en Google Earth) snel en efficiënt in de browser kan uitvoeren. Hoewel WASM een veilige sandbox-omgeving biedt ten opzichte van JavaScript, mist het veel van de traditionele laag-niveau beveiligingsmechanismen die in native C/C++-applicaties voorkomen, zoals stack-canaries, ASLR (Address Space Layout Randomization) en safe unlinking.

Het centrale probleem dat dit artikel adresseert, is dat kwetsbaarheden op het niveau van de binary (zoals buffer overflows en use-after-free) in WASM-modules niet alleen leiden tot klassieke exploitaties van het binary zelf, maar ook onverwachte web-security kwetsbaarheden kunnen veroorzaken. Onderzoekers hebben tot nu toe weinig aandacht besteed aan hoe laag-niveau bugs in gecompileerde WASM-code de integriteit van de omringende webapplicatie kunnen ondermijnen, waardoor aanvallen mogelijk worden die traditionele webbeveiligingsmaatregelen omzeilen.

Methodologie

De auteurs hebben een reproduceerbare methodologie ontwikkeld om de link tussen binary-kwetsbaarheden en web-layer impact te demonstreren. De aanpak omvatte:

1. Selectie van Kwetsbaarheden:
   • Binary-niveau: Ze focusten op vier specifieke kwetsbaarheden die "arbitrary read/write" primitives bieden: Stack-based Buffer Overflow, Use After Free (UAF), Integer Overflow en Uncontrolled Format Strings.
   • Web-niveau: Ze classificeerden web-kwetsbaarheden in twee categorieën: Direct/Chained (waarbij de output van de WASM-module de web-applicatie beïnvloedt) en Blind/Not-blind (waarbij er wel of geen directe output is).
2. Opzet van Proof-of-Concepts (PoC's):
   • Ze bouwden kwetsbare webdiensten met een Node.js/Express frontend en een WASM-backend (gecompileerd uit C met Emscripten).
   • Ze simuleerden scenario's waarbij een aanvaller een binary-kwetsbaarheid exploiteert om de output van de WASM-module te manipuleren, wat vervolgens leidt tot web-kwetsbaarheden.
3. Doelwitte Web-kwetsbaarheden:
   • SQL Injection (SQLi): Direct, niet-blind.
   • Server-Side Template Injection (SSTI): Gekoppeld (chained), niet-blind.
   • Cross-Site Leaks (XS-Leaks): Direct, blind (gebaseerd op timing-aanvallen via ReDoS).

Belangrijkste Bijdragen

1. Mapping van Binary naar Web: Het artikel toont aan dat C-achtige bugs in WASM niet alleen leiden tot code-executie, maar ook tot specifieke web-aanvallen zoals SQLi, SSTI en XS-Leaks.
2. Reproduceerbare PoC's: De auteurs hebben een complete set van PoC's, scripts en Docker-containers gepubliceerd die demonstreren hoe memory-safety bugs worden omgezet in high-impact web-aanvallen.
3. Nieuwe Aanvalsoppervlakken: Ze identificeren ondergewaardeerde aanvalsoppervlakken, zoals hoe de geheugenlay-out en de import/export van WASM-modules de webbeveiliging beïnvloeden.
4. Verdedigingsstrategieën: Het biedt concrete richtlijnen voor ontwikkelaars om risico's te mitigeren, variërend van compiler-opties tot runtime-hardening.

Resultaten en Experimentele Bevindingen

De experimenten toonden aan dat binary-exploitatie succesvol kan leiden tot web-exploitatie, zelfs met bestaande beveiligingsmaatregelen zoals prepared statements:

• SQL Injection (SQLi):

  • Zelfs met prepared statements is een applicatie kwetsbaar als de query-string zelf op de stack staat en kan worden overschreven via een Buffer Overflow.
  • Integer Overflows bleken gevaarlijk: een waarde die in JavaScript (64-bit float) als veilig wordt gezien (bijv. 2^32 - 1), kan in de C-WASM module (32-bit int) overlopen naar 0, waardoor beveiligde records worden vrijgegeven.
  • Use After Free (UAF) kon worden gebruikt om vrijgegeven query-strings te herschrijven met kwaadaardige SQL-injecties.

• Server-Side Template Injection (SSTI):

  • Webapplicaties vertrouwen vaak op de output van WASM-modules (bijv. een gegenereerde nonce). Als een Buffer Overflow of Format String kwetsbaarheid deze nonce manipuleert tot template-syntax (bijv. #{7*7}), voert de template-engine (zoals Pug) willekeurige code uit.
  • Dit toont aan dat de "vertrouwen" in WASM-output een kritieke zwakke schakel is.

• XS-Leaks (Cross-Site Leaks):

  • De auteurs demonstreerden een timing-aanval via Regular Expression Denial of Service (ReDoS).
  • Door een Buffer Overflow of UAF te gebruiken, kon een aanvaller de zoek-patroon (regex) in het WASM-geheugen manipuleren.
  • Door de responstijd te meten, kon de aanvaller afleiden of een specifiek voorvoegsel van een geheim (bijv. een wachtwoord) overeenkwam met de ingevoerde regex, ondanks de isolatie van de WASM-sandbox.
  • Opmerking: Format string-exploitatie voor XS-Leaks bleek minder stabiel omdat het de interne structuren van de regex-engine (PCRE2) kon corrumperen.

Moeilijkheidsgraad:

• Buffer Overflows: Relatief eenvoudig te exploiteren, zelfs zonder broncode, door trial-and-error.
• Format Strings: Moeilijkst te exploiteren zonder inzicht in de code, vereist precieze geheugenadressen.
• Use After Free: Moeilijk vanwege de onvoorspelbaarheid van heap-allocation, maar haalbaar met zorgvuldige "heap shaping".

Significantie en Conclusie

Dit onderzoek ondermijnt de veronderstelling dat WASM per definitie veiliger is dan JavaScript of dat bestaande webbeveiligingsmaatregelen voldoende zijn. De belangrijkste conclusies zijn:

1. WASM erft C-kwetsbaarheden: De veiligheid van een webapplicatie is nu afhankelijk van de kwaliteit van de gecompileerde WASM-modules.
2. Bestaande verdedigingen zijn onvoldoende: Prepared statements en input-validatie op JavaScript-niveau kunnen worden omzeild als de WASM-module zelf de data corrupteert.
3. Nieuwe aanvalsvector: Zelfs als de WASM-output niet direct in de HTML wordt gebruikt, kunnen timing-kwetsbaarheden (XS-Leaks) gevoelige data lekken.

Aanbevelingen voor ontwikkelaars:

• Behandel alle waarden die de grens tussen JavaScript en WASM oversteken als onbetrouwbaar.
• Valideer typen en bereiken aan beide kanten om integer-overflows en buffer-overflows te voorkomen.
• Minimaliseer de geëxporteerde interfaces en geheugenregio's om het aanvalsoppervlak te verkleinen.
• Schakel compiler-sanitizers in (bijv. via Emscripten) voor stack-smashing detectie en out-of-bounds checks, ook als dit een kleine performance-kost met zich meebrengt.

Kortom, WASM-modules moeten worden behandeld met dezelfde strenge beveiligingsrigor als native applicaties, en er moet een gelaagde verdedigingsstrategie worden toegepast om de risico's van laag-niveau gecompileerde code in web-omgevingen te mitigeren.