供应链攻击是 JavaScript 生态系统的大问题。在这篇短文中,我将概述一个简单的安全措施,可以由所有 JavaScript 运行时(浏览器内和浏览器外)实现。这将防止当今困扰 JavaScript 生态系统的大多数供应链攻击。
这是最近发生的网站被黑客攻击的事件:
问题的核心是JavaScript 模块继承了调用它们的应用程序或模块的权限。这对于浏览器内运行时和浏览器外运行时都是一个问题。
应用程序所依赖的模块版本可能会在应用程序作者不知情的情况下发生更改,这一事实使问题变得更加复杂。因此,即使所有依赖的代码都已经被彻底审查(这本身就是一个巨大的努力),如果依赖版本没有被锁定,这个努力就会被浪费。
为什么不锁定版本并使用基于 semver 的依赖项?嗯,这主要是因为如果模块发布者发布了错误修复,那么最好使用修复的代码。这也是 esm.sh 等 JavaScript CDN 支持 semvers 的重要原因之一。
网络浏览器是沙盒执行环境,因此网站导入的第三方 JavaScript 模块 (3JM) 不会对最终用户的设备造成任何损害。
尽管如此,3JM 可以在未经网站同意的情况下使用设备的计算资源并发出网络请求进行比特币挖矿等。
一些浏览器外运行时(例如 Deno)确实实施了限制 JavaScript/TypeScript 应用程序权限的措施。但由于以下原因,这些措施还不够:
目前,安全团队已经建立了自动化流程,用于查找在 NPM 等知名注册表上发布的模块中的漏洞。这种安全措施有几个缺点:
为了解决这些问题,我提出了一个新的每模块权限系统,该系统向后兼容 JS/TS 应用程序当前的工作方式。
这涉及一个新的可选权限配置,每个应用程序和模块都可以在其 deno.json / deno.jsonc / package.json 文件中声明。权限有 2 部分:
以下是 JS/TS 运行时如何使用权限:
{ "self": { "read": {"allow": [], "deny": []}, "write": {"allow": [], "deny": []}, "net": {"allow": [], "deny": []}, "env": {"allow": [], "deny": []}, "run": {"allow": [], "deny": []} }, "imports": { "jsr:@org/module@1.0.0": { "read": {"allow": [], "deny": []}, "write": {"allow": [], "deny": []}, "net": {"allow": [], "deny": []}, "env": {"allow": [], "deny": []}, "run": {"allow": [], "deny": []} }, "https://cdn.example/org/module@1.0.0": { "read": {"allow": [], "deny": []}, "write": {"allow": [], "deny": []}, "net": {"allow": [], "deny": []}, "env": {"allow": [], "deny": []}, "run": {"allow": [], "deny": []} }, "[default]": { "read": {"allow": [], "deny": []}, "write": {"allow": [], "deny": []}, "net": {"allow": [], "deny": []}, "env": {"allow": [], "deny": []}, "run": {"allow": [], "deny": []} } } }
这看起来非常简单。 JS/TS 语言无需修改。如果没有权限配置,那么我们会回到当前的情况,即应用程序及其依赖关系图都具有命令行参数提供的权限 ∎
以上是防止对 JavaScript 生态系统的供应链攻击的详细内容。更多信息请关注PHP中文网其他相关文章!