web 内容如何保护：如何有效地保护 HTML5 格式的视频内容?

文章资料还没有整理完，现在还不通顺，但是可以做笔记看

HTML 是用于创建 web 页面和 web 应用程序的公开标准的标记语言。HTML 文件基本上是纯文本文件，这意味着软件应用程序和普通人可以轻松地创建、读取和更新 web 页面。HTML 的开放特性不仅使得用户可以使用简单的文本编辑器来编辑网站，而且任何人都可以查看源代码并复制其 HTML 源代码，并应用于其他地方。

然而，对于网站所有者或公司网站而言，可能会遇到需要保护 HTML、图像、CSS、JavaScript 代码免受浏览和盗用的情况。例如，您可能希望：

阻止竞争对手学习和复制您的 JavaScript 代码。

阻止像 WebZip 这样的自动下载软件下载您的整个网站。

保护网站会员区付费内容不被复制。

防止垃圾邮件机器人获取电子邮件地址或从您的页面中复制文本信息。

保护使您的公司网页（例如财务报告，技术文件）只能在您的控制下被查看。

当然，这分为几个部分，网站防止盗链与机器人。JavaScript 代码

如何防盗链？HTTP Referer 在 http 协议中，有一个表头字段叫 referer，采用 URL 的格式来表示从哪儿链接到当前的网页或文件。

换句话说，通过 referer，网站可以检测目标网页访问的来源网页，如果是资源文件，则可以跟踪到显示它的网页地址。

有了 referer 跟踪来源就好办了，这时就可以通过技术手段来进行处理，一旦检测到来源不是本站即进行阻止或返回指定的页面。

其实就是通过 Referer 手段，来识别用户的来源，从而防止盗链的目的。

Referer 的正确英语拼法是 referrer 。由于早期 HTTP 规范的拼写错误，为了保持向后兼容就将错就错了。其它网络技术的规范企图修正此问题，使用正确拼法，所以目前拼法不统一，还有它第一个字母是大写。

Referrer Policy StatesReferrer Policy 规定了五种 Referrer 策略：No Referrer、No Referrer When Downgrade、Origin Only、Origin When Cross-origin、和 Unsafe URL。

策略名称 属性值（新） 属性值（旧） 解释 No Referrer no-referrer never 绝不允许 referrer data 通过 No Referrer When Downgrade no-referrer-when-downgrade default 发送 referrer 信息去安全的 HTTPS 站点，而非不稳定的 HTTP 站点。Origin Only origin - 发送协议、主机和端口（即子域）没有一个完整的 URL 作为来源，

即https://moz.com/example.html只会发送https://moz.com

Origin When Cross-origin origin-when-crossorigin - 当传 origin-only 来路信息发送给外部站点时，如果目标有相同的协议、主机和端口（即子域），无论它是 HTTP 或 HTTPS，都将全部的 URL 作为 Referrer 发送出去。（注解：官方说明书上有一处排印错误，将来的版本应该是"origin-when-cross-origin"）

标签写法：

Unsafe URL unsafe-url always 总是将 URL 字串作为一个 referrer 通过。

注意：如果你的 URL 中存在任何敏感信息，这不是最安全的选择。其中 URL 的片段、用户名、密码被自动剥去。

当然，Refferer 也有安全问题，如 URL 可能包含用户敏感信息，如果被第三方网站拿到很不安全（例如之前不少 Wap 站把用户 SESSION ID 放在 URL 中传递，第三方拿到 URL 就可以看到别人登录后的页面）。之前浏览器会按自己的默认规则来决定是否加上 Referrer。

具体参看《referrer-policy:狙击盗链与跨站攻击之 Referrer 策略》

Referer nginx 配置最原始的方式就是通过 http referer，对于没有 referer 不是本站来的或者为空的，直接返回 403

nginx 配置，直接使用 referer 模块：http://nginx.org/en/docs/http/ngx_http_referer_module.html。具体配置如下：

server {listen 80 default_server;root /var/www/html;index index.html index.htm index.nginx-debian.html;server_name _;valid_referers server_names*.zhoulujun.cnzhoulujun.cn;

    if ($invalid_referer) {                                                                                                                       return 403;                                                                                                                             }    location / {            try_files $uri $uri/ =403;    }

}不建议如下方式

location ~* .(gif|jpg|png|swf|flv) {valid_referers none blocked www.test.com *.jfedu.net;root /usr/share/nginx/html;if (invalid_referer) {return 403;}}这个一般用来阻止网站图片被盗用

Referer+token 服务端鉴权防盗复杂点，url 或者 cookie 里面加上 token，通过 token 校验给与流访问权限。

