Hvordan WASM-portabilitet og sikkerhet fungerer

by
Tweet
Share
Share
Pin
0 Shares

Sjekk ut hvordan WebAssembly (WASM) portabilitet og sikkerhetsmodeller fungerer i denne nybegynnerveiledningen.

Begge er avanserte WebAssembly (WASM) emner. Vi anbefaler at du leser de to foregående emnene i vår WebAssembly for Beginner-serie.

La oss komme i gang.

WebAssembly-portabilitet

WebAssemblys portabilitet gjør den klar for nettet. Faktisk kan du definere WASM som en bærbar sandkasseplattform.

Videre gjør dets binære format det mulig å kjøre på tvers av ulike instruksjonssettarkitekturer og operativsystemer. Dette betyr at du kan bruke WASM ikke bare på nettet, men også utenfor nettet.

For å forstå WASM-portabilitet, vil vi diskutere følgende:

  • Lokalt, begrenset og ikke-deterministisk miljø.
  • Spesifikke utførelsesmiljøegenskaper
  • WASM web- og ikke-webportabilitet

Lokal, begrenset og ikke-deterministisk

WASM trenger en effektiv utførelse og riktige miljøer som er lokale, begrensede og ikke-deterministiske. Nondeterminisme er databehandling som spesifiserer at en algoritme/kompilator/miljø gir forskjellig oppførsel eller resultater selv for samme inngang. Det er det motsatte av en deterministisk algoritme.

De to andre aspektene, begrensede og lokale, er assosiert med ikke-deterministisk utførelse. For å få ikke-deterministisk utførelse til å fungere, trenger du veldefinerte brukstilfeller som er «begrenset».

Dessuten er disse henrettelsene «lokale» uten effekt utenfor miljøet. Les deres offisielle nondeterminisme i WebAssembly-dokumentet for å lære mer om det.

Spesifikke utførelsesmiljøegenskaper

For å gjøre WebAssembly bærbart, antar det at utførelsesmiljøet tilbyr følgende egenskaper:

  • Byte minne granularitet adresserbarhet og 8-bit byte.
  • 32-bits to-komplementert heltall. Eventuelt 64 bits.
  • Programvareemulering er mulig via ujusterte minnetilganger eller pålitelig overlapping.
  • Støtte for 32-biters og 64-biters flytende punkt som definert i IEEE 754-2008.
  • Garantert å kjøre alle tråder med fremdrift.
  • For 64-biters tilgang bør wasm64 gi låsefrie atomminneoperatører.
  • De låsefrie atomminneoperatørene inkluderer 8-, 16- og 32-biters tilganger.
  • wasm64 støtter lineært minne høyere enn 4 GiB med 64-bits indekser eller pekere.
  • Little-endian byte-bestilling.
  USB 4 vil gi Thunderbolt-hastigheter for mindre penger

Alle større nettlesere, inkludert Chrome, Edge, Firefox og WebKit, støtter alle disse miljøkravene.

Dessuten utvikler WebAssembly seg i et raskt tempo. WASM Community Group og W3C WebAssembly Working Group jobber mot standardiseringen. Det betyr at alle disse kravene kan endres i fremtiden.

WASM web- og ikke-webportabilitet

WebAssemblys primære formål er å gi portabilitet og innebygd ytelse på nettet og ikke-nettet. I denne delen skal vi se på hvordan WASM oppnår det.

#1. Web-innbygging

WASM integreres godt med webøkosystemet, inkludert nettets sikkerhetsmodell, nettportabilitet og web-APIer. Dessuten må den ha nok rom for kreativ utvikling på veien (les WebAssembly for Beginners – Del 2 for å forstå målene)

Så hvordan oppnår WASM kompatibilitet med nettet? Den bruker JavaScript APIer, slik at utviklere enkelt kan bruke JavaScript for WebAssembly-moduler. Den tar seg også av å lagre og hente kompilatormoduler, administrere import fra kompilatormoduler, administrere minne og så videre.

For å lære mer om hvordan WASM oppnår webkompatibilitet på høyt nivå, les dette: Web Embedding – WebAssembly.

#2. Ikke-nettinnbygging

Som nevnt tidligere, fungerer WASM også med ikke-webmiljøer. Som utvikler eller bedrift kan du lage applikasjoner med høy ytelse eller skrive deler av appen din som trenger ytelsesjustering. Du kan for eksempel bruke den på IoT-enheter, datasenterservere og desktop-/mobilapper.

Siden ikke-webapplikasjoner ikke kan bruke web-APIer, er de avhengige av WASMs dynamiske koblinger. Du må også bruke funksjonstesting, en programvareutviklingsprosess som tester funksjonenes mange varianter for å se hva som er best for brukeropplevelsen. Utviklere kan dessuten bruke JavaScript-VM-er for å forenkle ikke-nettinnbygging eller utvikle appene sine uten.

For å lære mer, les Non-Web Embeddings – WebAssembly.

WebAssembly Sikkerhet

WebAssembly er en binærformatløsning som tilbyr native-lignende ytelse. Det fungerer utmerket på nettet, men kan også finjusteres for å fungere på ikke-web-innbygginger. Dette gjør WASM allment tilgjengelig på tvers av tjenester, løsninger og prosesser. Dette betyr imidlertid flere sikkerhetsutfordringer.

  Slik fjerner du sideskift i Word

