江苏龙网

  1. 主页 > 生活百科 > >

常见的Node.js攻击-恶意模块的危害

Node.js


常见的Node.js攻击-恶意模块的危害

文章插图
 
根据最近npm的一项安全性调查显示 ， 77%的受访者对OSS/第三方代码的安全性表示担忧 。本文将介绍关于这方面的内容 ， 通过第三方代码引入应用程序的安全漏洞 。具体来说 ， 我们考虑被恶意引入的漏洞的场景 。
我应该担心第三方模块吗?
你可能疑惑的第一件事是 ， 是否需要担心恶意模块？程序员是一群非常友好的人 ， 我们为什么要怀疑他们发布的模块呢?而且 ， 如果npm上的每个包都是开源的 ， 那么肯定有大量的眼睛来跟踪每一行代码 ， 不是吗?此外 ， 我只有几个模块 ， 能有多少第三方代码呢?
在探究这些答案之前 ， 让我们先看看这篇文章:“我正在从你的站点获取信用卡号码和密码 ， 方法在这" 。这是一个虚构的故事 ， 讲的是npm上的Node.js模块的作者 ， 该模块能够偷偷地从网站上盗取信用卡 。故事详细介绍了隐藏这些活动的各种方法 。例如 ， 代码从来不会在localhost环境上运行 ， 它从来不会在开发控制台打开时运行 ， 它只在很短一段时间内运行 ， 并且发布到npm的代码被混淆了 ， 并且与在GitHub上公开托管的代码不同 。虽然这个故事是虚构的 ， 但它所描述的技术方法是完全可行的 。
当然 ， 那只是一个虚构的故事 。现实真的有这样的例子吗?npm最近发布了这篇文章:“恶意模块报告:getcookies” 。本文介绍了一个实际情况 ， 文中描述的模块被发布并成为其他模块的依赖项 。当接收到精心设计的头信息时 ， 将触发此恶意模块 ， 然后执行请求中提供的任意JAVAScript代码 。
getcookies模块确实也成为了几个模块的依赖项 ， 但理论上这种损害并没有被广泛传播 。您现在可能想知道会造成多大的破坏 ， 或者攻击者会对npm生态系统产生多大的影响 。在“收集弱npm凭证”这篇文章中 ， 一位安全研究人员描述了他如何获取npm用户帐户凭证(从而获得发布权) ， 这些帐户占整个npm包生态系统的14% 。这是通过从许多可用的凭据泄漏和强制使用弱密码收集凭据来实现的 。由于这些包是其他包的依赖项 ， 研究人员能够瞬时影响54%的整个npm生态系统!如果研究人员发布了他所控制的每个包的补丁版本 ， 然后运行一个npm install ， 其中包含54%包中的任意一个包的依赖树 ， 就会执行研究人员的代码 。
更为严重的是 ， 即使是善意的包作者也可能成为网络钓鱼和密码泄漏的受害者 。为了防止以上问题的出现 ， npm确实为其服务增加了双因子认证 (2FA) 。然而 ， 即使添加了2FA ， 托管在npm上的包也不一定是全部启用的 。2FA是可选的 ， 不太可能所有的npm包作者都启用它 。虽然2FA更安全 ， 但许多2FA方法也容易受到钓鱼攻击 。
当然 ， 模块作者更有可能意外地向模块添加漏洞 ， 而不是故意这样做 。学者们发现Node.js模块中存在大量注入漏洞 ， 这可能会使您的应用程序变得脆弱 。我们才真正开始关注这方面的研究 ， 随着生态系统和Node.js开发人员数量的增加 ， 针对npm模块的攻击只会变得越来越有利可图 。
我使用了多少第三方代码?
如果让你预估你的代码库中有多少是应用程序代码 ， 有多少是第三方代码？现在你应该得到一个数字 ， 接下来在应用程序中运行以下命令 。该命令计算应用程序中的代码行数 ， 并将其与node_modules目录中的代码行数进行比较 。
npx @intrinsic/loc复制代码这个命令的输出可能有点令人惊讶 。对于一个拥有数千行应用程序代码的项目来说 ， 拥有超过100万行的第三方代码是很常见的 。
到底能造成多大的伤害?
现在你可能想知道到底会造成什么样的伤害 。例如 ， 如果您的应用程序依赖于模块A ， 而模块A又依赖于模块B ， 最后依赖于模块C ， 那么我们将一些重要数据传递给模块C的几率有多大呢?
为了让恶意包造成破坏 ， 不管它在require层次结构中有多深 ， 甚至不管它是否直接传递敏感数据 。重要的是代码被require了 。下面是一个恶意模块如何修改全局request的例子 ， 它很难被检测到 ， 并且会影响整个应用程序:


推荐阅读


上一篇：梦见狐狸扑向自己还想咬是什么意思 梦见狐狸扑向自己吓醒

下一篇：邢夫人的丫鬟 邢夫人王夫人关系