在本篇入門指南中,我們將深入探討 WebAssembly (WASM) 的可移植性和安全模型的運作機制。
這兩者皆屬於進階的 WebAssembly (WASM) 主題。如果您是初學者,我們建議您先閱讀 WebAssembly 入門系列的 前兩篇文章,以便建立基礎。
讓我們開始吧!
WebAssembly 的可移植性
WebAssembly 的可移植性使其非常適合在網路上使用。 實際上,WASM 可以被視為一個可移植的沙盒平台。
此外,其二進制格式使其能夠在各種不同的指令集架構和作業系統上執行。 這意味著您不僅可以在網路上使用 WASM,也可以在網路之外使用。
為了更好地理解 WASM 的可移植性,我們將探討以下幾個方面:
- 局部性、有限性和非決定性環境。
- 具體的執行環境特徵
- WASM 在網路和非網路環境中的可移植性
局部性、有限性和非決定性
WASM 需要高效的執行,並在局部、有限和非決定的環境中運行。所謂非決定性計算,指的是即使輸入相同,算法/編譯器/環境也可能輸出不同的行為或結果。這與決定性算法截然相反。
其他兩個方面,有限性和局部性,與非決定性執行有關。要使非決定性執行有效,您需要定義明確的「有限」用例。
此外,這些執行是「局部」的,在環境之外不會產生影響。欲了解更多信息,請參閱 WebAssembly 官方文件中關於非決定性的說明。
具體的執行環境特徵
為了實現 WebAssembly 的可移植性,它假設執行環境提供以下特性:
- 以位元組為單位尋址的記憶體粒度,且每個位元組為 8 位。
- 32 位二進制補碼帶符號整數,可選 64 位。
- 能夠透過未對齊的記憶體存取或可靠的陷阱進行軟體模擬。
- 支援 IEEE 754-2008 中定義的 32 位和 64 位浮點數。
- 保證所有執行緒都能向前推進。
- 對於 64 位存取,wasm64 應提供無鎖原子記憶體操作符。
- 無鎖原子記憶體操作符包括 8 位、16 位和 32 位存取。
- wasm64 支援超過 4 GiB 的線性記憶體,具有 64 位索引或指標。
- 小端位元組順序。
包括 Chrome、Edge、Firefox 和 WebKit 在內的所有主流瀏覽器都支援這些環境要求。
此外,WebAssembly 正快速發展。WASM 社區組和 W3C WebAssembly 工作組正努力實現其標準化。這意味著這些要求中的任何一個都可能在未來發生變化。
WASM 在網路和非網路環境中的可移植性
WebAssembly 的主要目標是在網路和非網路環境中提供可移植性和本地效能。在本節中,我們將探討 WASM 如何實現這一目標。
#1. 網路嵌入
WASM 與網路生態系統(包括網路的安全模型、網路可移植性和 Web API)良好整合。此外,它還必須有足夠的空間供未來的創造性開發(請閱讀《WebAssembly 入門 – 第二部分》以了解其目標)。
那麼,WASM 如何實現與網路的相容性呢? 它利用 JavaScript API,使開發人員能夠輕鬆地使用 JavaScript 進行 WebAssembly 模組編譯。 它還負責儲存和檢索編譯後的模組、管理從編譯模組的導入、管理記憶體等。
若要了解更多關於 WASM 如何實現進階網路相容性的資訊,請參閱:Web 嵌入 – WebAssembly。
#2. 非網路嵌入
如前所述,WASM 也適用於非網路環境。作為開發人員或企業,您可以建立高效能應用程式,或編寫需要效能調整的應用程式部分。例如,您可以在物聯網裝置、資料中心伺服器和桌面/行動應用程式中使用它。
由於非網路應用程式無法使用 Web API,因此它們依賴於 WASM 的動態連結。您還需要使用功能測試,這是一種軟體開發流程,可以測試功能的各種變體,以了解什麼對用戶體驗最有利。此外,開發人員可以使用 JavaScript VM 來簡化非網路嵌入,或在沒有它的情況下開發應用程式。
若要了解更多資訊,請參閱非網路嵌入 – WebAssembly。
WebAssembly 安全
WebAssembly 是一種二進制格式的解決方案,可提供類似本機的效能。它在網路上的運行效果很好,但也可以進行微調以在非網路環境中運行。這使得 WASM 在服務、解決方案和流程中被廣泛使用。然而,這也意味著更多的安全挑戰。
WASM 的安全挑戰和風險
儘管 WebAssembly 被認為是安全高效的,但它也存在多種安全風險,包括:
- WebAssembly 沙箱
- 記憶體管理
- 程式碼混淆
- 完整性檢查
#1. WebAssembly 沙箱
WASM 在網路瀏覽器中執行,就像 JavaScript 一樣。它使用與 JavaScript 相同的虛擬機 (VM)。沙箱有效地提供了一個安全的執行環境,並阻礙了幕後運行。
因此,如果 JavaScript/WebAssembly 程式碼包含惡意程式碼,則很難檢測到,因為它是一個黑盒子。此外,WASM 程式碼採用可以立即執行的二進制格式;它執行得更快,使得防病毒軟體難以查找任何惡意程式碼。例如,程式碼可能包含不必要的廣告,或將用戶重新導向到不必要的惡意軟體網站的能力。
此外,WebAssembly 過度依賴 JavaScript 在網路上運行,也意味著它繼承了 JavaScript 的漏洞。這就是為什麼身為開發人員,在編寫 WASM 程式碼時必須遵循 JavaScript 的安全預防措施。
#2. 記憶體管理
WASM 中的記憶體管理非常棘手。首先,它在 VM 中執行時不直接存取實體記憶體。這就是它使用主機記憶體的原因。
其次,在 WASM 中清理記憶體需要一個明確的過程,而相比之下,JavaScript 會自行清理。
此外,當 WASM 函式將輸出傳回給 JavaScript 時,它會傳回一個指向已分配的 WASM 記憶體空間內某個位置的指標。因此,如果宣告的記憶體已滿,WASM 程式可能會崩潰,進而破壞使用者體驗。為了防止這種情況發生,程式設計人員需要使用消毒劑來除錯他們的程式碼,或使用 emscripten 等工具鏈。
#3. 程式碼混淆
WASM 的沙箱執行使其程式碼變得模糊。此外,WASM 二進制格式也不是人類可讀的,因此很難進行逆向工程,而逆向工程是識別惡意程式碼所必需的。
由於缺乏人類可讀的格式,這些使得 WebAssembly 程式碼難以除錯。這開啟了許多安全漏洞,包括駭客隱藏竊取敏感資訊的程式碼或進行程式碼注入以接管主機的能力。
#4. 完整性檢查
透過網路傳輸的任何資料都容易受到資料篡改的影響。例如,駭客可以執行中間人攻擊來變更資料值。這是 WASM 的一個問題,因為它沒有正確的方法來進行完整性檢查。
但是,它可以與 JavaScript 一起執行完整性檢查。識別潛在 WASM 程式碼漏洞的另一種方法是使用整合工具,例如 Jit。它可以確保程式碼不受不良行為者的影響,並且不會影響應用程式或周圍的雲端基礎架構。
了解 WASM 安全模型
WebAssembly 非常重視安全性。這就是為什麼在官方 WASM 文件中,他們提到其安全模型負責兩個重要目標:
WASM 安全模型知道 WebAssembly 應用程式獨立執行,同時無法逃脫其沙箱環境。但是,API 可以開闢一條攻擊主機環境的途徑。
另一種容錯技術包括以有限的期望確定性地執行應用程式。透過確保這兩個條件,大多數應用程式的執行都被認為是安全的。
為了提高安全性,開發人員應對資訊流實施同源策略。如果您正在進行非網路開發,則必須使用 POSIX 安全模型。如果您想閱讀更多關於其安全模型的資訊,請參閱:安全 – WebAssembly。
WebAssembly 系統介面 (WASI)
WASI(WebAssembly 系統介面)在 WASM 非網路嵌入中也扮演著至關重要的角色,因為它可以提高安全性。 它是一個模組化系統介面,提供令人興奮的安全特性和可移植性。
事實上,它現在是 WebAssembly 系統介面子群章程的一部分,因此是標準化的。 由於 WASI,WASM 被廣泛應用於不同的邊緣/伺服器運算領域。 此外,WASI 簡化了從網路嵌入環境轉移到非網路嵌入時的安全性。
最後的話
WebAssembly 的可移植性和安全性是兩個重要的主題。 在面向初學者的 WebAssembly 系列的第三部分中,我們試圖對其進行簡化和分解,特別是針對初學者。
接下來,您可以查看面向開發人員和學習者的 JavaScript 備忘單。