这是很多问题。我们将坚持核心问题和缓解技术：

我的连接有可能被缓存代理代理或以其他方式检查。如果我可以将正确的数据放入我的请求并将所需的数据放入响应中，我就有很大的机会欺骗代理。基本思想在一篇名为《为乐趣和利润而自言自语》的论文中得到了证明。

作为一个攻击客户端，我想做的是将包含看似有效的请求字符串的内容推送到服务器：

... something ...

GET /jquery-latest.min.js HTTP/1.1
Host: code.jquery.com
...
... something that triggers the desired response from the server

唯一的要求是您想办法让服务器向您发送所需的字符串，这通常不会太难。然后服务器可以预见地鹦鹉返回所需的响应：

HTTP/1.1 200 OK
content-type: text/javascript

... my trojaned javascript file

就服务器和客户端而言，我们只是来回传递字符串。没有真正的担心理由，没有造成伤害，没有可能的利用媒介。

但是监视流量的代理会看到看起来很像 HTTP 请求的东西，然后看起来很像 HTTP 响应。如果代理足够幼稚（很多都是），它将相应地更新其缓存，以便下次有人通过代理请求http://code.jquery.com/jquery-latest.min.js 时，他们'我会得到我的木马版本，而不是真正的CDN 交付的代码。

为了防止这种情况，一个方向的流量（在这种情况下是客户端到服务器）被轻微扰乱。它不必是加密安全的，因为您不在乎是否有人可以对其进行解码。您只需要确保客户端无法预测他将通过网络传输的字符串。而且由于他无法预测自己的网络流量，因此他无法使用这种机制来触发代理服务器来更新其缓存。

如果请求和响应都包含看起来像 HTTP 的流量，代理只会看到可缓存的事件。所以只有一个方向需要打乱。

这不适用于 XHR，因为 XHR 请求是“正常”的 HTTP 请求，并且被代理很好地理解。

帧屏蔽如何防止缓存中毒？

这个想法是通过破坏帧数据来防止帧的内容被解释为正在进行的一些 HTTP 请求/响应。

实际上，我认为这完全没有用。

假设我编写了一个简单的 WebSocket 客户端（实际上是真的），作为帧的发送者，我可以选择掩码 dword。我所要做的就是用中间的一些 HTTP 标头组成一帧随机数据，并应用异或掩码算法。然后使用相同的掩码在我的 WebSocket 中发送该帧，WebSocket 的异或掩码只会导致 HTTP 部分成为线路上的纯文本。

你的，托尼威尔克