Hur WASM-portabilitet och säkerhet fungerar

av

Kolla in hur WebAssembly (WASM) portabilitets- och säkerhetsmodeller fungerar i den här nybörjarguiden.

Båda är ämnen för avancerad WebAssembly (WASM). Vi rekommenderar att du läser de två föregående ämnena i vår WebAssembly for Beginner-serie.

Låt oss börja.

WebAssembly Portabilitet

WebAssemblys portabilitet gör den redo för webben. Faktum är att du kan definiera WASM som en bärbar sandlådeplattform.

Dessutom gör det binära formatet det möjligt att köra över olika instruktionsuppsättningsarkitekturer och operativsystem. Detta innebär att du kan använda WASM inte bara på webben utan även utanför webben.

För att förstå WASM-portabilitet kommer vi att diskutera följande:

  • Lokal, begränsad och icke-deterministisk miljö.
  • Specifika exekveringsmiljöegenskaper
  • WASM webb- och icke-webbportabilitet

Lokal, begränsad och icke-deterministisk

WASM behöver ett effektivt utförande och korrekta miljöer som är lokala, begränsade och obestämda. Nondeterminism är datorer som specificerar att en algoritm/kompilator/miljö matar ut olika beteenden eller resultat även för samma indata. Det är motsatsen till en deterministisk algoritm.

De två andra aspekterna, begränsade och lokala, är förknippade med icke-deterministiskt utförande. För att få odeterministisk exekvering att fungera behöver du väldefinierade användningsfall som är ”begränsade”.

Dessutom är dessa avrättningar ”lokala” utan effekt utanför miljön. Läs deras officiella nondeterminism i WebAssembly-dokumentet för att lära dig mer om det.

Specifika exekveringsmiljöegenskaper

För att göra WebAssembly portabel, förutsätter det att exekveringsmiljön erbjuder följande egenskaper:

  • Byte minne granularitet adresserbarhet och 8-bitars byte.
  • 32-bitars två kompletterar signerade heltal. Eventuellt 64 bitar.
  • Programemulering är möjlig via ojusterade minnesåtkomster eller tillförlitlig fällning.
  • Stöd för 32-bitars och 64-bitars flyttal enligt definition i IEEE 754-2008.
  • Garanterar att köra alla trådar med framåtskridande framsteg.
  • För 64-bitars åtkomst bör wasm64 tillhandahålla låsfria atomminnesoperatörer.
  • De låsfria atomminnesoperatörerna inkluderar 8-, 16- och 32-bitars åtkomster.
  • wasm64 stöder linjärt minne högre än 4 GiB med 64-bitars index eller pekare.
  • Little-endian byte-ordning.

Alla större webbläsare, inklusive Chrome, Edge, Firefox och WebKit, stöder alla dessa miljökrav.

Dessutom utvecklas WebAssembly i snabb takt. WASM Community Group och W3C WebAssembly Working Group arbetar mot dess standardisering. Det betyder att alla dessa krav kan ändras i framtiden.

WASM webb- och icke-webbportabilitet

WebAssemblys primära syfte är att tillhandahålla portabilitet och inbyggd prestanda på webben och icke-webben. I det här avsnittet ska vi titta på hur WASM uppnår det.

#1. Webbbäddning

WASM integrerar väl med webbekosystemet, inklusive webbens säkerhetsmodell, webbportabilitet och webb-API:er. Dessutom måste det ha tillräckligt med utrymme för kreativ utveckling på vägen (läs WebAssembly for Beginners – Del 2 för att förstå dess mål)

Så, hur uppnår WASM kompatibilitet med webben? Den använder JavaScript API, vilket gör det möjligt för utvecklare att enkelt använda JavaScript för WebAssembly-moduler. Den tar även hand om att lagra och hämta kompilatormoduler, hantera importer från kompilatormoduler, hantera minne och så vidare.

För att lära dig mer om hur WASM uppnår webbkompatibilitet på hög nivå, läs detta: Webbambedding – WebAssembly.

#2. Icke-webbbäddning

Som tidigare nämnts fungerar WASM även med icke-webbmiljöer. Som utvecklare eller företag kan du skapa högpresterande applikationer eller skriva avsnitt av din app som behöver justeras prestanda. Du kan till exempel använda den på IoT-enheter, datacenterservrar och stationära/mobila appar.

Eftersom icke-webbapplikationer inte kan använda webb-API:er förlitar de sig på WASM:s dynamiska länkning. Du måste också använda funktionstestning, en mjukvaruutvecklingsprocess som testar funktionernas många varianter för att se vad som är bäst för användarupplevelsen. Dessutom kan utvecklare använda virtuella JavaScript-datorer för att förenkla icke-webbbäddning eller utveckla sina appar utan det.

För att lära dig mer, läs Non-Web Embeddings – WebAssembly.

WebAssembly säkerhet

