兄弟，「针对基础设施的攻击」这段能表述得更详细一点吗？或者给一下你阅读的资料来源？感觉没太理解。。

嗯, 好, 在我看来, 意思就是利用 WebSocket 在 客户端浏览器 构造出 HTTP 请求格式的帧, 因为都是基于 TCP 之上的, 经过缓存服务器时, 这些服务器有可能就把这个帧作为 HTTP 请求来对待, 存在潜在的安全隐患. (mask 这里就是防止你构造出预想的数据格式(HTTP 报文), 以便缓存服务器能够 pass 这些伪造的 HTTP 报文).

原文在这里: https://tools.ietf.org/html/rfc6455#section-10.3
过了好久了, 如果我的解释不合理请一定告诉我, thx~~

@onlyice

感谢答复 😺

那即是说，是因为这些缓存服务器并没有适配 WebSocket 的场景，才导致的问题？如果缓存服务器的实现更科学，是不是就不存在这种情况了？

看下这里的解释,更加方便你们的理解.楼主说的我也没看懂,看了这个明白了

https://security.stackexchange.com/questions/36930/how-does-websocket-frame-masking-protect-against-cache-poisoning

http://www.infoq.com/cn/articles/deep-in-websocket-protocol
这里的是中文的解释，感觉解释的很好

简单的说吧：

1. 代理服务器会缓存请求，可以精心发起一个请求，让代理服务器缓存指定的内容，从而使得后续的请求使用被缓存的内容
2. 通过加入 mask，使得请求不同，从而不会使用有问题的缓存
3. 其实在 HTTPS 普遍存在的情况下，这个意义不大，因为协商出来的密钥是不一样的，内容就不一样
4. 一些常见做法譬如请求后面加个随机数或者时间戳也是同样的道理，都是为了避免缓存
5. 感觉 mask 如果只是为了解决这个问题，其实挺鸡肋的

感觉这种污染proxy的行为就算没有websocke和可以进行啊，为何需要专门指出会发生在websocket上呢？
@hhding @abbshr

感觉这种污染proxy的行为就算没有websocke和可以进行啊，为何需要专门指出会发生在websocket上呢？
@hhding @abbshr

没有websocket,攻击者无法将伪装的响应放到代理服务器上吧

• 一些常见做法譬如请求后面加个随机数或者时间戳也是同样的道理，都是为了避免缓存

其实在 HTTPS 普遍存在的情况下，这个意义不大，因为协商出来的密钥是不一样的，内容就不一样 这个说法不太正确吧。即使使用 https 协议，如果不使用 mask-key 还是不能够解决请求被猜到的情况。设计不当的代理服务器在面临相同请求时，就会返回相同的缓存，这与是否使用 https 完全没有关系。

• 一些常见做法譬如请求后面加个随机数或者时间戳也是同样的道理，都是为了避免缓存

其实在 HTTPS 普遍存在的情况下，这个意义不大，因为协商出来的密钥是不一样的，内容就不一样 这个说法不太正确吧。即使使用 https 协议，如果不使用 mask-key 还是不能够解决请求被猜到的情况。设计不当的代理服务器在面临相同请求时，就会返回相同的缓存，这与是否使用 https 完全没有关系。

我觉得你对这个问题的理解似乎错了。

• 一些常见做法譬如请求后面加个随机数或者时间戳也是同样的道理，都是为了避免缓存

其实在 HTTPS 普遍存在的情况下，这个意义不大，因为协商出来的密钥是不一样的，内容就不一样 这个说法不太正确吧。即使使用 https 协议，如果不使用 mask-key 还是不能够解决请求被猜到的情况。设计不当的代理服务器在面临相同请求时，就会返回相同的缓存，这与是否使用 https 完全没有关系。

这么说吧，其实这个涉及到代理本身的工作原理。
在请求 HTTP 的时候，实际上客户端是这么请求的：

1. TCP socket 连接代理服务器
2. 往代理服务器发送类似下面内容：
   GET http://www.example.com/ HTTP/1.1
   Proxy-Authorization: Basic encoded-credentials
   Accept: text/html
3. 服务端返回给你明文请求结果

对于请求 HTTPS 的情况下，一般客户端是这么请求的

1. TCP socket 连接代理服务器
2. 往代理服务器发送类似下面内容：
   CONNECT www.example.com:443 HTTP/1.1
   Proxy-Authorization: Basic encoded-credentials
3. 服务端返回连接成功的消息
4. 加密啥的客户端直接跟服务端协商

在这种情况下，后续所有传输的信息都是加密信息，每个客户端都是不一样的。也就是说代理服务器看到的内容也是不一样的，即不存在缓存的问题。

另外一种情况是代理服务器直接转发 HTTPS 请求，这种情况我不大确定具体是怎么个协商法，但是确定无疑客户端失去了协商 SSL 协议的能力。只在特殊情况下才适用。

