Sådan fungerer WASM-portabilitet og sikkerhed

Af
Tweet
Share
Share
Pin

Se, hvordan WebAssembly (WASM)-portabilitet og sikkerhedsmodeller fungerer i denne begyndervejledning.

Begge er avancerede WebAssembly (WASM) emner. Vi anbefaler, at du læser de to foregående emner i vores WebAssembly for Beginner-serie.

Lad os komme igang.

WebAssembly Portabilitet

WebAssemblys portabilitet gør den klar til internettet. Faktisk kan du definere WASM som en bærbar sandkasseplatform.

Desuden gør dets binære format det muligt at udføre på tværs af forskellige instruktionssætarkitekturer og operativsystemer. Det betyder, at du ikke kun kan bruge WASM på nettet, men også uden for nettet.

For at forstå WASM-portabilitet diskuterer vi følgende:

  • Lokalt, begrænset og ikke-deterministisk miljø.
  • Specifikke eksekveringsmiljøkarakteristika
  • WASM web- og ikke-webportabilitet

Lokal, begrænset og ikke-deterministisk

WASM har brug for en effektiv udførelse og ordentlige miljøer, der er lokale, begrænsede og ikke-deterministiske. Nondeterminisme er databehandling, der specificerer, at en algoritme/compiler/miljø udsender forskellig adfærd eller resultater selv for det samme input. Det er det modsatte af en deterministisk algoritme.

De to andre aspekter, begrænsede og lokale, er forbundet med ikke-deterministisk udførelse. For at få ikke-deterministisk udførelse til at fungere, har du brug for veldefinerede use cases, som er “begrænsede.”

Disse henrettelser er også “lokale” uden effekt uden for miljøet. Læs deres officielle nondeterminisme i WebAssembly-dokumentet for at lære mere om det.

Specifikke udførelsesmiljøkarakteristika

For at gøre WebAssembly bærbart, forudsætter det, at eksekveringsmiljøet tilbyder følgende egenskaber:

  • Byte hukommelse granularitet adresserbarhed og 8-bit bytes.
  • 32-bit to-komplementer fortegnede heltal. Eventuelt 64 bit.
  • Softwareemulering er mulig via ujusterede hukommelsesadgange eller pålidelig fældefangst.
  • Understøttelse af 32-bit og 64-bit flydende point som defineret i IEEE 754-2008.
  • Garanti for at udføre alle tråde med fremadskridende fremskridt.
  • For 64-bit adgang bør wasm64 give låsefri atomhukommelsesoperatører.
  • De låsefri atomhukommelsesoperatører inkluderer 8, 16 og 32-bit adgange.
  • wasm64 understøtter lineær hukommelse højere end 4 GiB med 64-bit indekser eller pointere.
  • Little-endian byte-bestilling.
  Sådan opdaterer du din iPad til den nyeste version af iPadOS

Alle større browsere, inklusive Chrome, Edge, Firefox og WebKit, understøtter alle disse miljøkrav.

Desuden udvikler WebAssembly sig i et hurtigt tempo. WASM Community Group og W3C WebAssembly Working Group arbejder hen imod dens standardisering. Det betyder, at alle disse krav kan ændre sig i fremtiden.

WASM web- og ikke-webportabilitet

WebAssemblys primære formål er at levere portabilitet og indbygget ydeevne på nettet og ikke-nettet. I dette afsnit vil vi se på, hvordan WASM opnår det.

#1. Web-indlejring

WASM integrerer godt med web-økosystemet, herunder internettets sikkerhedsmodel, webportabilitet og web-API’er. Desuden skal den have plads nok til kreativ udvikling hen ad vejen (læs WebAssembly for begyndere – del 2 for at forstå dens mål)

Så hvordan opnår WASM kompatibilitet med internettet? Det bruger JavaScript API’er, hvilket gør det muligt for udviklere at bruge JavaScript til WebAssembly-moduler kompilering nemt. Det tager sig også af at gemme og hente compilermoduler, administrere import fra compilermoduler, administrere hukommelse og så videre.

For at lære mere om, hvordan WASM opnår webkompatibilitet på højt niveau, kan du læse dette: Web Embedding – WebAssembly.

#2. Ikke-webindlejring

Som tidligere nævnt arbejder WASM også med ikke-webmiljøer. Som udvikler eller virksomhed kan du oprette højtydende applikationer eller skrive sektioner af din app, der kræver justering af ydeevnen. For eksempel kan du bruge det på IoT-enheder, datacenterservere og desktop-/mobilapps.

Da ikke-webapplikationer ikke kan bruge web-API’er, er de afhængige af WASM’s dynamiske links. Du skal også bruge funktionstest, en softwareudviklingsproces, der tester funktionernes mange variationer for at se, hvad der er bedst for brugeroplevelsen. Desuden kan udviklere bruge JavaScript VM’er til at forenkle ikke-web-indlejring eller udvikle deres apps uden det.

For at lære mere, læs Non-Web Embeddings – WebAssembly.

WebAssembly sikkerhed

WebAssembly er en binært formatløsning, der tilbyder native-lignende ydeevne. Det fungerer godt på nettet, men kan også finjusteres til at fungere på ikke-web-indlejringer. Dette gør WASM bredt tilgængelig på tværs af tjenester, løsninger og processer. Det betyder dog flere sikkerhedsmæssige udfordringer.

  9 bedste platforme til at ansætte professionelle designere

