Hur WASM-portabilitet och säkerhet fungerar

By rik

Utforska hur portabilitets- och säkerhetsmodellerna för WebAssembly (WASM) fungerar i denna introduktionsguide.

Båda dessa aspekter är avancerade inom WebAssembly (WASM). Vi rekommenderar att du bekantar dig med de två tidigare delarna i vår serie ”WebAssembly för nybörjare”.

Låt oss sätta igång.

WebAssemblys Portabilitet

Portabiliteten är en grundsten för WebAssemblys framgång på webben. WASM kan beskrivas som en transportabel, isolerad plattform.

Dess binära format möjliggör exekvering på olika instruktionsuppsättningar och operativsystem. Det innebär att WASM inte bara kan användas på webben, utan även i andra miljöer.

För att förstå WASM:s portabilitet, ska vi gå igenom följande:

  • Lokal, begränsad och icke-deterministisk omgivning.
  • Specifika krav på exekveringsmiljön
  • WASM:s portabilitet på och utanför webben

Lokal, Begränsad och Icke-deterministisk

WASM kräver en effektiv exekvering och väldefinierade miljöer som är lokala, begränsade och icke-deterministiska. Icke-determinism innebär att en algoritm/kompilator/miljö kan producera olika beteenden eller resultat även med identiska indata. Detta står i motsats till deterministiska algoritmer.

De andra två aspekterna, begränsad och lokal, är kopplade till icke-deterministisk exekvering. För att icke-deterministisk exekvering ska fungera krävs väldefinierade scenarier som är ”begränsade”.

Dessa exekveringar är dessutom ”lokala” och påverkar inte miljön utanför. Fördjupa dig i deras officiella dokument om icke-determinism i WebAssembly för mer information.

Egenskaper hos Specifika Exekveringsmiljöer

För att säkerställa WebAssemblys portabilitet, krävs det att exekveringsmiljön tillhandahåller följande egenskaper:

  • Adresserbarhet på byte-nivå med 8-bitars byte.
  • 32-bitars tvåkomplements heltal, eventuellt 64 bitar.
  • Möjlighet till programemulering genom ojusterade minnesåtkomster eller pålitliga fel.
  • Stöd för 32-bitars och 64-bitars flyttal enligt standarden IEEE 754-2008.
  • Garanterad progression för alla trådar.
  • För 64-bitars åtkomst ska wasm64 tillhandahålla låsfria atomminnesoperationer.
  • Låsfria atomminnesoperationer omfattar 8-, 16- och 32-bitars åtkomster.
  • wasm64 stöder linjärt minne som överstiger 4 GiB med 64-bitars index eller pekare.
  • Little-endian byte-ordning.

Alla ledande webbläsare, inklusive Chrome, Edge, Firefox och WebKit, uppfyller dessa miljökrav.

WebAssembly utvecklas snabbt, och WASM Community Group tillsammans med W3C WebAssembly Working Group arbetar aktivt med standardiseringen. Detta innebär att kraven kan ändras framöver.

WASM:s Portabilitet på Webben och Utanför

WebAssemblys primära mål är att möjliggöra portabilitet och hög prestanda både på webben och utanför den. Vi ska nu undersöka hur WASM uppnår detta.

#1. Inbäddning på webben

WASM är väl integrerat med webbens ekosystem, inklusive webbsäkerhet, portabilitet och API:er. Det ska även finnas utrymme för innovation (se ”WebAssembly för nybörjare – Del 2” för att förstå dess mål).

Hur uppnår WASM kompatibilitet med webben? Det använder ett JavaScript API, som ger utvecklare möjligheten att enkelt använda JavaScript för WebAssembly-moduler. Det hanterar även lagring och hämtning av kompilatormoduler, importer från kompilatormoduler, minneshantering och liknande.

För att lära dig mer om WASM:s webbkompatibilitet på en övergripande nivå, se: Webbambedding – WebAssembly.

#2. Inbäddning utanför webben

Som tidigare nämnts fungerar WASM även utanför webbmiljöer. Utvecklare och företag kan skapa högpresterande applikationer eller skriva kodavsnitt som kräver prestandaoptimering. Exempelvis kan det användas på IoT-enheter, datacenterservrar samt stationära och mobila applikationer.

Eftersom applikationer utanför webben inte kan använda webb-API:er, använder de WASM:s dynamiska länkning. Du behöver även använda funktionstester, en mjukvaruutvecklingsprocess som testar många varianter av funktioner för att se vad som ger den bästa användarupplevelsen. Dessutom kan utvecklare använda virtuella JavaScript-maskiner för att förenkla inbäddning utanför webben eller utveckla appar utan den.

För mer information, läs Non-Web Embeddings – WebAssembly.

WebAssembly Säkerhet

