软件安全访谈：ZipSlip、NodeJS安全性和BBS攻击

正如Nodejs Security WG成员和Snyk开发者布道师Liran Tal所写的那样，自BBS早期以来，这种漏洞利用的矢量攻击已经为人所知。InfoQ采访了Tal，了解了更多有关软件安全性（尤其是Nodejs安全性）的相关信息。

今年早些时候，Bower软件包管理器被发现在解压缩包方面存在漏洞，攻击者可以在用户磁盘上写入任意文件。正如 Nodejs Security WG 成员和 Snyk 开发者布道师 Liran Tal 所写的那样，自 BBS 早期以来，这种漏洞利用的矢量攻击已经为人所知。

据安全研究人员 skyn3t 在 2019 年 1 月 1 日报道，攻击者可以通过一个恶意zip存档来利用符号链接的不正确验证在zip解压缩目录之外写入任意文件。根据 Tal 的说法，在使用 Bower 时，启用路径遍历的罪魁祸首是一个小小的 Nodejs 包——decompress-zip，但这种情况并不只在这里出现。事实上，这种漏洞也已经在其他几个生态系统中找到，包括 JavaScript、Ruby、.NET、Go 和 Java，并且似乎影响了数千个项目，因此它被称为ZipSlip。令人感到震惊的是，ZipSlip 使用的基本攻击向量已经是众所周知的，并且自 Bulletin Board Systems（BBS）早期以来可能已经被多次利用。

InfoQ 借此机会采访了 Tal，了解了更多有关软件安全性（尤其是 Nodejs 安全性）的相关信息。

InfoQ：你能介绍一下自己并简要描述一下你在 Snyk 做什么吗？

Liran Tal：我做过很长一段时间的软件开发，最近五年在带Web开发团队。我是作为一名开发者布道师加入Snyk的，任务是帮助其他开发人员使用开源软件并保证安全，并进一步扩展我在Node.js和JavaScript生态系统安全性方面的工作。在Snyk工作是非常棒的经历，我在这里认识了很多人，并且我在以前的几个公司也使用过snyk。

InfoQ：全球统计数据显示，软件漏洞在过去几年中一直在稳步增长，对软件系统产生了很大的影响，从基本组件（CPU、操作系统、网络栈等）到面向用户的应用程序，从而可以以前所未有的规模窃取用户数据。这是不是说明我们的系统变得越来越脆弱，越来越复杂，还是对安全的重要性有了更多认识？

Tal：我认为你说得没错。毫无疑问，系统已经变得越来越复杂，而且我们今天看到的抽象比20年前要多得多。并不是说这很糟糕，但它确实增加了复杂性并增加了所需的技能和专业知识。

系统变得更容易受到攻击并非有意的，但我确信所有开发人员都能够理解——我们添加的代码越多，存在错误和安全漏洞的风险就越高。近十年来，开源软件得到了广泛的应用，这对于任何一个从开源软件运动早期就开始接触开源软件的人来说，都是令人惊讶和真正振奋人心的。与此同时，这意味着我们使用可能由很多开发人员（或者说是陌生人）构建的软件组件来构建我们的产品，而我们对他们的安全知识一无所知，也不知道他们评审代码库的频率是怎样的（如果有的话）。

我真的很高兴你提到了这个话题，因为我在过去几周里一直在努力制作一份报告，报告揭示了有关开源安全状态的详细信息和真实数据。它关注应用程序库、系统库以及开源开发人员和维护人员的状态。我们了解到了一些有关代码库安全方面的有趣内容，例如他们是如何发现安全漏洞的，以及他们的CI中有多少是包含了自动化安全测试。Snyk去年也发布了一份报告，2019年的最新报告将在几周后发布。

