Both are advanced WebAssembly (WASM) topics. We recommend you read the previous two topics in our WebAssembly for Beginner series.
WebAssembly for Beginners – Part 1: An Introduction To WASM WebAssembly for Beginners – Part 2: Goals, Key Concepts, and Use Cases
Let’s get started.
WebAssembly Portability
WebAssembly’s portability makes it ready for the Web. In fact, you can define WASM as a portable sandboxed platform. Furthermore, its binary format enables it to execute across various instruction set architectures and operating systems. This means you can use WASM not only on the Web but also off the Web. To understand WASM portability, we’ll discuss the following:
Local, limited, and nondeterministic environment. Specific execution environment characteristics WASM web and non-web portability
Local, Limited, and Nondeterministic
WASM needs an efficient execution and proper environments that are local, limited, and nondeterminism. Nondeterminism is computing that specifies that an algorithm/compiler/environment outputs different behaviors or results even for the same input. It is the opposite of a deterministic algorithm. The two other aspects, limited and local, are associated with nondeterministic execution. To make nondeterministic execution work, you need well-defined use cases which are “limited.” Also, these executions are “local” with no effect outside the environment. Read their official nondeterminism in the WebAssembly doc to learn more about it.
Specific Execution Environment Characteristics
To make WebAssembly portable, it assumes that the execution environment offers the following characteristics:
Byte memory granularity addressability and 8-bit bytes. 32-bit two’s complement signed integers. Optionally 64 bits. Software emulation is possible via unaligned memory accesses or reliable trapping. Support for 32-bit and 64-bit floating points as defined in IEEE 754-2008. Guarantee to execute all threads with forward progress. For 64-bit access, wasm64 should provide lock-free atomic memory operators. The lock-free atomic memory operators include 8, 16, and 32-bit accesses. wasm64 support linear memory higher than 4 GiB with 64-bit indices or pointers. Little-endian byte ordering.
All major browsers, including Chrome, Edge, Firefox, and WebKit, support all these environmental requirements. Moreover, WebAssembly is evolving at a rapid pace. The WASM Community Group and W3C WebAssembly Working Group are working towards its standardization. That means any of these requirements can change in the future.
WASM Web and Non-Web Portability
WebAssembly’s primary purpose is to provide portability and native performance on the Web and the non-web. In this section, we’ll look at how WASM achieves it.
#1. Web Embedding
WASM integrates well with the Web ecosystem, including the Web’s security model, web portability, and web APIs. Moreover, it must have enough room for creative development down the road (read WebAssembly for Beginners – Part 2 to understand its goals) So, how does WASM achieves compatibility with the Web? It utilizes JavaScript APIs, enabling developers to use JavaScript for WebAssembly modules compilation easily. It also takes care of storing and retrieving compiler modules, managing imports from compiler modules, managing memory, and so on. To learn more about how WASM achieves high-level Web compatibility, read this: Web Embedding – WebAssembly.
#2. Non-Web Embedding
As mentioned earlier, WASM also works with non-web environments. As a developer or business, you can create high-performance applications or write sections of your app that need performance tuning. For example, you can use it on IoT devices, data center servers, and desktop/mobile apps. As non-web applications cannot use web APIs, they rely on WASM’s dynamic linking. You also need to use feature testing, a software development process that tests features’ multiple variations to see what’s best for user experience. Moreover, developers can use JavaScript VMs to simplify non-web embedding or develop their apps without it. To learn more, read Non-Web Embeddings – WebAssembly.
WebAssembly Security
WebAssembly is a binary format solution that offers native-like performance. It works great on the Web but can also be fine-tuned to work on non-web embeddings. This makes WASM widely available across services, solutions, and processes. However, this means more security challenges.
WASM Security Challenges and Risks
Even though WebAssembly is considered safe and efficient, it comes with multiple security risks, including:
WebAssembly sandbox Memory management Code obfuscation Integrity checks
#1. WebAssembly Sandbox
WASM executes within the web browser, just like JavaScript. It utilizes the same Virtual Machine (VM) as JavaScript. The sandbox effectively provides a safe execution environment and hinders what’s running under the hood. So, if the JavaScript/WebAssembly code contains malicious code, it is hard to detect as it is a black box. Also, WASM code is in ready-to-run binary format; it runs faster, making it hard for antivirus solutions to look for any malicious code. For example, the code can contain unwanted advertisements or the ability to redirect users to unwanted malware sites. In addition, WebAssembly’s overreliance on JavaScript to run on the Web also means it inherits JavaScript vulnerabilities. That’s why, as a developer, you must follow JavaScript’s safety precautions and measures when coding WASM.
#2. Memory Management
Memory Management in WASM is tricky. Firstly, it doesn’t directly access physical memory as it executes within VM. That’s why it uses the host machine’s memory. Secondly, cleaning memory in WASM requires an explicit process, whereas, in comparison, JavaScript cleans itself up. In addition, when a WASM function returns output to JavaScript, it returns a pointer to the position within the allocated WASM memory space. So, if the declared memory becomes full, the WASM program can crash, ruining the user’s experience. To prevent it, programmers need to use sanitizers to debug their code or use toolchains such as emscripten.
#3. Code Obfuscation
WASM’s sandbox execution makes its code obfuscated. Additionally, the WASM binary format is also not human-readable, making it hard to reverse engineering, which is necessary to identify malicious code. These make WebAssembly code hard to debug due to its lack of human-readable format. This opens up many security loopholes, including hackers‘ ability to hide code that steals sensitive information or does code injection to take over the host machine.
#4. Integrity Checks
Any data transferred through the Web is vulnerable to data tempering. For example, hackers can perform a man-in-the-middle attack to change data values. It is an issue for WASM, considering it has no proper way to do integrity checks. However, it can work with JavaScript to perform integrity checks. Another way to identify potential WASM code vulnerabilities is to use integration tools such as Jit. It ensures the code is free from bad actors and can’t impact apps or surrounding cloud infrastructure.
Understanding WASM Security Model
WebAssembly takes security seriously. That’s why, on the official WASM docs, they have mentioned that their security model takes care of two important goals: The WASM security model knows WebAssembly apps execute independently while not being able to escape its sandbox environment. However, APIs can open up a way to attack the host environment. Another fault-tolerant technique includes executing apps deterministically with limited expectations. By ensuring both conditions, most app executions are deemed safe. To improve security, developers should enforce the same-origin policy for information flow. If you’re developing for non-web, you must use the POSIX security model. If you want to read more about its security model, check out: Security – WebAssembly.
The WebAssembly System Interface(WASI)
WASI (The WebAssembly System Interface) also plays a crucial role in WASM non-web embedding as it improves security. It is a modular system interface that offers exciting security characteristics and portability. In fact, it is now part of the WebAssembly System Interface Subgroup Charter and hence standardized. Due to WASI, WASM is widely adopted in different edge/server computing areas. Also, WASI simplifies security when moving to a non-web embedding from a web-embedding environment.
Final Words
WebAssembly’s portability and security are two big topics. In part 3 of the WebAssembly for beginners, we tried to simplify it and break it down, especially for beginners. Next, you can check out JavaScript cheat sheets for developers and learners.