简单说就是生成一个 token，url 必须有 token 才能访问。避免第三方直接盗用 link，避免小白用户轻易下载内容。优酷 youtube 都是如此。

但是防盗链防止不了比较熟悉网络的用户下载，其实在浏览器缓存里面就有视频文件了。

第三方插件，如 video download chrome 扩展插件，可以直接使用。

上述方法无法对视频进行保护。

视频内容保护方案视频保护是相对来水非常难的。目前业界做的方案，自定义播放器。之前 Flash 时代，不用 embed，而是 Flash，因为可以加密视频，防止导播。

现在 Adobe Flash 已经彻底凉凉，现在 H5 时代，实现视频加密算法，一个是获取加密的视频流，本地生成解密视频再播放。但是视频还是缓存了，插件啥的还是能够很好地被下载到本地播放。

第二个是，自定义实现播放器。如果代码 js 代码不混淆，更加安全。

JavaScript 加密、代码保护？JavaScript 是一种开放标准的浏览器解释语言，因此它在浏览器上都是可见的。不幸的是，任何人只要通过查看网页源代码或者调试工具就可以轻松看到它，他们可以复制 JavaScript 代码，为自己使用，甚至调试 JavaScript，修改 JavaScript 代码的功能。

代码混淆是目前保护 JavaScript 代码免受逆向工程最常用的方法之一，它使程序更难看得懂，但这并不是最好的解决方案。由于 JavaScript 关键字仍然暴露，黑客仍然可以理解代码，而在浏览器中，黑客可以调试并知道 JavaScript 的变量。混淆的 JavaScript 代码仍然可以被浏览器复制和查看。

具体参看 《前端安全保障:加密/混淆/反调试/加壳/自定义虚拟机—必要吗》

HTML 5 中如何保护知识产权 2011 年时 Silverlight 、HTML5 及 Flash 还是最受热捧的 RIA (富互联网应用) 技术。当时，Silverlight 的 PlayReady DRM、 Flash 的 Flash Media Rights Management(FMRM)，在版权保护上已十分成熟。而 HTML5 还处于 未指明编码标准的萌芽状态、更谈不上版权保护。

随着移动互联网、视频直播、职能家电等等互联网快速发展，浏览器插件一度成为网络恶意攻击的重灾区，给网络用户安全性带来很大隐患。微软和许多企业都鼓励用户、开发者使用 HTML5 的通信协议，标准化通信可以极大增加网络安全性。

其中包括 W3C 的 Media Source Extensions (MSE)、Encrypted Media Extensions (EME)、MPEG 的 MPEG-DASH 和 Common Encryption(CENC)。

终于，内容提供商（如 Netflix、Adobe、CableLabs 等）从 Flash、Silverlight 插件播放器过渡到统一的 HTML5 视频播放；各大浏览器公司（如 Google, Microsoft, Apple）也逐步抛弃了过时的媒体插件。

EME 作为 HTML 5 DRM 版权保护方案中的一员，虽然从 2012 年提案开始就颇多争议，但是事实上已被各浏览器以捆绑闭源的 CDM 的沙箱化方式“悄悄”分发。现在，W3C 只是给了它应有的名分罢了。

EME 对 Web 产生的影响 W3C 理事长 Tim Berners-Lee 在《W3C Blog: 关于 HTML5 标准中的加密媒体扩展（EME）》中阐述了 EME 对内容分发商、媒体、用户、开发者、安全技术研究人员的影响。

对多数人的影响大概是，可以提供一个相对安全的在线环境使用户可以获取高品质商业级的 Web 音视频等内容，并便捷的就此进行在线互动。

下图是内容提供商分发他们电影的选择渠道和优缺点。

ON EME IN HTML5

现代播放器的技术原理《视频直播技术详解——现代播放器原理》中，将典型的播放器分解为：UI、多媒体引擎和解码器。如下图：

视频直播技术详解——现代播放器原理

UI：含皮肤、自定义特性（如播放列表、分享等）和业务逻辑部分（广告、设备兼容性逻辑和认证管理等）；

多媒体引擎：处理所有播放控制相关逻辑，如描述文件解析、视频片段拉取、自适应码率规则设定和切换等。它拥有非常多的不同组件和特性，从字幕到截图到广告插入等等。

解码器和 DEM 管理器：解码器解码并渲染视频内容；DRM 则通过解密过程来控制是否有权播放。解码器和 DRM 管理器与操作系统平台密切绑定。

解码器、渲染器和 DRM 工作流程图.png

