基于 Node.js 的分布式系统

第 10 章 安全 安全

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

对于所有应用程序，尤其是那些暴露在网络中的应用程序来说，安全是一个重要的问题。传统上，影响网络应用程序的最大漏洞是不起眼的 SQL 注入攻击。多年来，这种攻击都是由普遍存在的不良文档和需要用户手动构建 SQL 查询字符串的库造成的。值得庆幸的是，在过去的十年中，编程界已经取得了长足的进步，你很难找到一个提倡查询字符串连接的现代库或教程。

尽管如此，SQL 注入仍然是应用程序安全方面的最高风险之一，并在OWASP 十大列表中名列第一。SQL 注入攻击的记录非常详尽，数据库库中易受攻击的边缘情况也有足够大的警告标志，因此本章将不再赘述。

不过，Node.js 平台似乎也面临着一些固有的新的独特挑战，这些挑战还没有得到广泛的理解。甚至还有一些相对较新的工具可以帮助自动发现和修补这些漏洞。这些挑战和工具是本章的重点。

这些挑战之一就是确定应用程序的攻击面。传统上，攻击来自外部，比如攻击者通过 Network+ 发送恶意请求。但是，如果攻击者编写的恶意代码进入了应用程序所依赖的软件包，会发生什么情况呢？

在深入研究单个安全问题之前，重要的是制定一份检查清单，以帮助识别不同应用程序的健康状况。对于使用许多不同微服务为应用程序提供动力的企业来说，这一点尤为重要。

管理存储库

构建后端系统的一种常见模式是使用微服务来表示应用程序的各个领域。通常的做法是创建独立的版本控制资源库，初始化新的模块结构，然后添加 JavaScript 文件，可以从头开始，也可以模仿其他资源库中使用的模式。

在这种情况下，团队和软件仓库之间通常是 1:N 的所有权关系，不过有时也会有几个热门项目由多个团队共同参与。还有一些时候，一些软件源最终会成为孤儿，没有明确的所有者。我曾在一些公司工作过，其中几个团队共同拥有几十个微服务。

拥有这些项目的团队有不同的工作重点。有时，一个团队会非常重视保持项目的最新状态和安全补丁的应用。其他时候，一个项目的package-lock.json可能几个月或几年都不会被动过。

有时，有必要指定一名工程师负责整个组织内所有 Node.js 项目的健康状况。当我加入一家公司时，我通常会主动承担这个角色。这样做既能帮助公司控制局面，又能帮助我熟悉公司的微服务及其互操作方式。

我采用的一种模式是，首先查找公司使用的不同服务，并将遇到的所有不同服务制作成电子表格。

即使应用程序可能会在几种不同的范式中运行（这边是 Kubernetes，那边是专用 VPS，再加上 Lambda），组织通常也会使用单一的版本控制服务来组织所有代码。该工具是获取服务列表的最佳途径。例如，GitHub 可以按语言列出存储库：

https://github.com/<org>?language=javascript

获得组织内的软件源列表后，您需要缩小条目范围，直到只列出活跃的 Node.js 服务。在工作表中为找到的每个服务新建一行。请务必在工作表中跟踪任何相关信息，如版本库链接、拥有版本库的团队、部署媒介，以及最重要的项目运行的 Node.js 版本。

我还喜欢记录一些其他信息，比如项目使用的重要软件包的版本。例如，网络服务器软件包的名称和版本，以及由组织维护的任何集成软件包的版本（如果适用）。跟踪网络服务器很重要，因为就安全性而言，它是 HTTP 服务器的主要出入口。它通常是应用程序中最复杂的部分，因此也是最有可能暴露安全漏洞的组件之一。

有些组织选择发布内部软件包，用于与重要服务通信，而不是记录和公开用于与服务通信的协议。例如，一家公司可能将一个账户软件包发布为 ...