WebAssembly入门第三部分：WASM的可移植性和安全性如何工作
查看WebAssembly（WASM）的可移植性和安全性模型在这个初学者指南中的工作原理。
这两个都是高级的WebAssembly（WASM）主题。我们建议您阅读我们的WebAssembly入门系列中的前两个主题。
- WebAssembly for Beginners – Part 1: An Introduction To WASM
- WebAssembly for Beginners – Part 2: Goals, Key Concepts, and Use Cases
让我们开始吧。
WebAssembly的可移植性
WebAssembly的可移植性使其成为Web的理想选择。实际上，您可以将WASM定义为一种可移植的沙箱平台。
此外，其二进制格式使其能够在各种指令集架构和操作系统上执行。这意味着您不仅可以在Web上使用WASM，还可以在Web之外使用。
为了理解WASM的可移植性，我们将讨论以下内容：
- 本地、有限和不确定的环境。
- 特定的执行环境特性
- WASM的Web和非Web可移植性
本地、有限和不确定的
WASM需要一个高效的执行和适当的本地、有限和不确定的环境。不确定性是指算法/编译器/环境即使对于相同的输入也会产生不同的行为或结果的计算。它是确定性算法的相反。
另外，另外两个方面的有限和本地与不确定性执行相关。为了使不确定性执行起作用，您需要定义明确的使用案例，这些案例是“有限的”。
此外，这些执行是“本地的”，不会对环境之外产生影响。阅读官方的nondeterminism in the WebAssembly文档以了解更多信息。
特定执行环境特性
为了使WebAssembly具有可移植性，它假设执行环境提供以下特性：
- 以字节为粒度的内存寻址和8位字节。
- 32位二进制补码有符号整数。可选64位。
- 通过非对齐内存访问或可靠的陷阱进行软件仿真。
- 支持32位和64位浮点数，如IEEE 754-2008定义。
- 保证以前进的方式执行所有线程。
- 对于64位访问，wasm64应提供无锁原子内存操作符。
- 无锁原子内存操作符包括8、16和32位的访问。
- wasm64支持高于4 GiB的线性内存，具有64位索引或指针。
- 小端字节顺序。
包括Chrome、Edge、Firefox和WebKit在内的所有主要浏览器都支持所有这些环境要求。
此外，WebAssembly正在快速发展。WASM社区组和W3C WebAssembly工作组正在努力推进其标准化。这意味着这些要求中的任何一个都可能在将来发生变化。
WASM的Web和非Web可移植性
WebAssembly的主要目的是在Web和非Web上提供可移植性和本地性能。在本节中，我们将看看WASM是如何实现这一点的。
#1. Web嵌入
WASM与Web生态系统完美集成，包括Web的安全模型、Web可移植性和Web API。此外，它还必须有足够的空间进行创意开发（阅读WebAssembly for Beginners – Part 2了解其目标）
那么，WASM如何与Web兼容？它利用JavaScript API，使开发人员可以轻松地使用JavaScript编译WebAssembly模块。它还负责存储和检索编译器模块、管理从编译器模块导入、管理内存等等。
要了解有关WASM如何实现高级Web兼容性的更多信息，请阅读此链接：Web Embedding – WebAssembly。
#2. 非Web嵌入
正如之前提到的，WASM也适用于非Web环境。作为开发者或企业，您可以创建高性能的应用程序或编写需要性能优化的应用程序部分。例如，您可以在IoT devices、数据中心服务器和桌面/移动应用程序上使用它。
由于非Web应用程序无法使用Web API，它们依赖于WASM’s dynamic linking。您还需要使用特性测试，这是一种软件开发过程，测试特性的多个变体，以确定用户体验最佳的选项。此外，开发者可以使用JavaScript VM简化非Web嵌入或开发应用程序而无需使用它。
要了解更多信息，请阅读Non-Web Embeddings – WebAssembly。
WebAssembly安全性
WebAssembly是一种二进制格式解决方案，提供了类似本地代码的性能。它在Web上运行良好，但也可以进行调优以在非Web嵌入中使用。这使得WASM在服务、解决方案和流程中广泛可用。然而，这也意味着存在更多的安全挑战。
WASM安全挑战和风险
尽管WebAssembly被认为是安全和高效的，但它也存在多个安全风险，包括：
- WebAssembly沙盒
- 内存管理
- 代码混淆
- 完整性检查
#1. WebAssembly沙盒
WASM在Web浏览器中执行，就像JavaScript一样。它使用与JavaScript相同的虚拟机（VM）。沙盒有效地提供了安全的执行环境，并阻止了底层的运行情况。
因此，如果JavaScript/WebAssembly代码包含恶意代码，很难检测到，因为它是一个黑盒子。此外，WASM代码以可运行的二进制格式存在，运行速度更快，这使得antivirus solutions很难查找到任何恶意代码。例如，代码可以包含不需要的广告或将用户重定向到不需要的malware站点。
此外，WebAssembly在Web上过度依赖JavaScript运行，这也意味着它继承了JavaScript的漏洞。这就是为什么作为开发者，在编写WASM代码时必须遵循JavaScript的安全预防措施和措施。
#2. 内存管理
WASM中的内存管理是棘手的。首先，它不直接访问物理内存，因为它在虚拟机中执行。这就是为什么它使用主机机器的内存。
其次，清理WASM中的内存需要一个显式的过程，而相比之下，JavaScript会自行清理。
此外，当WASM函数将输出返回给JavaScript时，它返回一个指向分配的WASM内存空间内位置的指针。因此，如果声明的内存变满，WASM程序可能会崩溃，破坏用户的体验。为了防止这种情况，程序员需要使用调试器来调试他们的代码，或者使用诸如emscripten的工具链。
#3. 代码混淆
WASM的沙盒执行使其代码混淆。此外，WASM的二进制格式也不可读，这使得查找恶意代码变得困难。
这使得WebAssembly代码由于其缺乏可读性的格式而难以调试。这打开了许多安全漏洞，包括隐藏代码以窃取敏感信息或进行代码注入以控制主机机器的能力。
#4. 完整性检查
通过Web传输的任何数据都容易受到数据篡改的攻击。例如，黑客可以执行中间人攻击来更改数据值。对于WASM来说，这是一个问题，因为它没有适当的方法来进行完整性检查。
然而，它可以与JavaScript一起进行完整性检查。识别潜在的WASM代码漏洞的另一种方法是使用集成工具，例如Jit。它确保代码没有恶意行为，并且不能影响应用程序或周围的云基础架构。
了解WASM安全模型
WebAssembly（Web组件）非常重视安全性。这就是为什么在官方WASM文档中提到他们的安全模型可以实现两个重要目标：
- 确保没有错误或恶意的模块影响用户
- 确保开发人员可以降低任何安全风险并创建安全的应用程序，同时始终保持第一点。
WASM安全模型知道WebAssembly应用程序在执行时独立运行而无法逃脱其沙箱环境。然而，API可以打开攻击主机环境的途径。
另一种容错技术包括以有限的期望确定地执行应用程序。通过确保这两个条件，大多数应用程序执行被认为是安全的。
为了提高安全性，开发人员应该强制执行同源策略以进行信息流。如果您为非Web开发，您必须使用POSIX安全模型。如果您想了解更多有关其安全模型的信息，请访问：Security – WebAssembly。
WebAssembly系统接口（WASI）
WASI（WebAssembly系统接口）在WASM非Web嵌入中也起着至关重要的作用，因为它提高了安全性。它是一个模块化的系统接口，提供了令人兴奋的安全特性和可移植性。
实际上，它现在是WebAssembly的一部分，因此被标准化。由于WASI，WASM在不同的边缘/服务器计算领域得到了广泛采用。此外，WASI简化了从Web嵌入环境转移到非Web嵌入环境时的安全性。
最后的话
WebAssembly的可移植性和安全性是两个重要的主题。在WebAssembly入门系列的第3部分中，我们试图简化并分解它，特别是针对初学者。
接下来，您可以查看开发人员和学习者的 JavaScript cheat sheets。