重新审视Web开发安全：event-stream注入恶意代码

发表于 更新于 分类于 本文字数： 2.3k 阅读时长 ≈ 2 分钟

在开发Web应用时，如果我们的需求缺少一个不那么简单而又不想亲自动手写的工具时，我们会向Google老师求助，看到一个npm包恰好能够满足，然后npm install package一把梭，require解决问题。完美的工作流，体现了JavaScript社区的开放与强大。但是，最近一个月下载量达百万的包event-stream被注入了恶意代码。恶意代码会尝试劫持另外一个包中的bitcore-wallet-client.getKeyFunc方法。如果一个项目同时依赖了event-stream与copay-dash，当bitcore-wallent-client中的getKeyFunc运行时，恶意代码会检查钱包的id，持有比特币BTC的数量以及比特币现金BCH的数量。如果BTC数量大于100或者BCH数量大于1000，就将钱包的公钥发给一个地址。

当我看到这个新闻的时候，我心里想，我没写过写区块链相关的对象，应该不会被影响到吧。但是当我没事跑一下检查方法时，结果却傻眼了：

检查结果

我中招了！

安全建议

我中招是因为vue-cli间接依赖了受影响[email protected]。目前vue-cli已经更新了版本将event-stream锁定在了未受影响的3.3.4。如果有向我一样中招的朋友，请尽快升级vue-cli。

1
2
# 全局安装时
npm update vue-cli -g

如果没有安装过vue-cli，也要检查一下是否有项目简介依赖了[email protected]。方法如下：

1
2
3
4
5
# 全局层面
npm ls event-stream flatmap-stream -g

# 项目层面
npm ls event-stream flatmap-stream

攻击原理

太简单了，假如我们有一个正常的包good.js是这么写的：

1
module.exports.goodFunc = () => 'good'

然后我们有一个包含恶意的包malicious.js：

1
2
3
4
const good = require('./good')

good.goodFunc = () => 'hijacked'
module.exports.usefulFunc = () => 'a useful function in malicious code'

当我们的项目同时依赖两个包的时候：

1
2
3
4
5
// index.js
const good = require('./good')
const malicious = require('./malicious')

console.log(good.goodFunc())  // hijacked

简单到不可思议吧，比起别的程序深入汇编挖漏洞。JavaScript只需要，从一个不知道干什么的包里require被攻击的包，然后修改一下就行。这里event-stream干了很容易被发现的通过网络发送数据，如果其他攻击不是那么容易被发现呢？我们项目里动辄上千的依赖，我们能够保证它们都是善良的天使吗？I don’t know…

重新审视开发安全

Web开发者整天与不安全的网络、不可信任的输入等打交道。Web安全对于开发者而言，似乎就是保证用户的信息安全。我们会使用很多技术来保证用户的安全，像HTTPS，CSRF防御等等。

但是…对于开发者本身呢？Node.js的模块机制提供的保护是0。它只能够保证第一次require的时候代码是包作者提供的。接下来轮到我们的代码require的时候，说实话，我们不能保证我们调用的函数是李逵还是“李鬼”。JavaScript语言层面提供的保护…近乎为0。能够阻止修改我们exports出去的对象的方法只有一个，Object.defineProperty(module.exports, 'myMethod', { writable: false })。那么长，还只能锁住一个方法，一般库的作者是不会写的。

现在我们使用这些包，就像使用C++的未定义行为一样。有时它确实有用，但是可能不是像你想象中的一样作用的。也许哪一天，一个包给Object.create注入新行为，当执行这个函数时删除项目文件夹，也说不定。。

目前JavaScript社区是靠人来解决这一事情的，默认信任大牛、高Star的包。但是这些“高信任度”的包引入的依赖呢？巨量的基础包依赖，像is-odd（判断一个数是不是奇数。很简单是吧？这个包每周下载量达1百万次哦）这些，使得我们根本不可能去检查项目中的每一个依赖。当其中一个依赖出现问题的时候，我们每个人都是潜在的受害者。

综上所述，Node.js不严格的模块机制、过于灵活的JavaScript以及项目中巨量的包依赖已经对开发安全形成了威胁。我们需要一个解决方案保证我们调用的函数就是作者写的函数。

一个可能的解决方案

既然现有机制无法保证包在export出去之后其公共接口不受改变。那么包的开发者应该承担起这一责任，无论是通过Object.defineProperty去设定公共接口不可写或什么其他的方法。这里我写了一个exports-lock，能够通过递归地设置module.exports的属性为不可写(writable: false)、不可配置(configurable: false)。保证公共接口在export之后不受篡改。

（可能暴力了点，可以改良。。。）

参考文章

1.I don’t know what to say.