★ FEATURED ARTICLE 我曾任职的一家公司遭遇过一次攻击。攻击中NGINX 配置被修改视频流开始来自另一台服务器CDN 向用户分发了外来的恶意内容。用于签发访问链接的中间件也遭到了入侵。这件事让我开始思考哪些权限必须保留在被攻陷的分发环节之外才能避免让分发环节决定观众接受什么内容下面讨论一种范围明确的保护方式播放器在播放前验证媒体分片其代码和验证规则受到独立保护不受被攻陷的 CDN 与中间件控制。发布批准、当前发布上下文以及播放器更新也都处于被攻陷组件的权限范围之外。在这些条件下客户端可以拒绝被替换的内容。如果攻击者能够替换播放器本身或它的验证规则这一结论就不再成立。有效的签名链接与实际返回的内容**签名链接signed URL**是带有密码学签名的 URL。服务器可以据此验证链接是否由获授权的服务签发以及受签名保护的参数是否被修改。链接还可以规定访问条件例如有效期或允许访问的资源。[1]签名链接解决的是访问授权问题。例如CloudFront 验证签名和请求条件后会从缓存或源站返回内容。这一验证本身没有把链接签名与响应中的媒体数据绑定起来。[1]源站发生变化后同一个地址仍然可以继续工作。用户提交有效请求服务器返回响应但其中可能已经换成了另一份内容。这类替换不一定需要修改 URL。中间件被攻陷会进一步扩大攻击者的权限攻击者可以调用签发链接的操作。即使无法导出密钥调用签名操作本身仍然是一项权限。因此批准访问请求的权限需要与批准内容发布的权限分开。这里有三个独立的问题观众是否有权获取数据谁批准发布这份具体内容收到的媒体片段是否符合当前批准的发布内容第一个问题得到肯定回答并不能完成后两个问题的验证。攻击者控制了什么接下来采用一个较强的威胁模型分发节点整体与签发链接的中间件均被攻陷。攻击者能够修改配置、响应、进程和本地日志。同一节点上的内置验证也处于其控制范围内。本文不讨论最初感染的原因以及恶意软件随后被激活的机制。这些问题将在后续独立文章中展开。只读配置可以防止某些修改。一旦攻击者控制了操作系统仅靠这项措施就不足以建立对响应内容的信任。额外部署一个本地程序也不会仅仅因为它运行在独立进程中就获得验证上的独立性。以下四项权限必须保留在被攻陷的范围之外**批准发布**确定允许的频道、当前直播以及广告切换。**为媒体数据提供可验证的证明**只为获准用于本次发布的内容生成签名证明。**确定客户端应接受的直播内容**明确获准的签名者、当前上下文和允许的起始位置。**决定是否接受结果**验证实际数据并在播放前强制执行接受或拒绝的决定。把这些功能放到不同服务器上还不足以实现权限分离。共享管理员、更新流水线或策略访问权限都可能让一个攻击者同时控制所有功能。需要考察的是实际可调用的操作包括能否要求受保护的签名组件为任意内容生成证明。客户端尤其重要。如果被攻陷的中间件可以向用户下发修改后的 HTML/JavaScript 播放器就无法据此建立可信验证。后面的示例假设播放器的代码、策略、信任密钥和更新均受到独立保护。一个最小验证机制先选定一个具体方案使用已完整接收的 ISO BMFF/CMAF 媒体分片预先确定音视频轨道并且只使用一个媒体表示representation。每个分片都要完整验证通过后才能交给播放流程。这样就明确了验证与放行的单位。**C2PA 是一套规范可以通过密码学机制将媒体的来源与处理信息绑定到媒体本身。**本例使用这一机制在播放前验证收到的分片。该分片是否获准用于当前直播由应用程序的另一组规则决定。[2§§1.2–1.3]已有的技术机制可以作为基础。C2PA 2.4 描述了直播视频以及在每个分片中嵌入 C2PA Manifest 的方法。Manifest 包含与媒体数据的密码学绑定以及分片所属流和顺序的信息。规范的这一部分适用于 ISO BMFF/CMAF不包括 MPEG-TS。[2§19]在本例中分发之前的可信处理环节只为已获批准的内容生成上述证明。CDN 把分片和证明传给客户端。播放器验证签名、签名者的权限、证明与实际媒体数据的绑定以及当前发布上下文。密码学绑定应覆盖影响轨道播放的数据。只验证文件名无法确认这些数据的完整性。验证范围由所用格式决定与对 HTTP 响应的每一个字节进行哈希计算不同。[2§§9.2、15.12.2]随后执行本方案的规则只要缺少任何一项必需验证或验证未通过就不把该分片交给播放流程。C2PA 提供验证机制和结果报告在本链路中强制拒绝播放是应用程序制定的规则。[2§15.12.2]因此这种做法的价值在于权限分离以及强制执行验证结果。密码学机制来自已有规范。这样的验证有助于保护收到的媒体数据的完整性。下文正是围绕这一工程问题讨论中国《网络安全法》的相关条款。该法没有要求必须使用 C2PA采用 C2PA 也不代表已经满足该法的全部要求。[5第11、23条]如何确定当前获准发布的内容再考虑一种更复杂的替换攻击者返回昨天直播的某个分片。分片和原有的签名证明都未被修改签名验证也能通过。或者攻击者替换成同一发布者的另一个频道。对观众而言这样的响应仍可能不符合当前获准发布的内容。因此验证必须把收到的内容与独立确定的预期进行比较。播放开始前客户端需要获得当前有效的规则预期频道和直播会话、获准的签名者、起始位置、允许的轨道以及广告插入条件。这些规则来自受保护的控制环节被攻陷的分发环节无权替换它们也不能强行让客户端使用旧版本。判断规则和内容是否仍然有效需要专门的策略允许的时间窗口、重复片段的处理方式、重启后的行为以及加入正在进行的直播时应如何开始。第一个分片尤其重要。刚加入的客户端还无法依靠“与前一个已接收分片比较”来判断它是否正确。它需要独立确认的允许起始位置。缺少这一依据时严格执行规则的客户端不开始播放。这些是建立在所选 C2PA 机制之上的应用层放行条件并非规范中现成的字段。签名验证和媒体绑定验证通过并不等于该内容已获准在当前上下文中发布发布批准仍需单独确定。视频在语义上是否真实仍然是另一个问题。同一链路中的正常响应与替换尝试在上述条件下客户端已获得当前直播的发布批准信息和允许的起始位置。下面考察同一链路中分发环节返回的不同响应。分发环节返回什么客户端在这些条件下如何决定当前获准直播的正确分片签名、绑定、上下文和顺序均验证通过后允许播放。通过原有有效链接返回被修改的媒体数据数据与证明之间的绑定不成立拒绝该分片。附有新的有效访问令牌的外来内容访问令牌不能替代发布证明内容不获放行。签名正确但属于另一个频道或旧直播的分片签名可以有效但与独立确定的当前发布预期不符因此拒绝。缺少必需证明的分片删除证明不会开启绕过验证的路径仍然拒绝。广告分支也遵循同一组放行规则。如果应用能够播放未加密广告“广告”标签就不能成为任意数据进入播放流程的通行证。同时控制 CDN 本身不等于控制客户端 DRM、内容解密模块或许可证服务。这些权限需要分别考察。[3]限制替换的逻辑由此连贯起来修改数据会破坏绑定签名者没有相应发布权限时内容不会被放行另一份确实经过签名的素材会因上下文不符被拒绝。每一种拒绝都会在对应分片进入播放流程之前强制执行。在所采用的模型中被攻陷的组件无法修改这些决定的依据。拒绝播放的代价与保护边界拒绝某个分片可能意味着视频停止播放。要继续播放需要经过单独验证、并获准用于当前上下文的备用内容。签过名的历史录像本身并不会自动成为这样的备用内容。因此客户端接受结果的完整性与服务可用性需要分别验证。可用性需要测量延迟、切换时间、错误和恢复情况。验证完整分片还需要等待分片接收与处理完成具体增加多少延迟取决于实现。这里选定的方案只使用一个媒体表示。画质切换、重新封装、转码和服务端广告拼接都需要额外规则。例如不能让被攻陷的节点为任意转换结果重新生成签名否则批准替换内容的权限又回到了该节点手中。外部探针仍然有助于监测和响应。但被感染的服务器可以向探针和观众返回不同内容。为实现本文讨论的目标需要验证的是具体客户端即将播放的那份数据。拒绝时客户端可以把事件发送到外部响应系统。该事件可以作为调查和限制节点参与分发的依据但本身不能确定责任人或最初的漏洞。节点在事件后重新投入使用需要另外恢复对它的信任。一旦攻击者控制了发布批准、发布签名者、策略或验证客户端本身前述保证就失去了成立的条件。因此本文讨论的是特定链路在明确条件下的保护。能否用于真实系统取决于其播放器、更新机制、管理权限和媒体格式。CRA 与《中华人民共和国网络安全法》权限分离将技术分析与网络安全规范关心的完整性、可用性和事件响应联系起来。这些法规的适用条件不同。对欧盟《网络韧性法案》Cyber Resilience ActCRA需要考察产品、是否在欧盟市场提供、参与方的角色以及过渡条款。对中国《网络安全法》需要考察活动所在地域、提供者或网络运营者的角色以及适用的网络安全等级保护等保要求。文章发表在哪个平台并不能决定这些法规是否适用于所述系统。[4第2–3、69、71条5第2、23、78条]CRA 根据风险评估并在适用时规定相应要求。[4]《中华人民共和国网络安全法》第11、23条将网络保护与安全稳定运行、数据完整性以及组织和技术措施联系起来。第24条规定网络产品、服务提供者在发现安全风险后的补救、告知与报告、安全维护等义务第27条规定网络运营者制定预案和处置网络安全事件等义务。[5]播放前验证有助于分析其中一个工程属性。这些法规并未指定必须采用这一机制。拒绝被替换的内容不能证明已经全面合规也不会免除适用的漏洞修复、维护和报告义务。产品内部上报验证异常也不能自动视为已经向监管部门报告。在自己的系统中按步骤验证**选定一条播放路径。**明确频道、格式、播放器和广告分支得到一条具体的分析链路。**标出被攻陷的范围。**假定 CDN 和中间件均受攻击者控制列出其能够执行的操作修改响应、签发链接、替换代码或配置。**找到独立的发布批准来源。**确定客户端从哪里得知允许的内容、当前直播以及谁有权为其签名。如果攻击者能修改这份批准信息就需要先分离权限。**确定验证的数据单位。**本例使用完整分片。明确哪一份证明把发布批准与实际播放的数据联系起来。**在播放前设置不可绕过的验证。**检查所有路径包括音频和广告。确认被攻陷的组件无法替换验证代码、规则或更新。**执行对照场景。**正确分片应通过被修改的数据、另一个频道、旧直播以及缺少证明的分片应分别因相应条件不满足而被拒绝。**验证拒绝之后的动作。**有已验证且获准使用的备用内容时切换没有时停止播放。另外记录事件和后续响应。这延续了分布式网络中独立验证结果的原则。参与者可以承担分发职责但其结果能否被接受取决于不属于它的权限。只有明确了要验证的数据、当前预期以及客户端必须执行的放行或拒绝决定这条边界才具有实际意义。我会在两篇后续短文中继续展开这个例子《直播视频中的 C2PA分片签名与当前直播》讨论证明与媒体数据的绑定以及当前获准发布内容的验证。《谁来保护验证者播放器、策略与更新》讨论如何让被攻陷的基础设施无权修改客户端的验证代码、规则和更新。未雨绸缪未雨绸缪就是在问题发生前做好准备。[6] 对 CDN 而言这意味着在事件发生之前就明确谁批准发布、如何验证收到的内容以及发现替换后应采取什么动作。如果没有已验证的备用内容安全拒绝可能导致播放停止。这是实实在在的代价。但以公司名义播放外来内容还会增加失去用户与合作伙伴信任的风险。提前制定并验证应对流程有助于限制攻击的技术后果与声誉损失。感谢您读到这里。您的意见对我很重要。您在自己的系统中如何解决内容信任问题欢迎分享建议和实践经验。参考资料Amazon CloudFront — Use signed URLsHow signed URLs work。C2PA Technical Specification 2.4§§1.2–1.3、9.2、14、15.12.2、19.1–19.3、19.7。批准用于当前发布的内容和强制拒绝播放是本文应用方案的条件。W3C Encrypted Media Extensions — Recommendation, 18 September 2017Abstract、Definitions、§7.3.4。Regulation (EU) 2024/2847 — Cyber Resilience Act第2–3、13–14、69、71条附件 I 第一部分 2(d)、2(f)、2(h)–2(k)以及第二部分。官方 OJ PDF附件 I 见第68–69页。《中华人民共和国网络安全法》——国家网信办官方发布经2025年修正的版本第2、11、23–24、27、78条。《重編國語辭典修訂本》——未雨綢繆关于事先准备的释义。
阅读完成 · 觉得有帮助？