WebAssembly är en lösning i binärt format som erbjuder native-liknande prestanda. Det fungerar utmärkt på webben men kan också finjusteras för att fungera på icke-webbambäddningar. Detta gör WASM brett tillgängligt över tjänster, lösningar och processer. Detta innebär dock fler säkerhetsutmaningar.

WASM säkerhetsutmaningar och risker

Även om WebAssembly anses vara säkert och effektivt, kommer det med flera säkerhetsrisker, inklusive:

  • WebAssembly sandlåda
  • Minneshantering
  • Kodförvirring
  • Integritetskontroller

#1. WebAssembly Sandbox

WASM körs i webbläsaren, precis som JavaScript. Den använder samma virtuella maskin (VM) som JavaScript. Sandlådan ger effektivt en säker exekveringsmiljö och hindrar det som rinner under huven.

Så om JavaScript/WebAssembly-koden innehåller skadlig kod är det svårt att upptäcka eftersom det är en svart låda. Dessutom är WASM-koden i ett färdigt binärt format; det går snabbare, vilket gör det svårt för antiviruslösningar att leta efter skadlig kod. Koden kan till exempel innehålla oönskade annonser eller möjligheten att omdirigera användare till webbplatser med oönskad skadlig programvara.

Dessutom innebär WebAssemblys alltför beroende av JavaScript för att köras på webben att det ärver JavaScript-sårbarheter. Det är därför du som utvecklare måste följa JavaScripts säkerhetsåtgärder och åtgärder när du kodar WASM.

#2. Minneshantering

Minneshantering i WASM är knepigt. För det första får den inte direkt tillgång till fysiskt minne eftersom det körs inom VM. Det är därför den använder värddatorns minne.

För det andra kräver rengöring av minne i WASM en explicit process, medan JavaScript i jämförelse rensar upp sig själv.

Dessutom, när en WASM-funktion returnerar utdata till JavaScript, returnerar den en pekare till positionen inom det tilldelade WASM-minnesutrymmet. Så om det deklarerade minnet blir fullt kan WASM-programmet krascha och förstöra användarens upplevelse. För att förhindra det måste programmerare använda desinfektionsmedel för att felsöka sin kod eller använda verktygskedjor som emscripten.

#3. Kodförvirring

WASM:s sandlådekörning gör dess kod obfuskerad. Dessutom är det binära WASM-formatet inte heller 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 gör WebAssembly-kod svår att felsöka på grund av dess brist på mänskligt läsbart format. Detta öppnar upp för många säkerhetsluckor, inklusive hackares förmåga att dölja kod som stjäl känslig information eller gör kodinjektion för att ta över värdmaskinen.

#4. Integritetskontroller

All data som överförs via webben är sårbar för datahärdning. Till exempel kan hackare utföra en man-in-the-middle-attack för att ändra datavärden. Det är ett problem för WASM, med tanke på att det inte har något korrekt sätt att göra integritetskontroller.

Det kan dock fungera med JavaScript för att utföra integritetskontroller. Ett annat sätt att identifiera potentiella WASM-kodsårbarheter är att använda integrationsverktyg som Jit. Det säkerställer att koden är fri från dåliga aktörer och inte kan påverka appar eller omgivande molninfrastruktur.

Förstå WASM Security Model

WebAssembly tar säkerheten på allvar. Det är därför de i de officiella WASM-dokumenten har nämnt att deras säkerhetsmodell tar hand om två viktiga mål:

  • Se till att inga buggiga eller skadliga moduler påverkar användare
  • Se till att utvecklare kan minska eventuella säkerhetsrisker och skapa säkra applikationer samtidigt som du säkerställer att punkt 1 alltid bibehålls.

    • WASM-säkerhetsmodellen vet att WebAssembly-appar körs oberoende samtidigt som de inte kan fly från sin sandlådemiljö. Men API:er kan öppna ett sätt att attackera värdmiljön.

    En annan feltolerant teknik inkluderar att exekvera appar deterministiskt med begränsade förväntningar. Genom att säkerställa båda villkoren anses de flesta appkörningar vara 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 icke-webb måste du använda POSIX-säkerhetsmodellen. Om du vill läsa mer om dess säkerhetsmodell, kolla in: Säkerhet – WebAssembly.

    WebAssembly System Interface (WASI)

    WASI (WebAssembly System Interface) spelar också en avgörande roll i WASM icke-webbambäddning eftersom det förbättrar säkerheten. Det är ett modulärt systemgränssnitt som erbjuder spännande säkerhetsegenskaper och portabilitet.

    Faktum är att det nu är en del av WebAssembly System Interface Subgroup Charter och är därför standardiserat. På grund av WASI används WASM i stor utsträckning inom olika edge/server-beräkningsområden. Dessutom förenklar WASI säkerheten när man flyttar till en icke-webbambäddning från en webbinbäddningsmiljö.

    Slutord

    WebAssemblys portabilitet och säkerhet är två stora ämnen. I del 3 av WebAssembly för nybörjare försökte vi förenkla det och bryta ner det, speciellt för nybörjare.

    Därefter kan du kolla in JavaScript-fuskblad för utvecklare och elever.