The Internet has come a long way since its inception and one of the key technologies that have enabled its growth and evolution is JavaScript. JavaScript, which was developed in the mid-1990s, is a programming language that is widely used to create interactive and dynamic websites. It was initially designed to enable basic interactivity on web pages, such as form validation and image slideshows. However, it has evolved into a versatile language that is used to build complex web applications. Today, JavaScript is one of the most popular programming languages in the world, currently being used by 98% of all websites [1].

Despite its popularity and versatility, JavaScript has some inherent limitations that have become apparent as web applications have grown more complex and resource-demanding. Specifically, JavaScript is a high-level, interpreted, dynamically typed language, which fundamentally limits its performance. Consequently, it is not suited for developing resource-demanding web applications. To address the shortcomings of JavaScript, several technologies, like ActiveX [2], NaCl [3], and asm.js [4], have been developed. However, these technologies have faced compatibility issues, security vulnerabilities, and performance limitations.

WebAssembly was developed by a consortium of companies, including Mozilla, Microsoft, Apple, and Google, as a solution to the limitations of existing technologies. WebAssembly is designed as a safe, fast, and portable compilation target for high-level languages like C, C++, and Rust, allowing them to be executed with near-native performance in the browser. It has gained widespread adoption and is currently supported by 96% of all browser instances [5]. Moreover, WebAssembly is also being extended to desktop applications [6], mobile devices [7], cloud computing [8], blockchain virtual machines (VMs) ^[9][10][11][9,10,11], IoT ^[12][13][12,13], and embedded devices [14].

Overview. WebAssembly is a technology that aims to address performance, compatibility, and security issues that have plagued previous approaches. It was developed by a consortium of tech companies, including Mozilla, Microsoft, Apple, and Google, and was released in 2017 ^[15][25]. WebAssembly has since gained widespread adoption and is currently supported by 96% of all browser instances [5]. Additionally, it is an official World Wide Web Consortium (W3C) standard ^[16][26], and is natively supported on the web. An overview of WebAssembly is given in Figure 1. WebAssembly is a low-level bytecode language that runs on a stack-based Virtual Machine (VM). More specifically, instructions push and pop operands to the evaluation stack. This architecture does not use registers; instead, values are stored in global variables that are accessible throughout the entire module or in local variables that are scoped to the current function. The VM manages the evaluation stack, global variables, and local variables. Host Environment. WebAssembly modules run within a host environment, which provides the necessary functionality for the module to perform actions such as I/O or network access. In a browser, the host environment is provided by the JavaScript engine, such as V8 or SpiderMonkey. WebAssembly exports can be wrapped in JavaScript functions using the WebAssembly JavaScript API ^[17][27], allowing them to be called from JavaScript code. Similarly, WebAssembly code can import and call JavaScript functions. Other host environments for WebAssembly include server-side environments like Node.js ^[18][28] and stand-alone VMs with accompanying APIs. For instance, the WebAssembly System Interface (WASI) ^[19][29] allows WebAssembly modules to access the file system. Module. WebAssembly modules serve as the fundamental building blocks for deployment, loading, and compilation. A module contains definitions for types, functions, tables, memories, and globals. In addition, a module can declare imports and exports, as well as provide initialization through data and element segments or a start function. Compilation. Languages like C, C++, and Rust can be compiled into WebAssembly since it is designed as a compilation target. Toolchains like Emscripten ^[20][22] or wasm-pack ^[21][30] can be used to compile these languages to WebAssembly. The resulting binary is in the wasm binary format, but can also be represented in the equivalent human-readable text format called wat. A module corresponds to one file. The WebAssembly Binary Toolkit (WABT) ^[22][31] provides tools for converting between wasm and wat representations, as well as for the de-compilation and validation of WebAssembly binaries. Use Cases. WebAssembly has been adopted for various applications on the web due to its near-native execution performance, such as data compression, game engines, and natural language processing. However, the usage of WebAssembly is not only limited to the web. It is also being extended to desktop applications [6], mobile devices [7], cloud computing [8], IoT ^[12][13][12,13], and embedded devices [14].

2. Security

