应用生命周期威胁

Tauri 应用程序在应用程序生命周期的不同时间点由许多部分组成。在这里，我们描述了经典威胁以及您应该如何应对它们。

所有这些不同的步骤将在以下部分中描述。

Threat Stages During Development

上游威胁

Tauri 是您项目的直接依赖项，我们对提交、审查、拉取请求和发布保持严格的作者控制。我们尽力维护最新的依赖项，并采取行动进行更新或 Fork 并修复。其他项目可能没有得到很好的维护，甚至可能从未经过审计。

在集成它们时，请考虑它们的健康状况，否则，您可能在不知情的情况下采用了架构债务。

保持应用程序最新

当将您的应用程序发布到外部时，您也在发布包含 Tauri 的捆绑包。影响 Tauri 的漏洞可能会影响您应用程序的安全性。通过将 Tauri 更新到最新版本，您可以确保关键漏洞已得到修补，并且无法在您的应用程序中被利用。另请务必保持您的编译器 (rustc) 和转译器 (nodejs) 为最新版本，因为通常存在已解决的安全问题。这对于您的一般开发系统也是如此。

评估你的依赖

虽然 NPM 和 Crates.io 提供了许多方便的软件包，但选择值得信赖的第三方库（或在 Rust 中重写它们）是您的责任。如果您确实使用了受已知漏洞影响或未维护的过时库，您的应用程序安全性和良好的睡眠可能会受到威胁。

使用诸如 npm audit 和 cargo audit 之类的工具来自动化此过程，并依靠安全社区的重要工作。

rust 生态系统中最近的趋势，例如 cargo-vet 或 cargo crev，可以帮助进一步降低供应链攻击的可能性。要了解您站在谁的肩膀上，您可以使用 cargo supply chain 工具。

我们强烈建议的一种做法是，始终仅从 git 使用哈希修订版本（最好）或命名标签（次好）来使用关键依赖项。这适用于 Rust 以及 Node 生态系统。

开发威胁

我们假设您（开发人员）关心您的开发环境。您有责任确保您的操作系统、构建工具链和相关依赖项保持最新且合理安全。

我们所有人面临的真正风险是所谓的“供应链攻击”，通常认为是对项目直接依赖项的攻击。然而，野外越来越多的攻击直接针对开发机器，您最好正面解决这个问题。

开发服务器

Tauri 应用程序前端可以使用许多 Web 框架进行开发。这些框架中的每一个通常都带有自己的开发服务器，该服务器通过开放端口将前端资源暴露给本地系统或网络。这允许前端在 WebView 或浏览器中进行热重载和调试。

实际上，默认情况下，此连接通常既未加密也未经过身份验证。内置的 Tauri 开发服务器也是如此，并将您的前端和资源暴露给本地网络。此外，这允许攻击者将他们自己的前端代码推送到与攻击者在同一网络中的开发设备。根据暴露的功能类型，这可能导致最坏情况下的设备泄露。

您应该仅在您可以安全地暴露开发设备的受信任网络上进行开发。如果这不可能，您必须确保您的开发服务器对与您的开发设备的连接使用双向身份验证和加密（例如 mTLS）。

加固开发机器

加固您的开发系统取决于各种因素和您的个人威胁模型，但我们建议遵循一些通用建议

永远不要将管理帐户用于日常任务（如编码）
永远不要在开发机器上使用生产密钥
防止密钥被检入源代码版本控制
使用安全硬件令牌或类似物来减少受损系统的影响
保持您的系统更新
将您安装的应用程序保持在最低限度

在 awesome security hardening collection 中可以找到更实用的程序集合。

您当然可以虚拟化您的开发环境以阻止攻击者，但这无法保护您免受针对您的项目而非仅仅是您的机器的攻击。

确保源码控制的身份验证和授权

如果您像大多数开发人员一样工作，则使用源代码版本控制工具和服务提供商是开发过程中的重要步骤。

为了确保您的源代码不会被未经授权的行为者修改，重要的是了解并正确设置源代码版本控制系统的访问控制。

此外，请考虑要求所有（常规）贡献者签署他们的提交，以防止恶意提交归因于未受损或非恶意的贡献者的情况。

构建时威胁

现代组织使用 CI/CD 来制造二进制工件。

您需要能够完全信任这些远程（和第三方拥有的）系统，因为它们有权访问源代码、密钥，并且能够修改构建，而您无法可验证地证明生成的二进制文件与您的本地代码相同。这意味着要么您信任信誉良好的提供商，要么在您自己控制的硬件上托管这些系统。

在 Tauri，我们提供了一个 GitHub Workflow 用于在多个平台上构建。如果您创建自己的 CI/CD 并依赖第三方工具，请注意您未明确固定的操作版本。

您应该为您要发布的平台对二进制文件进行签名。虽然这可能很复杂且设置成本较高，但最终用户期望您的应用程序确实来自您。

如果加密密钥正确存储在硬件令牌上，则受损的构建系统将无法泄漏所涉及的签名密钥，但可以使用它们来签署恶意版本。

可复现构建

为了在构建时对抗后门注入，您需要构建是可复现的，以便您可以验证构建资产在您本地或在另一个独立提供商处构建时是否完全相同。

第一个问题是 Rust 默认情况下不能完全可靠地生成可复现的构建。它在理论上支持这一点，但仍然存在错误，并且最近在一个版本中崩溃了。

您可以在 rust 项目的公共错误跟踪器中跟踪当前状态。

您将遇到的下一个问题是，许多常见的前端捆绑器也不会产生可复现的输出，因此捆绑的资源也可能破坏可复现的构建。

这意味着您默认情况下不能完全依赖可复现的构建，并且很遗憾需要完全信任您的构建系统。

分发威胁

我们已尽力使应用程序的热更新尽可能直接和安全地发布。但是，如果您失去对清单服务器、构建服务器或二进制托管服务的控制，那么一切都无法保证。

如果您构建自己的系统，请咨询专业的 OPS 架构师并正确构建它。

如果您正在为 Tauri 应用程序寻找另一个受信任的分发解决方案，我们的合作伙伴 CrabNebula 提供了一种服务：https://crabnebula.dev/cloud

运行时威胁

我们假设 webview 是不安全的，这促使 Tauri 在加载不受信任的用户区内容的情况下实施多项关于 webview 访问系统 API 的保护措施。

使用内容安全策略将锁定 Webview 可以进行的通信类型。此外，功能可以防止不受信任的内容或脚本访问 Webview 中的 API。

我们还建议设置一种简单而安全的方式来报告漏洞，类似于我们的流程。