概述

本文为 WebSocket 协定的第九章，本文翻译的主要内容为 WebSocket 平安性相干内容。

10 平安性斟酌（协定正文）

这一章形貌了一些 WebSocket 协定的可用的平安性斟酌。这一章的小节形貌了这些特定的平安性斟酌。

10.1 非浏览器客户端

WebSocket 协定防备在受信托的运用比方 Web 浏览器中实行的歹意 JavaScript 代码，比方经由过程搜检Origin头字段（见下面）。见第 1.6 节去相识更多概况。这类假定在更有才能的客户端的状况下不成立。

这个协定可以被网页中的剧本运用，也可以经由过程宿主直接运用。这些宿主是代表本身的好处的，因而可以发送假的Origin头字段来诳骗效劳端。因而效劳端关于他们正在和已知的源的剧本直接通讯的假定须要音讯，而且必需以为他们可以经由过程没有预期的体式格局接见。特别地，效劳端不应当置信托何输入都是有用的。

示例：假如效劳端运用输入的内容作为一部份的 SQL 查询语句，一切的输入文本都必需在通报给 SQL 效劳器时举行编码，以防止效劳端遭到 SQL 注入进击。

10.2 源斟酌

只处置惩罚特定站点，不盘算处置惩罚任何 Web 页面的数据效劳器应当考证Origin字段是不是是他们预期的。假如效劳端收到的源字段是不接受的，那末他应当经由过程包括 HTTP 禁止状况码为 403 的要求相应作为 WebSocket 握手的相应。

当不信托的一方是 JavaScript 运用作者并存在受信托的客户端中运转时，Origin字段可以防止涌现这类进击的状况。客户端可以衔接到效劳端，经由过程协定中的Origin字段，肯定是不是开放衔接的权限给 JavaScript 运用。这么做的目的不是组织非浏览器运用竖立衔接，而是保证在受信托的浏览器中可以运转的歹意 JavaScript 代码并不会构建一个假的 WebSocket 握手。

10.3 基础设施进击（增加掩码）

除了终端可以会成为经由过程 WebSocket 被进击的目的以外，收集基础设施的别的一部份，比方代办，也有多是进击的对象。

这个协定生长后，经由过程一个试验考证了布置在外部的缓存效劳器因为一系列在代办上面的进击致使投毒。平常情势的进击就是在进击者掌握下竖立一个与效劳端的衔接，完成一个与 WebSocket 协定竖立衔接类似的 HTTP UPGRADE 衔接，然后经由过程晋级今后的衔接发送数据，看起来就像是针对已知的特定资本（在进击中，这可以类似于普遍布置的剧本，用于跟踪广告效劳收集上的点击或资本）举行 GET 要求。远端效劳器可以会经由过程一些看上去像相应数据的来相应假的 GET 要求，然后这个相应就会根据非零百分比的已布置中介缓存，因而致使缓存投毒。这个进击带来的影响就是，假如一个用户可以一般的接见一个进击者掌握的网网站，那末进击者可以针对这个用户举行缓存投毒，在雷同缓存的背面其他用户会运转其他源的歹意剧本，损坏 Web 平安模子。

为了防止对中介效劳的此类进击，运用不符合 HTTP 的数据帧中为运用程序的数据增加前缀是不够的，我们不可以细致的搜检和测试每个不合规范的中介效劳有无跳过这类非 HTTP 帧，或许对帧载荷处置惩罚不正确的状况。因而，采纳的防备步伐是对客户端发送给效劳端的一切数据增加掩码，如许的话远端的剧本（进击者）就不可以掌握发送的数据怎样涌现在线路上，因而就不可以组织一条被中介误会的 HTPT要求。

客户端必需为每一帧挑选一个新的掩码值，运用一个不可以被运用展望到的算法来举行通报数据。比方，每个掩码值可以经由过程一个加密强随机数天生器来天生。假如雷同的值已被运用过或许已存在一种体式格局可以推断出下一个值怎样挑选时，进击这个可以发送一个增加了掩码的音讯，来模仿一个 HTTP 要求（经由过程在线路上吸收进击者愿望看到的音讯，运用下一个被运用的掩码值来对数据举行增加掩码，当客户端运用它时，这个掩码值可以有用地反掩码数据）。

