Node.js 11.3.0 安全发布（Current）解读：HTTP 头限制、Slowloris 防护与 OpenSSL 升级

Node.js 11.3.0 安全发布（Current）解读：HTTP 头限制、Slowloris 防护与 OpenSSL 升级

【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org

本篇技术指南围绕 Node.js 官方网站（nodejs.org）仓库中的历史安全发布公告 v11.3.0 发布说明 展开，系统梳理 Node.js 11.3.0（Current 版本）作为一次安全发布所修复的 CVE 漏洞、代码级修复方案、OpenSSL 依赖升级内容，以及配套发布的下载与校验信息。读者读完本文，将能够理解 HTTP 头大小限制与 Slowloris 慢速攻击防护的实现原理、url.parse()主机名欺骗漏洞的成因，并掌握如何核对官方发布物完整性、理解发布公告的生成机制。

一、发布背景：一次面向全部活跃版本线的安全更新

Node.js 11.3.0 于 2018 年 11 月 28 日发布，属于Current（当前）版本线的安全发布。该版本的作者（发布人）为 Rod Vagg，发布说明明确提示：这是一次安全发布，所有 Node.js 用户都应查阅配套的安全发布总结——即仓库中的 November 2018 Security Releases 公告，以了解被修复漏洞的详细影响评估。

从配套公告可以看到，这次安全更新并非只针对 11.x 单一版本线，而是覆盖当时所有处于活跃维护期的发布线：

• Node.js 11.3.0（Current）
• Node.js 10.14.0（LTS "Dubnium"）
• Node.js 8.14.0（LTS "Carbon"）
• Node.js 6.15.0（LTS "Boron"）

其中 Node.js 6 和 8 升级到 OpenSSL 1.0.2q，Node.js 10 和 11 升级到 OpenSSL 1.1.0j。官方建议所有用户尽快升级到上述版本之一。值得注意的是，随后的 12 月 3 日，Node.js 6.15.1（LTS "Boron"）又被发布，用于修复 6.15.0 中一个回移（backport）错误——这从侧面说明安全修复在跨版本线回移时同样需要严格的验证流程。

二、本次发布修复的 CVE 清单

v11.3.0 发布说明列出了本次包含的 CVE 修复，共 5 项。结合配套安全公告 november-2018-security-releases.md 中的分类与影响评估，整理如下：

CVE 编号	漏洞主题	严重级别	所属模块
CVE-2018-12121	大 HTTP 头导致的拒绝服务（CWE-400）	HIGH	http
CVE-2018-12122	Slowloris HTTP 拒绝服务（CWE-400）	LOW	http / https
CVE-2018-12123	url.parse()对 javascript 协议的主机名欺骗（CWE-115）	LOW	url
CVE-2018-0734	OpenSSL DSA 签名生成时序漏洞	LOW	deps（OpenSSL）
CVE-2019-0735	OpenSSL ECDSA 签名生成时序漏洞	LOW	deps（OpenSSL）

说明：CVE-2019-0735 虽以 2019 年份编号，但其修复随 2018 年 11 月的 OpenSSL 1.1.0j 一起合入，因此出现在本发布说明中。

除上述外，配套安全公告还记录了同批次修复但未影响 Node.js 11的另外两个漏洞：CVE-2018-12120（调试器端口 5858 默认监听所有接口，仅影响 Node.js 6）与 CVE-2018-12116（HTTP 请求拆分，仅影响 Node.js 6 和 8）。这解释了为什么 v11.3.0 发布说明中只列出了 5 个 CVE——不同版本线受影响范围不同，发布说明只列出与本版本相关的修复。

三、HTTP 层安全修复详解

3.1 大 HTTP 头拒绝服务（CVE-2018-12121）：8 KB 头大小上限

漏洞原理：Node.js 6 及以后的所有版本均受影响，严重级别为 HIGH。攻击者通过组合"大量携带接近最大尺寸头（每个连接约 80 KB）的请求"并精心控制头的完成时机，可以触发 HTTP 服务器因堆分配失败（heap allocation failure）而中止。若服务前端有负载均衡器或其他代理层，攻击潜力会被削弱。

修复方案：Node.js 11.3.0 起，HTTP 服务器接收到的请求头总大小不得超过 8192 字节（8 KB）。该限制同时施加在底层解析器层面：

• llhttp解析器设置了最大头大小为 8 KB（提交a2b8aba23c，对应deps,http变更）；
• http_parser解析器同样设置了最大头大小为 8 KB（提交74e01d0020）；
• 同时修复了llhttp解析器复用时的headers_nread_计数器未重置问题（提交4ecbd3bdaa），并补充了头大小超限的错误处理与对应测试（提交04e0620597）。

这一系列提交说明：头大小限制不是仅在 JavaScript 层做简单判断，而是深入到底层 C 解析器，同时保证解析器在连接复用（keep-alive）场景下计数状态正确，避免绕过。

