Tcp WebSocket框架中的掩码是什么？

我正在研究websocket实现，不知道帧中掩码的含义

有人能给我解释一下它是干什么的，为什么推荐它吗

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
 |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |   (if payload len==126/127)   |
 | |1|2|3|       |K|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 127  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+

---

在RFC6455中定义了WebSocket，其中说明：

屏蔽键的不可预测性是 防止恶意应用程序的作者选择 出现在导线上的字节

在一次调查中，我发现了以下解释：

掩蔽键（32位）：如果设置了掩蔽位（相信我，如果您为服务器端写入，那么就是这样），您可以在这里读取用于对有效负载进行异或的无符号字节它用于确保客户端攻击者不会滥用糟糕的代理

但我在一本书中找到了最清楚的答案。约翰·坦普林在那里说：

基本上，WebSocket的独特之处在于您需要保护网络 基础架构，即使客户端中运行恶意代码，也会完全 恶意控制服务器，您唯一可以信任的是 客户端浏览器让浏览器为每个页面生成一个随机掩码 帧，恶意客户端代码无法选择显示的字节模式 并使用它攻击易受攻击的网络基础设施

> KMKAPLAN，描述了RFC中的攻击向量。 这是一种防止代理缓存中毒攻击的措施1。 它所做的是创造一些随机性。必须使用随机屏蔽键对有效负载进行异或

顺便说一句：这不仅仅是推荐。这是强制性的

1：请参见以下内容：

需要屏蔽从客户端到服务器的WebSocket流量，因为恶意代码不太可能导致某些损坏的代理执行错误操作，并将其用作某种攻击。没有人证明这种情况确实可能发生，但由于这种情况的发生足以让浏览器供应商感到不安，因此添加了屏蔽以消除其被用作攻击的可能性

因此，假设攻击者能够破坏浏览器中执行的JavaScript代码以及后端服务器，则屏蔽设计用于防止以特殊方式创建在这两个端点之间发送的字节序列，从而破坏这两个端点之间任何损坏的代理（这意味着代理可能试图将websocket流解释为HTTP，而实际上它们不应该这样做）

浏览器（而不是浏览器中的JavaScript代码）对用于发送消息的随机生成的掩码拥有最终发言权，这就是攻击者无法知道代理可能看到的最终字节流的原因

请注意，如果您的WebSocket流是加密的（应该是加密的），那么掩码是多余的

为什么会有掩蔽呢？因为显然有足够多的基础设施，让升级头通过，然后作为第二个HTTP请求处理其余的连接，然后将其填充到缓存中。对此我没有任何说法。在任何情况下，对这一点的防御基本上是一个强大的32位随机数r作为屏蔽键。或者你知道…使用TLS，不要使用糟糕的代理

---

我一直在努力理解WebSocket掩码的用途，直到我遇到了以下两个资源，它们清楚地总结了WebSocket掩码

来自《高性能浏览器网络》一书：

使用帧头中指定的值屏蔽所有客户端启动帧的有效负载：这可防止在客户端上执行的恶意脚本对可能不理解WebSocket协议的中介执行缓存中毒攻击

由于中介体（例如透明代理）并不总是理解WebSocket协议，因此恶意脚本可以利用该协议并创建流量，从而导致这些中介体中的缓存中毒

但是怎么做呢

这篇自言自语以获取乐趣和利润（）的文章进一步解释了缓存中毒攻击的工作原理：

攻击者的Java小程序打开一个到attacker.com:80的原始套接字连接（与以前一样，攻击者还可以使用SWF挂载 通过托管适当的策略文件对此进行授权的类似攻击 请求）

攻击者的Java小程序通过使用伪造主机头构建的套接字发送字节序列，如下所示：GET/script.js HTTP/1.1主机：target.com

透明代理将字节序列视为HTTP请求，并基于原始目标IP路由请求， 这就是攻击者的服务器

攻击者的服务器在将来会使用带有HTTP Expires头的恶意脚本文件进行回复（以指示代理缓存） 响应时间尽可能长）

因为代理缓存基于主机头，所以代理存储恶意消息 缓存中的脚本文件为，而不是为

将来，任何客户 通过代理请求，代理将 为恶意脚本的缓存副本提供服务

本文还进一步解释了WebSocket是如何在缓存中毒攻击中出现的：

考虑一个中介来检查浏览器和攻击者的服务器之间交换的数据包 WebSocket和服务器同意。此时，客户端可以发送 频道上的任何流量。不幸的是，中间人 不了解WebSocket，所以初始WebSocket握手 看起来就像一个标准的HTTP请求/响应对 像往常一样，请求被一个空行终止 程序可以注入看起来像HTTP请求的新数据和 代理可以这样对待它。例如，他可以注入 以下字节序列：

GET/sensitive document HTTP/1.1

主机