重新整理 | 郑丽媛
公司出品 | CSDN（ID：CSDNnews）
近年，频密发生的 npm 物流配送反击令开发人员们筋疲力尽：
盛行 npm 包 faker.js 和 colors.js 的译者为杯葛“开放源码白嫖”而隐身工程项目，引致数百个应用领域崩盘；
著名 npm 包 node-ipc 的译者以“和平主义”名来，向工程项目转化成蓄意代码；
反击者特别针对 Azure 开发人员，建立了向 200 数个蓄意 npm 模版盗取 PII（个人身份重要信息）；
SS为“RED-LILI”的骇客策动了小规模 npm 物流配送反击，口气发布近 800 个蓄意 npm 包。
这一连串接二连三的 npm 物流配送反击令许多人开始揣测：Node.js 包到底还值得称赞信赖吗？对于那个难题，著名开放源码架构 sharedb/ottypes 译者 Seph Gentle 通过一则该文得出了他的提问：“Node.js 包已不值得称赞信赖。”
npm 的显然难题
该文结尾，Seph Gentle 就特别强调：“npm 的显然难题是，你加装的大部份应用领域软件都可以在计算机系统上继续执行任何人操作方式。”
而那个“任何人”主要包括：写作笔记本电脑上的大部份文档，比如邮件、公钥等大部份文本；撰稿、删掉或是给文档加密码锁；在网络上做任何人它想做的事；运转子民主化、更动作业系统增设、加装关键性笔记机内……
举个范例，原本你只是想单纯加装一个 leftpad 组件图省钱，结果它只不过保有对伺服器和页面的完备出访职权，主要包括访问我们的隐私数据。
当然了，可能大多数的 Node.js 包和组件都没有蓄意，但不得不说，这种仿佛敞开大门欢迎大部份人来参观的设定有一定隐患。Seph Gentle 对此感慨：“坦率地说，我很惊讶供应链反击居然没有更频密地发生。”
不过，正如 Seph Gentle 所说，即便知道那个隐患，我们也很难先发制人地找出哪些 Node.js 包有难题，或是哪些开发人员不值得称赞信赖。
说到这里，可能会有人提到与 Node.js 一样同为 JavaScript 运转时却更为安全的 Deno：Deno 对于各种出访权（文档、网络和环境）都有严格限制。但 Seph Gentle 认为：“我认为它（Deno）还不够好。”
Deno 允许开发人员在命令行中指定程序可继续执行哪些类型的操作方式、出访哪些职权等，但其不足之处在于允许范围过大了。比如，开发人员正在制作一个网络伺服器，难道就要允许 leftpad 可出访全部网络？同理，即便开发人员正在制作文档伺服器，leftpad 也不应出访其全部文档系统。
Seph Gentle 对此总结道：“Deno 或许是一个好的开始，但它分得还不够细。”因此，Seph Gentle 还是想特别针对 Node.js 当前的处理方式提出可改进的地方，而此时，他注意到了 OpenBSD API 的 pledge 程序。
功能令牌或许是突破口？
OpenBSD API 中 pledge 程序的工作方式是：当程序开始但还未做任何人事情之前，开发人员需做出一套设定以确保该程序将仅使用某些资源，比如：“我保证那个程序不会出访 /some/path 之外的任何人文档，也不会连接到除 example.com 之外的其他节点。”这样的话，即便该程序被入侵，也无法实行职权之外的行为。
在此灵感启发下，Seph Gentle 认为 Node.js 的工作方式可以做出一些改变，以彻底解决现存隐患：
可添加一个名为 capabilities 的新内置 Node.js 库，用来分发功能令牌，且该令牌只能由 capabilities 库建立。
在进行任何人特权操作方式时（如出访文档系统、网络、硬件、生成子民主化、加载原生 npm 模块等等），调用者需在相关函数中添加相符的功能令牌。
每个功能令牌都要设定一个范围，指定该令牌的持有者可以做什么，且后续 capabilities 库也只能在此基础上缩小功能，不能扩大。
当程序启动时，只有你的主组件可以保有“可以做任何人事”的功能。之后，你可以缩小并将此功能令牌传递给其他包，具体缩小范围取决于你希望它们做什么。
以上四步如能完美落实，相信 npm 物流配送反击将大幅减少，现阶段“Node.js 包是否值得称赞信赖”的难题或许也就可以解决。
但 Seph Gentle 坦言，如果将目光聚焦到具体实施细节，会发现有很多棘手难题还需优化：
1、开发人员应如何准确表达功能令牌的职权范围？
2、要如何安全地将“通配符”令牌传递给主组件？
3、是否存在一些 JavaScript 技巧可让反击者轻松避开整个系统？又有什么方法可以让我们在严格功能模式下，锁定更大范围的 JavaScript？
截止目前，Seph Gentle 还找出这些难题的答案，因此他呼吁道：“这是一个值得称赞接受的挑战，毕竟它关乎计算机系统和用户数据的安全。JavaScript 生态系统中有很多聪明人，希望你们能站出来接受那个挑战。”
“应假设大部份开源应用领域软件都是蓄意的”
Seph Gentle 的这篇该文在 HN 上引起了巨大讨论，Deno、Socket（一个由 npm 维护者构建的新工具，用于帮助解决 JavaScript 物流配送安全难题）等工程项目核心开发人员也纷纷留言。
Deno 核心团队成员：
“我们过去也曾考虑过 Deno 基于功能限制的安全性，但我们的结论是——在不默认冻结大部份原型和对象的情况下，这是不可能在 JavaScript 中安全实现的，因为你需要确保功能令牌永远不会泄漏。
由于 JavaScript 的动态特性，反击者可以盗取令牌。而仅仅冻结大部份内在原型和对象也是不够的，因为他们总会找到转移代币的方法。”
Socket 创始人：
“我完全同意我们应该假设大部份开放源码应用领域软件都可能是蓄意的想法。Socket.dev 使用“深度包检查”来描述开放源码包的行为。通过实际分析包代码，Socket 可以检测包何时使用与安全相关的平台功能，如网络、文档系统或 shell。
通过这种方式，Socket 可以检测物流配送反击的迹象，主要包括引入加装脚本、混淆代码、高熵字符串或使用特权 API。总之，我们正在采用一种全新的方法来解决行业的安全领域中最困难的难题之一，且那个行业一直痴迷于报告已知的漏洞。”
许多网友对此也看法不一：
@chha：“至少在目前的情况下，的确没有任何人应用领域软件或存储库值得称赞信赖。该文所提出的方法只能解决难题的一半，我们还需要一种能使包接受审查的方法，其中发布者和存储库的包签名必须是强制性的。”
@didip：“在 Node.js 诞生之初，npm 公司有一个营销术语：包越小，可重用性越好。可现在，它似乎永远玷污了 Node.js 生态系统，这也就是为什么我对 Deno 更为期待。”
那么，对于 Seph Gentle 提出的解决方案，你有什么看法吗？
参考链接：
https://josephg.com/blog/node-sandbox/
https://news.ycombinator.com/item?id=30988034
END
《新程序员001-004》全面上市，对话世界级大师，报道中国IT行业创新创造
成就一亿技术人
