互操作性中的“S”：标准、解析器差异与安全维护

背景

互操作性（Interoperability）是互联网技术的基石，而标准（Standards）则是实现互操作性的核心手段。然而，标准的制定并非一劳永逸，其落地过程往往伴随着复杂的工程挑战和潜在的安全隐患。

作者作为一名资深技术从业者，其参与标准制定的历程颇具代表性：从最初作为读者通过标准来理解复杂代码或协议中的异常行为，到后来协助澄清边缘情况以确保实现的一致性，最终成为 W3C 推荐标准 Subresource Integrity (SRI) 的共同编辑者。SRI 于 2015 年发布，其核心理念是通过在引入第三方 JavaScript 时附带预期的 SHA2 摘要（digest），防止 CDN 劫持或篡改脚本，从而在享受 CDN 加速的同时降低安全风险。

尽管 SRI 标准看似严谨，但在其发布约十年后的 2025 年，作者团队在排查 Firefox 浏览器对某网站兼容性问题时，意外发现了一个潜伏已久的 Bug。这一事件揭示了标准文本与实际实现之间长期存在的细微差异，以及这些差异如何演变为安全漏洞。

核心内容

SRI 标准中的 Base64 编码陷阱

SRI 标准的哈希摘要格式定义为 sha(size)-(base64 encoding of the digest)。然而，Base64 编码存在两种不同的字母表变体：

1. 标准 Base64：使用 a-zA-Z0-9/+ 字符集。
2. URL 安全 Base64 (base64url)：使用 a-zA-Z0-9_- 字符集，旨在避免 URL 中的特殊字符冲突。

SRI 规范的示例中均使用了第一种标准 Base64。然而，另一个浏览器引擎为了兼容性，宽松地接受了这两种编码格式。这导致网站开发者开始互换使用这两种编码，期望浏览器都能支持。

当 Firefox 严格遵循规范，只接受标准 Base64 时，它无法验证那些使用了 base64url 编码的哈希值。这导致页面在 Firefox 中无法正常工作，并暴露出一个次要的安全问题：浏览器未能执行预期的完整性检查。

标准维护与浏览器市场现实的博弈

从纯技术标准角度看，正确的修复方式应是明确规范中 base64url 变体为非法，并促使另一家浏览器引擎修正其行为。然而，现实情况更为复杂：

• 标准泛滥：互联网标准数量激增，维护成本高昂。
• Web 兼容性压力：破坏现有网页的兼容性是浏览器厂商极力避免的。
• 市场主导地位：某些浏览器引擎的市场份额使其拥有更大的话语权，迫使其他实现进行妥协。

因此，为了支持现有的 Web 内容，标准制定者最终选择了妥协：修改规范，承认两种编码格式均为有效的表示形式。这一案例表明，互操作性规范可以在“快乐路径”（Happy Path，即理想情况）上建立共识，但在对抗性环境或边缘情况下，往往需要漫长的时间才能暴露出细微的差异。

从规范到标准：互操作性与安全性的区别

作者进一步区分了“规范”（Specification）与“标准”（Standard）的概念：

• 规范：最初仅是一份文档，描述某种想法、行为逻辑、数据结构或算法。任何人都可以编写语法、解析器和数据结构。
• 标准：需要广泛的共识，并被广泛且一致地实现。这需要规范、实现和边缘案例讨论之间的迭代共同设计，甚至包括共享测试套件。

互操作性（Interop）是一个渐进的过程，依赖于随时间推移达成的共享协议；而安全性（Security）则需要更深层的理解，要求审视局限性和细微边界。许多实现者认为语法“足够简单”而跳过阅读规范，导致基于不同假设的解析器产生细微的不兼容甚至安全漏洞。

解析器差异（Parser Differentials）案例：JSON 重复键

除了 SRI 案例，作者还以 JSON 为例说明了“看似简单”的输入处理带来的风险。考虑以下 JSON 字符串：

{
  "test": 0,
  "test": 1
}

当解析为对象 obj 时，obj.test 的值是多少？

• 实现 A：简单覆盖，返回 1。
• 实现 B：检测到重复键，静默拒绝第二个键，保留第一个，返回 0。

虽然 JSON 最初被描述为 JavaScript 的子集，但其 RFC（2017 年发布）已承认这种描述的模糊性存在问题。然而，直到今天，许多实现仍允许重复键并表现出不同的行为。

虽然 SRI 和 JSON 重复键的案例看似无害，但类似的解析器差异在实际中曾导致代码执行、身份验证绕过等严重安全漏洞。

关键要点

• 标准的滞后性：细微的标准差异可能需要数年甚至数十年才能在真实环境中暴露出来。SRI 中的 Base64 编码歧义潜伏了十年之久。
• 互操作性不等于安全性：互操作性关注的是不同实现能否协同工作（共享协议），而安全性关注的是对边界条件和潜在攻击面的深刻理解。两者需要不同的维护策略。
• 解析器差异是安全盲区：许多开发者自行编写或依赖宽松的解析器处理文本格式（如 HTML、XML、JSON、YAML）。不同解析器对“简单”语法的不同假设，可能导致严重的安全漏洞。
• 标准需要持续维护：完美的互操作性不是通过一份静态文档创建的，而是通过持续的维护、实施者的反馈以及用户的报告逐步实现的。
• 现实妥协的必要性：在 Web 生态中，由于兼容性和市场力量的影响，标准制定往往需要在“理论正确”和“实际兼容”之间做出妥协。

意义与影响

这篇文章深刻地揭示了互联网基础设施的成熟过程并非一蹴而就，而是充满了“疤痕组织”（scar tissue）。

1. 对开发者的启示：不要假设标准是静态或完美的。在使用第三方库、解析器或依赖 Web 标准时，必须意识到实现之间的细微差异可能带来安全风险。特别是在处理输入验证、完整性检查和数据解析时，应严格遵循规范，避免依赖“宽松”的默认行为。
2. 对标准制定者的启示：标准文档需要清晰、无歧义，并且必须伴随持续的维护机制。仅仅发布规范是不够的，还需要建立有效的反馈循环，包括共享测试套件、漏洞报告和社区讨论，以消除实现中的歧义。
3. 对安全研究的启示：安全漏洞不仅存在于代码逻辑中，也可能隐藏在标准解释的差异里。安全审计应涵盖对解析器行为、边缘案例处理以及标准实现一致性的深入检查。

最终，标准之所以安全，并非因为它们被写成了文档，而是因为人们持续地质疑、理解和维护它们。Bug 报告、规范问题追踪、共享测试用例，甚至是论坛上的随机抱怨，都是消除歧义、推动互联网标准成熟的关键力量。