El modelo de seguridad de WASM

Welcome to our lesson on the WebAssembly (WASM) Security Model! Understanding WASM's security features is crucial for building robust and safe web applications.

We'll explore how WASM is designed to be secure by default, providing a safe execution environment for code from various sources.

At the heart of WebAssembly's security is its sandboxed execution environment. Think of a sandbox as a secure, isolated space where code can run without affecting the rest of your system.

This isolation prevents malicious or buggy code from accessing sensitive data or resources outside its designated area.

When a WASM module runs, it operates within its own:

• Linear Memory: A separate block of memory, distinct from the host environment (like your browser's JavaScript memory).
• Execution Stack: Its own stack for function calls and local variables.
• Function Table: A list of callable functions, both internal and imported.

This strict separation ensures that WASM code cannot directly 'reach out' and manipulate other parts of the application or operating system.

One of the most important security features is that WASM modules cannot directly perform system calls. This means they cannot:

• Access your file system (read/write files)
• Make network requests
• Interact with hardware (like a webcam or microphone)
• Manipulate the DOM (Document Object Model) of a web page

All these operations must be explicitly mediated by the host environment (e.g., the browser or Node.js).

Since WASM can't directly access system resources, how does it do anything useful?

The host environment (usually JavaScript in a browser) acts as a gatekeeper. It explicitly imports functions into the WASM module, granting specific capabilities. For example, JavaScript might import a function that allows WASM to write to the browser's console.

WASM's linear memory is a contiguous, byte-addressable array. Each module gets its own memory instance, preventing one module from interfering with another's memory or the host's memory.

This design helps prevent common vulnerabilities like buffer overflows or arbitrary memory access, which are often exploited in native code.

WebAssembly's binary format has a structured control flow. This means that the program's execution path is well-defined and cannot be easily altered by an attacker.

Unlike assembly code, where arbitrary jumps are possible, WASM's strict validation rules prevent malicious code from hijacking the program flow, enhancing security.

This Rust code compiles to a WASM module. Notice it only performs a calculation without any direct system interaction. The host (JavaScript) would load this module and call the add function.

This demonstrates how WASM focuses on secure, isolated computation.

The host environment (e.g., your browser, Node.js runtime, or a WASI runtime) is responsible for:

• Loading and validating WASM modules.
• Providing APIs for WASM to interact with the outside world (e.g., console, network via JavaScript).
• Enforcing security policies and permissions.

This means the host remains in full control of what a WASM module can and cannot do.

Based on what we've learned, which statement best describes WebAssembly's core security principle?

In this lesson, we explored WebAssembly's robust security model. We learned that WASM runs in a strict sandbox, offering isolation and preventing direct system access.

Key takeaways:

• WASM modules have their own isolated memory.
• All interactions with the outside world are controlled by the host (e.g., JavaScript).
• This 'secure by design' approach makes WASM ideal for running untrusted code safely.

Next, we'll look into further sandboxing strategies and permissions management.