3.2 Slowloris 慢速头攻击防护（CVE-2018-12122）：server.headersTimeout与 40 秒超时

漏洞原理：攻击者通过非常缓慢地发送 HTTP 头，可以让 HTTP/HTTPS 连接及其关联资源长时间存活，从而耗尽服务器资源造成拒绝服务。该漏洞影响 Node.js 6 及以后所有版本，严重级别为 LOW（同样可通过负载均衡层缓解）。

修复方案：Node.js 11.3.0 起，服务器接收 HTTP 头新增 40 秒超时，并可通过server.headersTimeout属性调整：

• 如果在规定时间内未完整收到头，socket 将在收到下一个数据块（chunk）时被销毁；
• 与server.setTimeout()配合使用，可防止过多资源驻留，降低拒绝服务风险。

这是一个(SEMVER-MINOR)的 API 增强（提交315ee2e626，http,https模块共同受益），因为它为http.Server引入了新的可配置属性。对于需要更宽松或更严格头接收窗口的服务，可以通过设置server.headersTimeout来自定义超时值（单位为毫秒）。

3.3 影响评估：各版本线的暴露情况

根据配套安全公告，这两个 HTTP 漏洞对所有 6/8/10/11 版本线都有影响，因此本批次四个发布版本（11.3.0、10.14.0、8.14.0、6.15.0）都包含对应的 http 修复。而 v11.3.0 发布说明中的"Commits"部分也证实了这一点：修复以私有仓库（nodejs-private）的 pull request 形式先合入，再随公开发布同步公开。

四、URL 解析器主机名欺骗修复（CVE-2018-12123）

漏洞原理：当应用使用url.parse()解析 URL 并据此判断主机名（hostname）时，攻击者可以通过混合大小写的javascript:协议（例如javAscript:）欺骗解析结果。如果应用基于解析出的主机名做安全决策（如白名单校验），就可能得出错误结论。其他协议不受影响，严重级别为 LOW。

修复方案：修复提交为d7504324e1（url模块：避免 javascript 协议下的主机名欺骗）。修复思路是让 URL 解析器在处理 javascript 协议时不再信任可被混淆的输入，从而保证url.parse()返回的主机名真实可信。

防御建议：即便升级到修复版本，也建议应用层不要仅依赖url.parse()返回的 hostname 做安全边界判断，可配合协议白名单、规范化后再校验等多层手段。

五、OpenSSL 依赖升级：DSA 与 ECDSA 时序侧信道修复

5.1 升级内容

v11.3.0 将内置 OpenSSL 从 1.1.0 系列升级到OpenSSL 1.1.0j，一次性修复两个签名算法时序侧信道漏洞：

• CVE-2018-0734（DSA）：DSA 签名算法存在时序侧信道漏洞，攻击者可通过观察签名过程中的时间变化恢复私钥；
• CVE-2019-0735（ECDSA）：ECDSA 签名算法同样存在时序侧信道漏洞，可被用于恢复私钥。

两个漏洞严重级别均为 LOW。DSA 漏洞影响 6/8/10/11 所有版本线，而 ECDSA 漏洞仅影响 10 和 11 版本线（6 和 8 不受影响）——因此 11.3.0 的依赖升级只针对 11.x 自身的 OpenSSL 绑定。

5.2 升级相关的提交链

发布说明中列出的 OpenSSL 升级提交完整呈现了"升级依赖"的标准操作流程：

• 8f191f3759：更新 OpenSSL 1.1.0 升级文档；
• f20ac47d7a：更新 OpenSSL-1.1.0 的架构文件（archs files）；
• 8248d227b7：为 OpenSSL-1.1.0 新增 s390 汇编规则；
• 65d03f0180：将 OpenSSL 源码升级到 1.1.0j。

值得注意的是 s390 汇编规则的加入：Node.js 的 OpenSSL 绑定需要为不同 CPU 架构维护汇编优化规则，s390x 是当时官方支持的架构之一（这也可以从下方下载列表中的node-v11.3.0-linux-s390x.tar.xz得到印证）。

六、下载物清单与校验信息

6.1 各平台二进制与源码包

v11.3.0 发布说明列出了完整的下载物清单（对应 downloadsTable.mjs 中定义的下载模板按版本渲染）：

平台	文件
Windows 32 位安装器	node-v11.3.0-x86.msi
Windows 64 位安装器	node-v11.3.0-x64.msi
Windows 32 位二进制	win-x86/node.exe
Windows 64 位二进制	win-x64/node.exe
macOS 64 位安装器	node-v11.3.0.pkg
macOS 64 位二进制	node-v11.3.0-darwin-x64.tar.gz
Linux 64 位二进制	node-v11.3.0-linux-x64.tar.xz
Linux PPC LE 64 位二进制	node-v11.3.0-linux-ppc64le.tar.xz
Linux s390x 64 位二进制	node-v11.3.0-linux-s390x.tar.xz
AIX 64 位二进制	node-v11.3.0-aix-ppc64.tar.gz
SmartOS 64 位二进制	node-v11.3.0-sunos-x64.tar.xz
ARMv6 32 位二进制	node-v11.3.0-linux-armv6l.tar.xz
ARMv7 32 位二进制	node-v11.3.0-linux-armv7l.tar.xz
ARMv8 64 位二进制	node-v11.3.0-linux-arm64.tar.xz
源码包	node-v11.3.0.tar.gz

