发生了什么？
12月14日，Ledger 的一个软件库 Ledger Connect Kit 遭受了软件供应链攻击。
据称，此次入侵的起因是一名前员工仍保有发布权限，并成为网络钓鱼攻击的受害者，导致其 npm 凭据被盗。npm（即 Node Package Manager）是一种用于导入开源软件库的工具，在 Web 开发行业及 Web3 领域被广泛使用。
此次攻击使恶意版本的相关库得以发布。该库通过内容分发网络（CDN）以实时更新的方式被集成到以太坊生态系统中的众多 Web 应用中，导致恶意代码被注入这些应用。
如何防范？LavaMoat。
LavaMoat 是一套专为解决 Web 应用开发者所面临的软件供应链安全问题而构建的工具集。
LavaMoat 在软件开发生命周期的三个不同节点提供供应链攻击防护：依赖安装时（导入各类库的阶段）、构建时（应用准备通过互联网提供服务的阶段），以及运行时（已构建应用正在运行的阶段）。
LavaMoat 的独特之处在于其运行时防护能力。目前也有其他可用于开发阶段的工具，例如 snyk.io（仅提供已知漏洞警告）和 socket.dev（提供更全面的代码分析，无需等待专家将发现上报至中央数据库）。这些扫描工具发挥着不可或缺的作用，我们建议使用 socket.dev 的 GitHub 集成功能。
然而，它们无法提供任何运行时保障。 因此，我们认为单独使用这些工具是不够的。
LavaMoat 的安全防护机制源于仅向应用依赖项授予指定能力。
这是什么意思？请继续阅读，并观看我们的 Devcon 6 演讲，深入了解 LavaMoat 的工作原理及使用方式。
对象能力模型入门
你可以将一个系统理解为拥有能力：即它能够执行的操作，例如显示信息、读取本地存储的数据，或向其他系统发出请求（如向服务器发起 Web 请求，或向钱包发起交易请求），以及将这些能力委托给其他对象的能力。
在委托能力时，你可以提供该能力的受限版本，这被称为能力衰减。
这三个要素构成了对象能力安全模型的基础。通过使用该模型，你可以清晰了解谁有权执行哪些操作。
Web 应用安全
浏览器在沙箱化应用方面做得相当不错，即将各应用相互隔离，防止它们干扰你的计算机或其他网站。
然而，浏览器并未为 Web 应用开发者提供强健的基础构件，以便进一步对应用的特定部分进行沙箱化，从而防止某些组件危及整个应用。
因此，当你将一个库导入应用时，实际上是在将所有能力委托给该库。更复杂的是，大多数 JavaScript 库不仅包含自身代码，还会引入由不同作者编写的一系列库。
Ledger 攻击详情
@ledger/connect-kit-loader 库是 Ledger 官方推荐的与其产品集成的方式。该软件包是一个轻量级封装器，用于从 CDN 加载其库的最新版本。
这意味着你的应用始终能获取该库的最新版本，但同时也意味着__你实际上是将 Web 应用的控制权委托给了 Ledger 加载器库，而该库又将控制权进一步委托给了托管在 CDN 上的代码。__
你可以将委托链建模如下：
Web 应用 → **@ledger/connect-kit-loader** → jsDelivr CDN → npm → Ledger → Ledger 前员工 → 攻击者
即便如此，这仍是一种简化。仅深入审视其中一个组件，例如 jsDeliver CDN，就能发现令人眼花缭乱的复杂附加服务，它们同样是供应链的组成部分，也是发动攻击的潜在立足点。
使用对象能力安全模型保护应用
如前所述，浏览器本身并未提供太多工具来限制应用子组件的能力，但 JavaScript 语言实际上非常适合完成这项任务。
JavaScript 通过一定的精心设计，允许你构建隔离区（Compartments），从而限制代码的访问权限。可参考 Agoric 的 Hardened Javascript 项目，了解隔离区的具体实现。
MetaMask 的 LavaMoat 供应链安全系统和 MetaMask Snaps 插件系统均基于隔离区构建，以实现代码隔离。
LavaMoat 能否阻止 Ledger 供应链攻击？
问 LavaMoat 是否能阻止此次攻击，有点像问台锯上的触碰即停功能能否在你抓着锯跳崖时保护你——答案是肯定的，跳下去之后你的手指大概率还会完好无损。
从原理上看，@ledgerhq/connect-kit-loader 的工作方式迫使应用开发者放弃许多已有的安全最佳实践。但并非毫无希望。
让 LavaMoat（及其他供应链安全工具）发挥最大作用的最佳方式，是直接使用 @ledgerhq/connect-kit，而非将所有控制权交给加载器。
LavaMoat 的设计初衷是缓解类似 Copay 钱包攻击（又称"event-stream 事件"）的攻击，并能有效防御此类攻击。那么，面对这次不同类型的攻击，LavaMoat 表现如何？
答案遗憾地是那句老话："视情况而定"。由于 LavaMoat 集成于应用运行时的方式，它是面向应用开发者的工具，而非库开发者的工具。这意味着，虽然部分 Web 应用可以借助 LavaMoat 保护自身，但未使用 LavaMoat 的应用仍然存在漏洞。
此外，LavaMoat 仅执行开发者指定的策略。如果你配置了不安全的策略，LavaMoat 将无法保护你。
让我们来看看，使用了 LavaMoat 的应用如何能够抵御此次攻击。
LavaMoat 使用策略文件来确定依赖项应获得哪些能力（以全局平台 API 的形式）。为简化这一过程，你可以让 LavaMoat 分析一个软件包，并自动判断该包运行所需的能力，这被称为静态分析。
虽然静态分析在理解代码意图方面并不完美，但 LavaMoat 使用静态分析仅是为了便利，帮助你生成策略文件，而非在运行时用于执行策略。生成的策略随后由开发者审查、调整并批准。
针对最初的问题，一个答案是：是的，LavaMoat 可以通过阻止软件包在运行时加载新代码的能力，保护你的应用和用户免受供应链攻击。 前提是你已正确配置，并且使用的依赖项不要求过于强大的能力。
另一个答案是：不能。如果你将 LavaMoat 配置为允许 **@ledgerhq/connect-kit-loader** 正常运行，并允许其注入 script 标签运行任意代码（在 LavaMoat 运行时之外），攻击仍然会成功。 这是 LavaMoat 在向后兼容性与更安全系统之间所做的权衡。LavaMoat 具有高度灵活性，以实现最大兼容性，让你无需从头重写即可将其集成到应用中。应用开发者仍有责任制定合理的策略并选择合理的依赖项。LavaMoat 允许你有选择地提供全局浏览器 API，但某些全局 API 所包含的权限过于强大，无法安全地授予第三方软件包。我们正在研究进一步限制这些权限的多种方案，但要为那些不主动限制自身控制权的软件包提供开箱即用的解决方案，仍是一项挑战。
LavaMoat 的一项名为 Scuttling 的功能，会干扰由 @ledgerhq/connect-kit-loader 加载的恶意包和原始包。Scuttling 会移除在 LavaMoat 沙箱外运行的代码对能力的访问权限。这将从根本上阻止你使用不安全的 @ledgerhq/connect-kit-loader，并推动你直接使用并自主管理 @ledgerhq/connect-kit 的更新流程，确保你对应用中运行的代码保持完全控制。
LavaMoat 并非万能，但它能在你原本毫无掌控力的地方赋予你控制权和可见性。LavaMoat 应只是你安全策略中的工具之一。
以下是你现在就可以采取的措施，以抵御明天可能发生的攻击：
添加免费的 Socket.dev 依赖监控（2 分钟）。
添加对资源进行严格控制的 CSP（30 分钟）。
AI 翻译。可能包含错误。请务必核实信息。