WASM sikkerhetsutfordringer og -risikoer

Selv om WebAssembly anses som trygt og effektivt, kommer det med flere sikkerhetsrisikoer, inkludert:

  • WebAssembly sandkasse
  • Minnehåndtering
  • Kodeforvirring
  • Integritetssjekker

#1. WebAssembly Sandbox

WASM kjøres i nettleseren, akkurat som JavaScript. Den bruker den samme virtuelle maskinen (VM) som JavaScript. Sandkassen gir effektivt et trygt utførelsesmiljø og hindrer det som renner under panseret.

Så hvis JavaScript/WebAssembly-koden inneholder ondsinnet kode, er det vanskelig å oppdage siden det er en svart boks. Dessuten er WASM-koden i klar til å kjøre binært format; den kjører raskere, noe som gjør det vanskelig for antivirusløsninger å lete etter skadelig kode. For eksempel kan koden inneholde uønskede annonser eller muligheten til å omdirigere brukere til uønskede skadevaresider.

I tillegg betyr WebAssemblys overavhengighet av JavaScript for å kjøre på nettet også at den arver JavaScript-sårbarheter. Derfor må du som utvikler følge JavaScripts sikkerhetsregler og tiltak når du koder WASM.

#2. Minnehåndtering

Minnehåndtering i WASM er vanskelig. For det første får den ikke direkte tilgang til fysisk minne ettersom den kjøres i VM. Det er derfor den bruker vertsmaskinens minne.

For det andre krever rensing av minne i WASM en eksplisitt prosess, mens JavaScript renser seg selv til sammenligning.

I tillegg, når en WASM-funksjon returnerer utdata til JavaScript, returnerer den en peker til posisjonen innenfor den tildelte WASM-minneplassen. Så hvis det deklarerte minnet blir fullt, kan WASM-programmet krasje og ødelegge brukerens opplevelse. For å forhindre det, må programmerere bruke rensemidler for å feilsøke koden eller bruke verktøykjeder som emscripten.

#3. Kodeobfuskasjon

WASMs sandkassekjøring gjør koden tilslørt. I tillegg er det binære WASM-formatet heller ikke lesbart for mennesker, noe som gjør det vanskelig å reversere engineering, noe som er nødvendig for å identifisere ondsinnet kode.

Disse gjør WebAssembly-kode vanskelig å feilsøke på grunn av mangelen på menneskelig lesbart format. Dette åpner for mange smutthull i sikkerheten, inkludert hackers evne til å skjule kode som stjeler sensitiv informasjon eller gjør kodeinjeksjon for å overta vertsmaskinen.

  Fiks Disney Plus som ikke fungerer på Roku

#4. Integritetssjekker

Alle data som overføres via nettet er sårbare for datatempering. For eksempel kan hackere utføre et mann-i-midten-angrep for å endre dataverdier. Det er et problem for WASM, med tanke på at det ikke har noen riktig måte å utføre integritetskontroller på.

Det kan imidlertid fungere med JavaScript for å utføre integritetssjekker. En annen måte å identifisere potensielle WASM-kodesårbarheter på er å bruke integreringsverktøy som Jit. Det sikrer at koden er fri for dårlige aktører og ikke kan påvirke apper eller omkringliggende skyinfrastruktur.

Forstå WASM sikkerhetsmodell

WebAssembly tar sikkerhet på alvor. Derfor har de på de offisielle WASM-dokumentene nevnt at sikkerhetsmodellen deres tar seg av to viktige mål:

  • Sørg for at ingen buggy eller ondsinnede moduler påvirker brukere
  • Sørg for at utviklere kan redusere eventuelle sikkerhetsrisikoer og lage trygge applikasjoner samtidig som du sikrer at punkt 1 alltid opprettholdes.

    • WASM-sikkerhetsmodellen vet at WebAssembly-apper kjører uavhengig mens de ikke er i stand til å unnslippe sandkassemiljøet. Imidlertid kan API-er åpne en måte å angripe vertsmiljøet på.

    En annen feiltolerant teknikk inkluderer å utføre apper deterministisk med begrensede forventninger. Ved å sikre begge forholdene anses de fleste appkjøringer som trygge.

    For å forbedre sikkerheten bør utviklere håndheve policyen med samme opprinnelse for informasjonsflyt. Hvis du utvikler for ikke-nett, må du bruke POSIX-sikkerhetsmodellen. Hvis du vil lese mer om sikkerhetsmodellen, sjekk ut: Sikkerhet – WebAssembly.

    WebAssembly System Interface (WASI)

    WASI (WebAssembly System Interface) spiller også en avgjørende rolle i WASM ikke-web-innbygging da det forbedrer sikkerheten. Det er et modulært systemgrensesnitt som tilbyr spennende sikkerhetsegenskaper og portabilitet.

    Faktisk er det nå en del av WebAssembly System Interface Subgroup Charter og dermed standardisert. På grunn av WASI, er WASM mye brukt i forskjellige edge/server databehandlingsområder. WASI forenkler også sikkerheten når du flytter til en ikke-web-innbygging fra et web-innbyggingsmiljø.

    Siste ord

    WebAssemblys portabilitet og sikkerhet er to store emner. I del 3 av WebAssembly for nybegynnere prøvde vi å forenkle den og bryte den ned, spesielt for nybegynnere.

    Deretter kan du sjekke ut JavaScript-jukseark for utviklere og elever.