所有文件均托管于https://nodejs.org/dist/v11.3.0/目录下，官方 API 文档位于https://nodejs.org/docs/v11.3.0/api/。从仓库的下载表生成逻辑看，该清单会随版本号语义化地调整——例如小于 16.0.0 的版本不含 macOS Apple Silicon 二进制，小于 19.9.0 的版本不含 Windows ARM 产物，这解释了历史版本下载列表的差异来源。

6.2 SHASUMS 与 PGP 签名校验

发布说明末尾附带了完整的SHASUMS256.txt.asc内容，包含三部分：

1. SHA-256 校验和：覆盖上述每个下载文件的哈希值，用于验证下载文件完整性；
2. PGP 签名：整个校验文件使用 OpenPGP 签名（-----BEGIN PGP SIGNED MESSAGE-----/-----END PGP SIGNATURE-----），用于验证校验和文件本身确实来自 Node.js 官方发布渠道；
3. 签名元信息：包含哈希算法（SHA256）与签名指纹信息（iQEzBAEBCAAdFiEE3Y8jOLrnUB491ax4wnN5L32DVF0FAlv95CwA）。

校验实践建议：下载后应使用sha256sum（Linux/macOS）或Get-FileHash（Windows PowerShell）比对发布说明中的哈希值；同时用 Node.js 官方公开密钥验证 PGP 签名，防止下载物在传输途中被篡改——尤其是本次发布本身就是为了修复安全漏洞，校验环节不可省略。

七、发布公告的生产流程：从 Changelog 到发布页面

v11.3.0 发布说明这类文档并非完全手写，仓库中的 release-post/index.mjs 脚本揭示了其自动化生成流程：

1. 获取版本：通过命令行参数node index.mjs [version]指定版本；省略时从https://nodejs.org/dist/index.json自动取最新版本号；
2. 拉取 Changelog：从CHANGELOG_V{n}.md中用正则提取<a id="{version}"></a>锚点对应的版本段落，作为正文主体（fetchChangelog/fetchChangelogBody）；
3. 解析发布作者：从 Changelog 段落头（如## 2018-11-28, Version 11.3.0 (Current), @rvagg）解析出作者 GitHub 用户名，再查询其资料得到显示名（fetchAuthor）；
4. 解析版本策略：从段落头括号中提取Current/LTS等策略标记（fetchVersionPolicy）；
5. 拉取 SHASUMS：从https://nodejs.org/dist/v{version}/SHASUMS256.txt.asc拉取校验和内容（fetchShasums）；
6. 验证下载物：对 downloadsTable.mjs 生成的全部下载 URL 逐个发起 HEAD 请求验证存在性，不存在的标记为*Coming soon*（verifyDownloads/urlOrComingSoon）；
7. 渲染与落盘：通过 template.hbs 的 Handlebars 模板组装出完整 Markdown，再经 Prettier 格式化后写入pages/en/blog/release/v{version}.md。

模板结构（date、category: release、title、layout: blog-post、author等 frontmatter 加正文）与 v11.3.0 发布说明的最终形态完全吻合，说明该文档正是此流程的产物。这一机制保证了每次发布公告的下载清单、SHASUMS、版本策略等信息的一致性与准确性，是 Node.js 发布工程化的重要组成部分。

八、升级建议与后续关注

• 立即升级：所有使用 Node.js 6/8/10/11 的用户都应尽快升级到对应版本线的最新安全版本（11.3.0 或更高），以规避 HTTP 头 DoS、Slowloris 与主机名欺骗风险；
• 配置检查：若应用依赖超大自定义请求头（超过 8 KB），需评估是否受影响并调整架构（如改为通过 body 传递数据或调整代理层配置）；若需要调整头接收超时，可显式设置server.headersTimeout；
• 关注发布线状态：Node.js 11 属于 Current（非 LTS）版本线，其后续演进与维护窗口可参考仓库中的版本数据生成逻辑 releaseData.mjs——该模块根据各主版本线的 LTS 标记与 EOL 日期动态计算Current/LTS/EOL状态，帮助用户判断当前所处发布线的支持周期；
• 安全公告订阅：安全相关发布均归档在仓库apps/site/pages/en/blog/vulnerability/目录，并配套各版本线的 release 公告，可作为审计与溯源的一手资料。

参考资料

• Node.js 11.3.0 发布说明（本主题文档）
• November 2018 Security Releases 安全公告
• 发布公告生成脚本
• 发布公告 Markdown 模板
• 下载清单生成逻辑
• 发布版本状态数据生成逻辑

【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org