WebAssembly är en binär lösning som erbjuder prestanda i närheten av native-kod. Det fungerar utmärkt på webben, men kan också anpassas för att fungera utanför webben. Detta gör WASM brett tillgängligt, men ökar även säkerhetsutmaningarna.

Säkerhetsutmaningar och Risker

WebAssembly anses vara säkert och effektivt, men det finns flera säkerhetsrisker, inklusive:

  • WebAssembly-sandboxen
  • Minneshantering
  • Kodförvrängning
  • Integritetskontroller

#1. WebAssembly Sandbox

WASM körs i webbläsaren, precis som JavaScript, och använder samma virtuella maskin (VM). Sandboxen ger en säker exekveringsmiljö och begränsar vad som sker under ytan.

Om JavaScript/WebAssembly-koden innehåller skadlig kod är det svårt att upptäcka eftersom det är en ”svart låda”. WASM-koden är i binärt format, vilket gör den snabbare och svårare för antiviruslösningar att analysera. Koden kan innehålla oönskade annonser eller omdirigera användare till webbplatser med skadlig programvara.

Eftersom WebAssembly förlitar sig på JavaScript för att köras på webben, ärver det även JavaScript-sårbarheter. Därför behöver utvecklare följa JavaScripts säkerhetsåtgärder när de kodar WASM.

#2. Minneshantering

Minneshantering i WASM är komplex. Den får inte direkt tillgång till fysiskt minne eftersom det körs i en VM, utan använder värddatorns minne.

Rensning av minne i WASM kräver en explicit process, medan JavaScript rensar upp sig själv.

När en WASM-funktion returnerar data till JavaScript, returneras en pekare till positionen i WASM:s allokerade minnesutrymme. Om det deklarerade minnet blir fullt kan WASM-programmet krascha. För att undvika detta, behöver programmerare använda desinfektionsmedel för att felsöka sin kod eller använda verktyg som emscripten.

#3. Kodförvrängning

WASM:s sandbox-körning gör dess kod förvrängd. Det binära WASM-formatet är inte läsbart för människor, vilket gör det svårt att göra omvänd konstruktion, vilket är nödvändigt för att identifiera skadlig kod.

Dessa faktorer gör WebAssembly-kod svår att felsöka på grund av dess brist på läsbarhet. Detta öppnar för säkerhetshål, som att hackare döljer kod som stjäl känslig information eller gör kodinjektion för att ta över värddatorn.

#4. Integritetskontroller

All data som överförs över webben är utsatt för dataförfalskning. Hackare kan utföra en ”man-in-the-middle”-attack för att ändra datavärden. Detta är ett problem för WASM, eftersom det inte har ett eget sätt att utföra integritetskontroller.

Det kan dock samarbeta med JavaScript för att utföra integritetskontroller. Ett annat sätt att identifiera sårbarheter i WASM-kod är att använda verktyg som Jit. Detta säkerställer att koden inte påverkas av skadliga aktörer och inte kan påverka appar eller molninfrastruktur.

Förstå WASM:s Säkerhetsmodell

WebAssembly tar säkerheten på allvar. Deras officiella dokument betonar att säkerhetsmodellen fokuserar på två huvudsakliga mål:

  • Att säkerställa att buggiga eller skadliga moduler inte påverkar användare.
  • Att ge utvecklare möjligheten att minska potentiella säkerhetsrisker och bygga säkra applikationer, samtidigt som punkt 1 alltid upprätthålls.
  • WASM:s säkerhetsmodell bygger på att WebAssembly-appar körs oberoende och isolerade inom sin sandbox-miljö. Men API:er kan öppna en väg för attacker mot värdmiljön.

    En annan feltolerant teknik är att köra applikationer deterministiskt med begränsade förväntningar. Genom att garantera dessa villkor anses de flesta appkörningar säkra.

    För att förbättra säkerheten bör utvecklare tillämpa samma ursprungspolicy för informationsflöde. Om du utvecklar för miljöer utanför webben behöver du använda POSIX-säkerhetsmodellen. För mer information om säkerhetsmodellen, se: Säkerhet – WebAssembly.

    WebAssembly System Interface (WASI)

    WASI (WebAssembly System Interface) spelar en viktig roll i WASM:s inbäddning utanför webben genom att förbättra säkerheten. Det är ett modulärt systemgränssnitt som erbjuder intressanta säkerhetsfunktioner och portabilitet.

    Det är nu en del av WebAssembly System Interface Subgroup Charter och därmed standardiserat. På grund av WASI används WASM flitigt inom olika edge/server-beräkningsområden. WASI förenklar också säkerheten när man går över från en webbinbäddad miljö till en utanför webben.

    Sammanfattning

    WebAssemblys portabilitet och säkerhet är två stora områden. I del 3 av ”WebAssembly för nybörjare” har vi försökt att förenkla och bryta ner dessa koncept, särskilt för nybörjare.

    Nästa steg kan vara att kolla in ett JavaScript-fuskblad för utvecklare och studenter.