WASM's sikkerhedsmodel

Velkommen til vores lektion om WebAssemblys (WASM's) sikkerhedsmodel! Det er afgørende at forstå WASM's sikkerhedsfunktioner, når du bygger robuste og sikre webapplikationer.

Vi undersøger, hvordan WASM er designet til at være sikkert som standard og leverer et sikkert kørselsmiljø for kode fra forskellige kilder.

Kernen i WebAssemblys sikkerhed er dets isolerede kørselsmiljø. Tænk på en sandkasse som et sikkert, isoleret område, hvor kode kan køre uden at påvirke resten af dit system.

Denne isolation forhindrer skadelig eller fejlbehæftet kode i at få adgang til følsomme data eller ressourcer uden for det tildelte område.

Når et WASM-modul kører, arbejder det i sin egen:

• Lineære hukommelse: En separat hukommelsesblok, der er adskilt fra værtsmiljøet, f.eks. browserens JavaScript-hukommelse.
• Kørselsstak: Sin egen stak til funktionskald og lokale variable.
• Funktionstabel: En liste over funktioner, der kan kaldes, både interne og importerede.

Denne strenge adskillelse sikrer, at WASM-kode ikke direkte kan "række ud" og ændre andre dele af applikationen eller operativsystemet.

En af de vigtigste sikkerhedsfunktioner er, at WASM-moduler ikke kan udføre systemkald direkte. Det betyder, at de ikke kan:

• Få adgang til dit filsystem (læse/skrive filer)
• Foretage netværksanmodninger
• Interagere med hardware, f.eks. et webkamera eller en mikrofon
• Ændre DOM'en (Document Object Model) på en webside

Alle disse handlinger skal udtrykkeligt formidles af værtsmiljøet, f.eks. browseren eller Node.js.

Hvordan kan WASM så gøre noget nyttigt, når det ikke har direkte adgang til systemressourcer?

Værtsmiljøet, som normalt er JavaScript i en browser, fungerer som portvagt. Det importerer udtrykkeligt funktioner til WASM-modulet og tildeler bestemte funktioner. JavaScript kan f.eks. importere en funktion, der giver WASM mulighed for at skrive til browserens konsol.

WASM's lineære hukommelse er et sammenhængende array, der kan adresseres byte for byte. Hvert modul får sin egen hukommelsesinstans, så ét modul ikke kan forstyrre et andet moduls eller værtens hukommelse.

Dette design hjælper med at forhindre almindelige sårbarheder som bufferoverløb eller vilkårlig hukommelsesadgang, der ofte udnyttes i native-kode.

WebAssemblys binære format har et struktureret kontrolflow. Det betyder, at programmets kørselssti er veldefineret og ikke let kan ændres af en angriber.

I modsætning til assemblerkode, hvor vilkårlige spring er mulige, forhindrer WASM's strenge valideringsregler skadelig kode i at kapre programmets flow, hvilket øger sikkerheden.

Denne Rust-kode kompileres til et WASM-modul. Bemærk, at den kun udfører en beregning uden direkte systeminteraktion. Værten (JavaScript) indlæser dette modul og kalder funktionen add.

Dette viser, hvordan WASM fokuserer på sikker, isoleret beregning.

Værtsmiljøet, f.eks. din browser, Node.js-kørselsmiljøet eller et WASI-kørselsmiljø, er ansvarligt for:

• Indlæsning og validering af WASM-moduler.
• Levering af API'er, så WASM kan interagere med omverdenen, f.eks. konsollen eller netværket via JavaScript.
• Håndhævelse af sikkerhedspolitikker og tilladelser.

Det betyder, at værten har fuld kontrol over, hvad et WASM-modul kan og ikke kan gøre.

I denne lektion undersøgte vi WebAssemblys robuste sikkerhedsmodel. Vi lærte, at WASM kører i en streng sandkasse, der sørger for isolation og forhindrer direkte systemadgang.

Vigtigste pointer:

• WASM-moduler har deres egen isolerede hukommelse.
• Al interaktion med omverdenen styres af værten, f.eks. JavaScript.
• Denne tilgang med sikkerhed indbygget i designet gør WASM velegnet til sikker kørsel af kode, du ikke har tillid til.

Dernæst ser vi nærmere på yderligere sandkassestrategier og håndtering af tilladelser.