总的来说，我认为E.S Raymond说得对，所有的缺陷都是很浅层的。作为一个平台，GitHub极大地降低了参与开源社区的门槛，在我看来，这是对采用开源的重大贡献。它使代码库相对容易经受安全评审，并与维护人员就漏洞和修复问题进行交流。我们从去年的报告中收集到的一个有趣指标是，引入代码库的漏洞所需的最长时间为5.9年。对于一个漏洞来说，藏在源代码中直到有人发现并被公开，5.9年已经是很长时间了。我们研究过的一些流行的库，中位数时间是2.5年。

InfoQ：说到你的专业领域 NodeJS，你最近在 Bower（一个目前仍在广泛使用的软件包管理器）中发现了一个漏洞。但更令人担忧的是 NPM（NodeJS/JavaScript 生态系统的包管理器）的安全状态。开发人员应该做些什么来最小化交付软件的风险？

Tal：因为问题太普遍了，以至于解决这些问题可能有点令人望而生畏。说到NPM的安全性，有两个方面需要提一下——NPM注册表本身的安全性及其开发人员和维护人员的平台安全性。前者在过去曾被批评有米有在采取适当措施为生态系统提供安全基础。后者是托管在NPM注册表上的JavaScript源代码集合中的安全级别。

尽可能早地考虑安全性是认真对待安全性的一个好的开始。Tanya Janca说，首先，这是一种安全思维，理解安全问题是每个人的工作。将安全问题作为设计和代码评审流程的一部分，然后在日常开发流程中继续集成一组支持安全性的流程和工具。

例如，采用静态代码分析插件作为构建过程的一部分，或者扫描项目中的开源依赖项漏洞，Snyk在这方面做得最好，因为它拥有非常全面的漏洞数据库，而且它还提供了报告漏洞的方法，并通过升级依赖项所需的最小semver变更自动创建拉取请求。

安全性并没有止步于使用CI集成来扫描漏洞。请考虑一下这种情况——你开发了一个Web应用程序，将其发布到生产环境中，然后继续下一个项目。旧代码没有继续维护，但正如我们从最近的报告和多年的安全经验中了解到的那样，漏洞将会在稍后出现。那么怎样才能知道是不是出现了漏洞呢？你需要随时监控项目的依赖项，以便在发现安全问题时可以返回项目并修复漏洞。snyk就提供了这些东西，可以将它集成到整个软件开发生命周期中。

你之前提到了Bower漏洞的一个有趣的事实——它与去年snyk的安全团队所做的研究有关，并且在大约二十年前的一篇有关Phrack的文章中首次提到过。这些研究工作揭示了数以千计的项目容易受zip压缩包行为漏洞的影响，这些行为可能导致写入任意文件和潜在的远程代码执行。这进一步说明了使用开源软件的影响，一个库中的漏洞可以在数千个项目和代码库中体现出来。

可以想象，像NPM、yarn或Bower这样的供应链服务都需要做一些与压缩包相关的事情，而Bower特别容易受到几种类型的ZipSlip漏洞的攻击。如果有人对概念验证感兴趣，想知道它的原理，我可以介绍这个故事，并一步一步说明如何利用这个漏洞。

InfoQ：在 NodeJS 生态系统中，是否应该在更加结构化的层面上进行一些努力？

Tal：从Node.js的角度来看，安全工作组的任务是负责为Node.js创建一个更安全的生态系统，同时也是间接为整个JavaScript生态系统创建一个更安全的生态系统。

我们正在积极地评审和改进安全焦点，例如相关的Node.js API、安全代码评审和Noe.js核心的安全测试工作。工作组还充当了NPM Registry中的第三方生态系统模块以及Node.js核心的事件响应团队。

有一些外部力量在为社区提供安全知识，例如Node.js安全路线图，以及巩固安全资源的努力，例如我自己的awesome-nodejs-security。我们希望从安全工作组内部看到更多这样的东西。

为了提高Node.js生态系统的安全性，有很多努力和举措。InfoQ将继续对此进行报道，并及时让读者知道。

查看英文原文：https://www.infoq.com/news/2019/02/zipslip-nodejs-vulnerability