正如我們 最近解釋的，WebAssembly 是一種用于以任何語言編寫的二進制格式的軟件，旨在最終無需更改就能在任意平臺運行。WebAssembly 的第一個應用是在 Web 瀏覽器中，以使網站更快、更具交互性。WebAssembly 有計劃推向 Web 之外，從各種服務器到物聯網(IoT)，其創造了很多機會，但也存在很多安全問題。這篇文章是對這些問題和 WebAssembly 安全模型的一篇介紹性概述。

WebAssembly 跟 JavaScript 很像

在 Web 瀏覽器內部，WebAssembly 模塊由執行 JavaScript 代碼的同一 虛擬機VM 管理。因此，WebAssembly 和 JavaScript 一樣，造成的危害也是相同的，只是效率更高，更不易被察覺。由于 JavaScript 是純文本，運行前需要瀏覽器編譯，而 WebAssembly 是一種可立即運行的二進制格式，運行速度更快，也更難被掃描出(即使使用殺毒軟件)其中的惡意指令。

WebAssembly 的這種 “代碼混淆” 效果已經被用來彈出不請自來的廣告，或打開假的 “技術支持” 窗口，要求提供敏感數據。另一個把戲則是自動將瀏覽器重定向到包含真正危險的惡意軟件的 “落地” 頁。

最后，就像 JavaScript 一樣，WebAssembly 可能被用來 “竊取” 處理能力而不是數據。2019 年，對 150 個不同的 WASM 模塊的分析 發現，其中約 32% 被用于加密貨幣挖掘。

WebAssembly 沙盒和接口

WebAssembly 代碼在一個由虛擬機(而不是操作系統)管理的 沙盒 中封閉運行。這使它無法看到主機，也無法直接與主機交互。對系統資源(文件、硬件或互聯網連接)的訪問只能通過該虛擬機提供的 WebAssembly 系統接口WebAssembly System Interface(WASI) 進行。

WASI 不同于大多數其他應用程序編程接口(API)，它具有獨特的安全特性，真正推動了 WASM 在傳統服務器和邊緣Edge計算場景中的采用，這將是下一篇文章的主題。在這里，可以說，當從 Web 遷移到其他環境時，它的安全影響會有很大的不同。現代 Web 瀏覽器是極其復雜的軟件，但它是建立在數十年的經驗和數十億人的日常測試之上的。與瀏覽器相比，服務器或物聯網(IoT)設備幾乎是未知領域。這些平臺的虛擬機將需要擴展 WASI，因此，肯定會帶來新的安全挑戰。

WebAssembly 中的內存和代碼管理

與普通的編譯程序相比，WebAssembly 應用程序對內存的訪問非常受限，對它們自己也是如此。WebAssembly 代碼不能直接訪問尚未調用的函數或變量，不能跳轉到任意地址，也不能將內存中的數據作為字節碼指令執行。

在瀏覽器內部，WASM 模塊只能獲得一個連續字節的全局數組(線性內存linear memory)進行操作。WebAssembly 可以直接讀寫該區域中的任意位置，或者請求增加其大小，但僅此而已。這個線性內存linear memory也與包含其實際代碼、執行堆棧、當然還有運行 WebAssembly 的虛擬機的區域分離。對于瀏覽器來說，所有這些數據結構都是普通的 JavaScript 對象，使用標準過程與所有其他對象隔離。

結果還好，但不完美

所有這些限制使得 WebAssembly 模塊很難做出不當行為，但也并非不可能。

沙盒化的內存使 WebAssembly 幾乎不可能接觸到 外部 的東西，也使操作系統更難防止 內部 發生不好的事情。傳統的內存監測機制，比如 堆棧金絲雀Stack Canaries 能注意到是否有代碼試圖擾亂它不應該接觸的對象，但在這里沒用。

事實上，WebAssembly 只能訪問自己的線性內存linear memory，但可以直接訪問，這也可能為攻擊者的行為 提供便利。有了這些約束和對模塊源代碼的訪問，就更容易猜測覆蓋哪些內存位置可能造成最大的破壞。破壞局部變量似乎也是 可能的，因為它們停留在線性內存linear memory中的無監督堆棧中。

2020 年的一篇關于 WebAssembly 的二進制安全性 的論文指出，WebAssembly 代碼仍然可以在設定的常量內存中覆蓋字符串文字。同一篇論文描述了在三個不同的平臺(瀏覽器、Node.JS 上的服務端應用程序，和獨立 WebAssembly 虛擬機的應用程序)上，WebAssembly 可能比編譯為原生二進制文件時更不安全的其他方式。建議進一步閱讀此主題。

通常，認為 WebAssembly 只能破壞其自身沙盒中的內容的想法可能會產生誤導。WebAssembly 模塊為調用它們的 JavaScript 代碼做繁重的工作，每次都會交換變量。如果模塊在這些變量中的任意一處寫入不安全的調用 WebAssembly 的 JavaScript 代碼，就 會 導致崩潰或數據泄露。

未來的方向

WebAssembly 的兩個新出現的特性：并發 和內部垃圾收集，肯定會影響其安全性(如何影響以及影響多少，現在下結論還為時過早)。

并發允許多個 WebAssembly 模塊在同一個虛擬機中并行。目前，只有通過 JavaScript web workers 才能實現這一點，但更好的機制正在開發中。安全方面，他們可能會帶來 以前不需要的大量的代碼，也就是更多出錯的方法。

為了提高性能和安全性，我們需要一個 本地的垃圾收集器，但最重要的是，要在經過良好測試的瀏覽器的 Java 虛擬機之外使用 WebAssembly，因為這些虛擬機無論如何都會在自己內部收集所有的垃圾。當然，甚至這個新代碼也可能成為漏洞和攻擊的另一個入口。

往好處想，使 WebAssembly 比現在更安全的通用策略也是存在的。這些策略包括：編譯器改進、棧/堆和常量數據的 分離 的線性存儲機制，以及避免使用 不安全的語言(如 C)編譯 WebAssembly 模塊代碼。