图 ：解码器、渲染器和 DRM 工作流程图

DRM 管理器.png

今天，在传输工作室生产的付费内容的时候，DRM 是必要的。这些内容必须防止被盗，因此 DRM 的代码和工作过程都向终端用户和开发者屏蔽了。解密过的内容不会离开解码层，因此也不会被拦截。

为了标准化 DRM 以及为各平台的实现提供一定的互通性，几个 Web 巨头一起创建了通用加密标准 Common Encryption (CENC) 和通用的多媒体加密扩展 Encrypted Media Extensions，以便为多个 DRM 提供商（例如，EME 可用于 Edge 平台上的 Playready 和 Chrome 平台上的 Widewine）构建一套通用的 API，这些 API 能够从 DRM 授权模块读取视频内容加密密钥用于解密。

CENC 声明了一套标准的加密和密钥映射方法，它可用于在多个 DRM 系统上解密相同的内容，只需要提供相同的密钥即可。

在浏览器内部，基于视频内容的元信息，EME 可以通过识别它使用了哪个 DRM 系统加密，并调用相应的解密模块（Content Decryption Module, CDM）解密 CENC 加密过的内容。解密模块 CDM 则会去处理内容授权相关的工作，获得密钥并解密视频内容。

CENC 没有规定授权的发放、授权的格式、授权的存储、以及使用规则和权限的映射关系等细节，这些细节的处理都由 DRM 提供商负责。

基本概念 DRM：数字版权管理（Digital Rights Management）是以一定的计算方法，实现对数字内容的保护, 也可以解释为, 内容数字版权加密保护技术。

EME：加密媒体扩展（Encrypted Media Extensions）是 W3C 提出的一种规范，用于在 Web 浏览器和 DRM 代理软件之间提供通信通道。

MSE：媒体源扩展（Media Source Extensions）是一项 W3C 规范，它扩展了 HTMLMediaElement，允许 JavaScript 生成媒体流以支持回放。这可以用于自适应流（adaptive streaming）及随时间变化的视频直播流（live streaming）等应用场景。

CDM：内容解密模块（Content Decryption Module），客户端或者使用端软件或硬件提供的一个机制，可以播放加密内容。

DRM 数字版权管理系统（Digital Rights Management）通过对数字内容进行加密和附件使用规则，对数字内容进行保护。提供了 widevine、fairPlay、playReady 等国际通用的保护机制。

DRM 整体保护机制 widevine 流程 h5 播放器为例 widevine 机制

用户端拉取需要播放的加密视频地址（cdn）

浏览器通过拉取的视频文件的头信息，知道该视频是加密的

触发浏览器 CDM 内容加密模块，产生 license 请求

播放器应用层，向应用服务器发送获取服务证书的请求，应用服务器，向 chrome 应用证书服务器，发送请求，获取证书，以及密钥

播放器应该用层获得解密密钥和证书，浏览器 CDM 使用获得密钥去更新，解密

加密视频能够在浏览器端播放

DRM 整体保护机制 widevine 流程

DRM 整体保护机制 FairPlay 流程创建 HTMLMediaElement 元素 <video>

设置播放媒体的 m3u8 文件地址 给 video.src = xxx.m3u8

用户点击播放，或者触发自动播放

事件监听器收到 webkitneedkey 的消息后，触发事件

创建 mediaKeys 并与媒体元素关联

创建 keySession，并监听 webkitkeymessage 事件

webkitmessage 事件触发，发送 SPC 给 key Server

收到 key Server 的 CKC 响应，更新 session 解密视频

播放

成熟的开源技术开源的视频播放器 个人点评 video.js 和其插件。设备检测与配置逻辑的 videojs-contrib-hls 、广告 videojs-contrib-ads 免费开源的 HTML5 和 Flash 播放器，通过强大的插件应用于 400,000 网站。采用 Apache License, Version 2.0 授权 JW Player 号称世界上最流行的嵌入播放器，应用于 200 万网站、每月 13 亿播放次数。采用 Creative Commons license 授权 Shaka Player Google 开源的基于 MSE + EME 的 JavaScript 库，支持 DASH、HLS 等。采用 Apache License 2.0 授权 dash.js 一个支持 MPEG DASH 的参考实现，适合研究学习。采用 BSD 授权参考文章：

精读加密媒体扩展（Encrypted Media Extensions，EME） https://juejin.cn/post/6844903503907815432

转载本站文章《web 内容如何保护：如何有效地保护 HTML5 格式的视频内容?》,请注明出处：https://www.zhoulujun.cn/html/webfront/SGML/web/2021_0801_8651.html