Environment. WebAssembly modules run in a sandboxed environment which uses fault isolation techniques to separate it from the host environment. As a result of this, modules have to go through APIs to access external resources. For instance, modules that run in the web browser must use JavaScript APIs to interact with the Document Object Model (DOM). Similarly, stand-alone runtimes must use APIs, like WASI, to access system resources like files. In addition to this, modules must adhere to the security policies implemented by its host environment, such as the Same Origin Policy (SOP) ^[23][32] enforced by web browsers, which restricts the flow of information between web pages from different origins. Memory. Unlike native binaries, which have access to the entire memory space allocated to the process, WebAssembly modules only have access to a contiguous region of memory known as linear memory. This memory is untyped and byte-addressable, and its size is determined by the data present in the binary. The size of linear memory is a multiple of a WebAssembly page, each being 64 KiB in size. When a WebAssembly module is instantiated, it uses the appropriate API call to allocate the memory that is needed for its execution. The host environment then creates a managed buffer, typically an ArrayBuffer, to store the linear memory. This means that the WebAssembly module accesses the physical memory indirectly through the managed buffer, which ensures that it can only read and write data within a limited area of the memory. Control Flow Integrity. WebAssembly enforces structured control flow, organizing instructions into well-nested blocks within functions. It restricts branches to the end of surrounding blocks or within the current function, with multi-way branches targeting only pre-defined blocks. This prevents unrestricted go-tos or executing data as bytecode, eliminating attacks like shellcode injection or the misuse of indirect jumps. Additionally, execution semantics ensure safety for direct function calls through explicit indexing and protected returns with a call stack. Indirect function calls undergo runtime checks for type signatures, establishing coarse-grained, type-based control-flow integrity. Additionally, the LLVM compiler infrastructure has been adapted to include a fine-grained control flow integrity feature, specifically designed to support WebAssembly ^[24][33].

3. Vulnerabilities

Inherent vulnerabilities in the source code can lead to subsequent vulnerabilities in WebAssembly modules ^[25][15]. Specifically, buffer overflows in memory-unsafe languages like C and C++ can overwrite constant data or the heap in WebAssembly modules. Despite WebAssembly’s sandboxing, these vulnerabilities allow malicious script injection into the module’s data section, which is accessible via JavaScript APIs. An example of this is the Emscripten API ^[20][22], which allows developers to access data from WebAssembly modules and inject these into the DOM, which can lead to Cross Site Scripting (XSS) attacks ^[26][34]. Notably, two-thirds of WebAssembly binaries are compiled from memory-unsafe languages ^[27][16], and these attacks have been shown to be practical in real-world scenarios ^[25][15]. For instance, Fastly, a cloud platform that offers edge computing services, experienced a 45 min disruption on 8 June 2021, when a WebAssembly binary with a vulnerability was deployed ^[28][35]

4. Smart Contracts

Smart contracts are computer programs that are stored on a blockchain, designed to automatically execute once predetermined conditions are met, eliminating the need for intermediaries. As initially proposed by Nick Szabo in 1994 ^[29][36], long before the advent of Bitcoin, they have since gained widespread popularity alongside the rise of blockchain technology and cryptocurrencies. The inherent properties of blockchain, such as transparency, security, and immutability, make smart contracts particularly appealing for cryptocurrency transactions. This ensures that once the terms of the contract are agreed upon and coded into the blockchain, they can be executed without the possibility of fraud or third-party interference. Smart contracts can facilitate a variety of transactions, from the transfer of cryptocurrency between parties to the automation of complex processes in finance, real estate, and beyond. Due to its near-native performance, WebAssembly has been adopted by blockchain platforms, such as EOSIO [10] and NEAR [11], as their smart contract runtime. Ethereum has included WebAssembly in the roadmap for Ethereum 2.0, positioning it as the successor to the Ethereum Virtual Machine (EVM) [9]. However, as with any technology, smart contracts are not without their challenges and vulnerabilities. The immutable nature of blockchain means that once a smart contract is deployed, it cannot be modified, making the correction of vulnerabilities in its code challenging. Several incidents have highlighted the potential financial and security risks associated with vulnerabilities in WebAssembly smart contracts. For instance, random number generation vulnerabilities led to the theft of approximately 170,000 EOS tokens ^[30][17]. Similarly, the fake EOS transfer vulnerability in the EOSCast smart contract has led to the theft of approximately 60,000 EOS tokens ^[31][18]. The forged transfer notification vulnerability in EOSBet has resulted in the loss of 140,000 EOS tokens ^[31][18]. Based on the average price of EOS tokens at the time of the attacks, the combined financial impact of these three vulnerabilities amounted to roughly USD 1.9 million. Additionally, around 25% of WebAssembly smart contracts have been found to be vulnerable ^[32][37].

5. Cryptojacking

Cryptojacking, also known as drive-by mining, involves using a website visitor’s hardware resources for mining cryptocurrencies without their consent. Previously, cryptojacking was implemented using JavaScript. However, in recent years WebAssembly has been utilized due to its computational efficiency. The year after WebAssembly was released, there was a 459% increase in cryptojacking ^[33][38]. The following year, researchers found that over 50% of all sites using WebAssembly were using it for cryptojacking ^[34][19]. To counter this trend, researchers developed several static and dynamic detection methods for identifying WebAssembly-based cryptojacking. While there are theories suggesting that WebAssembly can be used for other malicious purposes, like tech support scams, browser exploits, and script-based keyloggers ^[35][39], evidence of such misuse in real-world scenarios has not been documented. As a result, there are no analysis techniques for detecting such malicious WebAssembly binaries. Consequently, discussions about malicious WebAssembly binaries in this rpapesearchr mainly refer to crypto mining binaries.