当从客户端最先通报第一帧时，这个帧的有用载荷（运用程序供应的数据）就不可以被客户端运用程序修正，这个战略是很主要的。不然，进击者可以发送一个都是已知值（比方悉数为 0）的初始值的很长的帧，盘算收到第一部份数据时运用过的掩码，然后修正帧中还没有发送的数据，以便在增加掩码时显现为 HTTP 要求。（这与我们在之前的段落中形貌的运用已知的值和可展望的值作为掩码值，现实上是雷同的题目。）假如别的的数据已发送了，或许要发送的数据有所转变，那末新的数据或许修正的数据必需运用一个新的数据帧举行发送，因而也须要挑选一个新的掩码值。简短来讲，一旦一个帧的传输最先后，内容不可以被远端的剧本（运用）修正。

受庇护的要挟模子是客户端发送看似HTTP要求的数据的模子。因而，从客户端发送给效劳端的频道数据须要增加掩码值。从效劳端到客户端的数据看上去像是一个要求的相应，然则，为了完成一次要求，客户端也须要可以捏造要求。因而，我们不以为须要在双向传输上增加掩码。（效劳端发送给客户端的数据不须要增加掩码）

只管经由过程增加掩码供应了庇护，然则不兼容的 HTTP 代办依然因为客户端和效劳端之间不支撑增加掩码而遭到这类范例的进击。

10.4 指定完成的限定

在从多个帧从新组装后，关于帧大小或总音讯大小具有完成和必需防止本身凌驾相干的多平台特定限定带来的影响。（比方：一个歹意的终端可以会尝试耗尽对端的内存或许经由过程发送一个大的帧（比方：大小为 2 ** 60）或发送一个长的由很多分片帧组成的流来举行拒绝效劳进击）。这些完成应当对帧的大小和组装事后的包的总大小有肯定的限定。

10.5 WebSocket 客户端认证

这个协定在 WebSocket 握手时，没有划定效劳端可以运用哪一种体式格局举行认证。WebSocket 效劳器可以运用恣意 HTTP 效劳器通用的认证机制，比方： Cookie、HTTP 认证或许 TLS 认证。

10.6 衔接保密性和完整性

衔接保密性是基于运转 TLS 的 WebSocket 协定（wss 的 URLs）。WebSocket 协定完成必需支撑 TLS，而且应当在与对端举行数据传输时运用它。

假如在衔接中运用 TLS，TLS带来的衔接的收益异常依赖于 TLS 握手时的算法的强度。比方，一些 TLS 的加密算法不供应衔接保密性。为了完成合理登记的庇护步伐，客户端应当只运用强 TLS 算法。“Web 平安：用户接口指南”（W3C.REC-wsc-ui-20100812）议论了什么是强 TLS 算法。RFC5246 的附录 A.5和附录 D.3供应了别的的指点。

10.7 处置惩罚无用数据

传入的数据必需经由客户端和效劳端的认证。假如，在某个时刻，一个终端面临它没法明白的数据或许违反了这个终端定义的输入平安范例和规范，或许这个终端在最先握手时没有收到对应的预期值时（在客户端要求中不正确的途径或许源），终端应当封闭 TCP 衔接。假如在胜利的握手后收到了无效的数据，终端应当在进入封闭 WebSocket流程前，发送一个带有适宜的状况码（第 7.4 节）的封闭帧。运用一个适宜的状况码的封闭帧有助于诊断这个题目。假如这个无效的数据是在 WebSocket 握手时收到的，效劳端应当相应一个适宜的 HTTP 状况码（RFC2616）。

运用毛病的编码来发送数据是一类通用的平安题目。这个协定指定文本范例数据（而不是二进制或许其他范例）的音讯运用 UTF-8 编码。虽然依然可以获得长度值，但完成此协定的运用程序应运用这个长度来肯定帧现实完毕的位置，发送不合理的编码数据依然会致使基于此协定构建的运用程序可以会致使从数据的毛病会释到数据丧失或潜伏的平安漏洞涌现。

10.8 在 WebSocket 握手中运用 SHA-1

在这个文档中形貌的 WebSocket 握手协定是不依赖恣意 SHA-1 的平安属性，流入抗冲击性和对第二次前映像进击的抵抗力（就像 RFC4270 形貌的一样）。