简单的发表一下个人的见解。

1. 数据为何要进行掩码计算。

   根据 https://datatracker.ietf.org/doc/html/rfc6455#section-10.3 中的说明，虽然客户端发送的请求中是按 Websocket 的规范在应用数据前加上了不符合 HTTP 规范的帧，但是仅仅如此还不够，因为无法排除有些不符合要求的代理服务器可能会跳过此类非 HTTP 的帧，从而不正确的处理此帧的载荷。所以采取的防范措施是将客户端发送给服务器的数据进行掩码处理。因为掩码值是 UA（一般是浏览器）随机生成的，而且每一次客户端执行请求时都会不同，所以攻击者无法得知相应的掩码值，自然就无法构造出在进行掩码处理后的数据是模仿 HTTP 规范的数据。

2. 现实网络环境是否存在此漏洞。

   从论文《Talking to Yourself for Fun and Profit》中描述的实验步骤可以看出，实验作者在重现此漏洞时在客户端是用 Flash socket 来实现的，并不是用 Websocket 来实现。

   3. Experiment: To evaluate the practicality of mounting IP hijacking and cache poisoning attacks with the WebSocket handshakes, we implemented prototypes for each WebSocket handshake using Flash sockets and a WebSocket server written in Python. We reused the system from the Java and Flash socket experiment with the following changes. We setup a custom multiplexing server at port 80 on the attacking server, which forwards requests to either a standard Apache server or the WebSocket server depending on the request headers. We ran an advertisement campaign for four successive days in November 2010, spending $20 in the Philippines and $80 globally. Our advertisement contains a SWF which performs the WebSocket handshake, spoofs an HTTP request upon handshake success, and instructs the browser to request a script from the target server using a script tag. We experimented with how intermediaries process each WebSocket handshake.

   所以如果实验作者在伪造 HTTP 请求时没有遵守 Websocket 协议（文中似乎并没说明是否如此），那么只是证明原有规范存在安全风险，但并没有完全证实在现实网络环境存在这样可以利用的漏洞。不过即使如此，这也是一个潜在的风险，从协议层面进行预防御是有必要的。

3. 此设计和 WSS 的关系。

   和 HTTPS 类似，如果 Websocket 数据包在经过代理服务前已经经过加密，即使用 wss，由于内容都是加密过的，代理服务器也无法识别明文，自然无法也不会进行缓存，那么这时无论是否存在掩码的设计，对安全应该都没有什么影响。所以对数据进行掩码计算，主要是为了防范在通讯链路中使用 ws 的节点存在漏洞而设计的。

4. 安全风险完全杜绝了吗？

   答案是否。如果不采用此设计，有可能攻击者只要发布个钓鱼网站链接，就可以在短时间内展开大范围的攻击。在浏览器对数据载荷进行掩码处理后，就通过加大攻击难度从而极大降低了此漏洞被利用的风险。不过攻击者其实仍有机会进行攻击。

   假设现实网络环境中真的存在这样可以被利用的代理服务器，攻击者可以实现自己的客户端和服务端，然后让自己的客户端通过此代理服务器访问他的服务端，于是成功污染此代理服务器实现攻击目的。不过这样的攻击难度就大大增加了，攻击范围也显著缩小。

回来再看还是不太明白，作者提到：

WebSocket的防御措施是mask所有从客户端发往服务器的数据，这样恶意脚本（攻击者）就没法获知网络链路上传输的数据是以何种形式呈现的，所以他没法构造可以被中间设施误解为HTTP请求的frame

不明白为何攻击者就无法获知网络链路上传输的数据了，攻击者只要建立一个钓鱼网站，则他在服务端不是依然可以获取到全部数据吗？

然后还有就是：

为防止攻击者获知网络链路中传输的原始数据，提供不可预测的掩码至关重要。

能举个例子说明一下，如果mask是可预测或者固定的话，攻击者会怎么利用这个来实施攻击？

实施污染攻击的原理是攻击者的服务端返回了一些毒数据，这些非法数据被proxy缓存之后具有毒性。感觉增加mask并不能阻止攻击者的服务端返回毒数据。不知道我哪里理解错了。

哦我明白了！

• 当没有mask，恶意脚本能够轻松伪造一个http请求，然后让浏览器的websocket发送出去毒化proxy。
• 当有mask，脚本还希望继续伪造http请求的话，则必须知道mask的值，并根据公开的算法去构造数据，以使得被浏览器mask之后发送出去的数据依然是http请求 ！

我还是不明白，攻击者当然知道mask的值，mask是客户端产生的，只要攻击者自己实现一个客户端，就可以构造自己想要的数据在网络上传送了。这时如果服务器返回了类似http响应的帧，缓存就被毒化了。

后来者看这里：https://www.youtube.com/watch?v=y074HyGCeuM&list=PLoZQ0sz6CBHGLlYNKB-yzDRasrAYytelS&index=46