websocket - websocket掩码的安全方面

在实现 websocket 服务器时，我遇到了客户端屏蔽数据的需求。我在谷歌上搜索为什么指定它，因为 RFC 中没有给出任何理由，并且遇到了这个答案（以及其他具有相同推理的人）：关于 websocket 的掩码字段

起初它是有道理的，所以我只是实现了它，但由于除了强制“安全”之外几乎没有什么我讨厌的东西，它仍然有点困扰我，我最终有两个假设，我想知道这些假设是否正确：

由于它只是客户端的强制性要求，因此假设出现故障的代理或中间组件只关心客户端请求？或者说没有恶意服务器？
它实际上并不是为了防止恶意行为者导致远程代码执行，而是为了防止一个好的客户端无意间导致代码执行而成为一个坏的行为者。如果我是一个坏演员，我只会发送未屏蔽的数据或设置标志，即有效负载被屏蔽但不屏蔽它。

我有什么遗漏会导致这些假设错误吗？

标签： websocket

更大的问题 -可以用作攻击中介的载体- 主要是关于确保 WebSockets 协议可以通过现有基础设施而不受阻碍，并且不会造成意外损害，例如缓存中毒或其他副作用。

正如我在之前对类似问题的回答中提到的那样，由于许多较老的中介不了解 Websockets 协议，因此可能会编辑或处理看起来像 HTTP 请求的明文。

例如，代理可能会丢弃它认为是格式错误的 HTTP 请求（导致连接错误和数据丢失的非安全问题），或者缓存代理可能会缓存对它认为是有效 GET 请求的响应（导致缓存中毒，这是一个安全问题）。

通过屏蔽客户端发送的文本（中介可能认为是 HTTP 请求的文本），处理模式从明文“转移”到无法识别的字节，启动“直通”模式而不是允许中介将数据“处理”为有效（或无效）HTTP。

假设是，如果存在掩码错误（0000掩码/持久掩码），或者被掩码的数据出现恶意，服务器将断开 WebSocket 并且任何可能的攻击都会失败。

假设掩码处理得当（数据被掩码），响应将被缓存或以其他方式被中介处理 - 所以没有必要浪费 CPU 周期来掩码响应。