WASM sikkerhedsudfordringer og -risici

Selvom WebAssembly betragtes som sikkert og effektivt, kommer det med flere sikkerhedsrisici, herunder:

  • WebAssembly sandkasse
  • Hukommelseshåndtering
  • Kode sløring
  • Integritetstjek

#1. WebAssembly Sandbox

WASM udføres i webbrowseren, ligesom JavaScript. Den bruger den samme virtuelle maskine (VM) som JavaScript. Sandkassen giver effektivt et sikkert udførelsesmiljø og hindrer det, der løber under emhætten.

Så hvis JavaScript/WebAssembly-koden indeholder ondsindet kode, er det svært at opdage, da det er en sort boks. WASM-koden er også i klar til at køre binært format; det kører hurtigere, hvilket gør det svært for antivirusløsninger at lede efter skadelig kode. For eksempel kan koden indeholde uønskede reklamer eller evnen til at omdirigere brugere til uønskede malware-websteder.

Derudover betyder WebAssemblys overdrevne afhængighed af JavaScript til at køre på nettet også, at det arver JavaScript-sårbarheder. Derfor skal du som udvikler følge JavaScripts sikkerhedsforanstaltninger og foranstaltninger ved kodning af WASM.

#2. Hukommelseshåndtering

Hukommelsesstyring i WASM er vanskelig. For det første har den ikke direkte adgang til fysisk hukommelse, da den udføres i VM. Det er derfor, den bruger værtsmaskinens hukommelse.

For det andet kræver rensning af hukommelse i WASM en eksplicit proces, hvorimod JavaScript renser sig selv til sammenligning.

Derudover, når en WASM-funktion returnerer output til JavaScript, returnerer den en pointer til positionen inden for den tildelte WASM-hukommelsesplads. Så hvis den erklærede hukommelse bliver fuld, kan WASM-programmet gå ned, hvilket ødelægger brugerens oplevelse. For at forhindre det, skal programmører bruge desinfektionsmidler til at fejlsøge deres kode eller bruge værktøjskæder såsom emscripten.

#3. Kode sløring

WASM’s sandbox-udførelse gør dens kode sløret. Derudover er det binære WASM-format heller ikke læseligt for mennesker, hvilket gør det svært at lave omvendt konstruktion, hvilket er nødvendigt for at identificere ondsindet kode.

Disse gør WebAssembly-kode svær at fejlfinde på grund af dens mangel på menneskeligt læsbart format. Dette åbner op for mange sikkerhedshuller, herunder hackers evne til at skjule kode, der stjæler følsom information eller laver kodeindsprøjtning for at overtage værtsmaskinen.

  13 bedste robotmopper til knirkende rene gulve

#4. Integritetstjek

Alle data, der overføres via internettet, er sårbare over for datatempering. For eksempel kan hackere udføre et man-in-the-middle-angreb for at ændre dataværdier. Det er et problem for WASM, da det ikke har nogen ordentlig måde at udføre integritetstjek på.

Det kan dog fungere med JavaScript til at udføre integritetstjek. En anden måde at identificere potentielle WASM-kodesårbarheder på er at bruge integrationsværktøjer såsom Jit. Det sikrer, at koden er fri for dårlige aktører og ikke kan påvirke apps eller omkringliggende cloud-infrastruktur.

Forståelse af WASM Security Model

WebAssembly tager sikkerhed seriøst. Derfor har de på de officielle WASM-dokumenter nævnt, at deres sikkerhedsmodel tager sig af to vigtige mål:

  • Sørg for, at ingen buggy eller ondsindede moduler påvirker brugerne
  • Sørg for, at udviklere kan afbøde eventuelle sikkerhedsrisici og skabe sikre applikationer, samtidig med at det sikres, at punkt 1 altid opretholdes.

    • WASM-sikkerhedsmodellen ved, at WebAssembly-apps kører uafhængigt, mens de ikke er i stand til at undslippe sit sandkassemiljø. API’er kan dog åbne op for en måde at angribe værtsmiljøet på.

    En anden fejltolerant teknik omfatter eksekvering af apps deterministisk med begrænsede forventninger. Ved at sikre begge betingelser anses de fleste app-udførelser for sikre.

    For at forbedre sikkerheden bør udviklere håndhæve den samme oprindelsespolitik for informationsflow. Hvis du udvikler til ikke-web, skal du bruge POSIX-sikkerhedsmodellen. Hvis du vil læse mere om dens sikkerhedsmodel, så tjek: Sikkerhed – WebAssembly.

    WebAssembly System Interface (WASI)

    WASI (WebAssembly System Interface) spiller også en afgørende rolle i WASM ikke-web-indlejring, da det forbedrer sikkerheden. Det er en modulær systemgrænseflade, der tilbyder spændende sikkerhedsegenskaber og bærbarhed.

    Faktisk er det nu en del af WebAssembly System Interface Subgroup Charter og dermed standardiseret. På grund af WASI er WASM bredt udbredt i forskellige edge/server computing områder. WASI forenkler også sikkerheden, når du flytter til en ikke-web-indlejring fra et web-indlejring-miljø.

    Afsluttende ord

    WebAssemblys portabilitet og sikkerhed er to store emner. I del 3 af WebAssembly for begyndere forsøgte vi at forenkle det og nedbryde det, især for begyndere.

    Dernæst kan du tjekke JavaScript-snydeark for udviklere og elever.