10. Security Considerations
10 安全性考虑
This section describes some security considerations applicable to the
WebSocket Protocol. Specific security considerations are described
in subsections of this section.
本节介绍了一些适合WebSocket协议的安全性考虑。特别的安全性考虑在本节的子节中进行描述。
10.1. Non-Browser Clients
The WebSocket Protocol protects against malicious JavaScript running
inside a trusted application such as a web browser, for example, by
checking of the |Origin| header field (see below). See Section 1.6
for additional details. Such assumptions don’t hold true in the case
of a more-capable client.
10.1 非浏览器客户端
WebSocket协议能防止受信任的应用（如浏览器）中的恶意JavaScript运行，比如，通过检查|Origin|头字段。更多细节请参照1.6节。这种假设在多样化客户端上并不永远成立。
While this protocol is intended to be used by scripts in web pages,
it can also be used directly by hosts. Such hosts are acting on
their own behalf and can therefore send fake |Origin| header fields,
misleading the server. Servers should therefore be careful about
assuming that they are talking directly to scripts from known origins
and must consider that they might be accessed in unexpected ways. In
particular, a server should not trust that any input is valid.
EXAMPLE: If the server uses input as part of SQL queries, all input
text should be escaped before being passed to the SQL server, lest
the server be susceptible to SQL injection.
这个协议倾向于在web页面的脚本中使用，但是也可以直接被主机使用。这些主机代表它们自身的利益，因此可以发送模拟的|Origin| 头字段，从而使服务端误入歧途。服务端应该小心这种假设：它们正在直接与已知的域中的脚本交互，它们必须认识到它们有可能被非正常方式访问。特别是服务端不能假设所有的输入都是合法的。例如：服务端使用输入的内容作为SQL查询的一部分，所有的输入文本在传送给SQL server之前都必须处理，避免服务端遭受SQL注入。
10.2. Origin Considerations
Servers that are not intended to process input from any web page but
only for certain sites SHOULD verify the |Origin| field is an origin
they expect. If the origin indicated is unacceptable to the server,
then it SHOULD respond to the WebSocket handshake with a reply
containing HTTP 403 Forbidden status code.
10.2 域注意事项
那些不处理页面输入仅面向个别站点的服务端需要验证 |Origin| 字段是它们期望的域。假如是服务端不接收的域，那么它应该用包含"HTTP 403 拒绝访问的编码"的应答WebSocket握手。
The |Origin| header field protects from the attack cases when the
untrusted party is typically the author of a JavaScript application
that is executing in the context of the trusted client. The client
itself can contact the server and, via the mechanism of the |Origin|
header field, determine whether to extend those communication
privileges to the JavaScript application. The intent is not to
prevent non-browsers from establishing connections but rather to
ensure that trusted browsers under the control of potentially
malicious JavaScript cannot fake a WebSocket handshake.
|Origin|头字段保护免受这样的攻击：非信任的组织是JavaScript应用的作者，在受信任的客户端的上下文中运行。客户端本身可以联系服务端，使用|Origin|头字段机制去决定是否把会话权利扩展到JavaScript应用。目的不是阻止非浏览器建立连接，而是去保证受信任的浏览器能控制恶意的JavaScript不能模拟WebSocket握手。
10.3. Attacks On Infrastructure (Masking)
In addition to endpoints being the target of attacks via WebSockets,
other parts of web infrastructure, such as proxies, may be the
subject of an attack.
10.3 基础实施攻击（掩码）
除了使用WebSocket的终端作为攻击目标外，网络基础设施的其它部分，像代理，也可能成为攻击者。
As this protocol was being developed, an experiment was conducted to
demonstrate a class of attacks on proxies that led to the poisoning
of caching proxies deployed in the wild [TALKING]. The general form
of the attack was to establish a connection to a server under the
"attacker’s" control, perform an UPGRADE on the HTTP connection
similar to what the WebSocket Protocol does to establish a
connection, and subsequently send data over that UPGRADEd connection
that looked like a GET request for a specific known resource (which
in an attack would likely be something like a widely deployed script
for tracking hits or a resource on an ad-serving network). The
remote server would respond with something that looked like a
response to the fake GET request, and this response would be cached
by a nonzero percentage of deployed intermediaries, thus poisoning
the cache. The net effect of this attack would be that if a user
could be convinced to visit a website the attacker controlled, the
attacker could potentially poison the cache for that user and other
users behind the same cache and run malicious script on other
origins, compromising the web security model.
随着协议变得成熟，一个实验证明一类针对代理的攻击能引起部署在野外（in the wild）的缓存代理中毒。攻击的形式是与服务端建立一个攻击者控制的连接，是在HTTP连接上执行UPGRADE 操作就如同WebSocket建立连接时做的一样，随后在UPGRADE 连接上发送数据，就如同为已知资源发送的一个GET请求（在攻击中可能是广为流传的跟踪点击脚本或广告服务的资源）。远程服务会响应一些数据，看上去像对模拟GET请求的响应，这个响应会被中介按百分比进行缓存，从而使缓存代理中毒。这个攻击的网络效果是如果一个用户访问了被攻击者控制的站点，攻击者可能会感染该用户的缓存以及使用同样缓存的用户，然后在其它域上运行恶意脚本，影响站点的安全模型。
To avoid such attacks on deployed intermediaries, it is not
sufficient to prefix application-supplied data with framing that is
not compliant with HTTP, as it is not possible to exhaustively
discover and test that each nonconformant intermediary does not skip
such non-HTTP framing and act incorrectly on the frame payload.
Thus, the defense adopted is to mask all data from the client to the
server, so that the remote script (attacker) does not have control
over how the data being sent appears on the wire and thus cannot
construct a message that could be misinterpreted by an intermediary
as an HTTP request.
为了在已部署的网络设施上避免此类攻击，仅仅对应用数据使用不兼容HTTP的帧前缀是不够的，因为去发现并测试每个跳过非HTTP帧、表现不正常的、不一致的中介是不可能的，因此，采用的机制是把从客户端到服务端的数据进行掩码，因此远方的脚本（攻击者）无法控制网络上的数据是如何发送的，这样就不能组成一个被中介误解为HTTP请求的消息。
Clients MUST choose a new masking key for each frame, using an
algorithm that cannot be predicted by end applications that provide
data. For example, each masking could be drawn from a
cryptographically strong random number generator. If the same key is
used or a decipherable pattern exists for how the next key is chosen,
the attacker can send a message that, when masked, could appear to be
an HTTP request (by taking the message the attacker wishes to see on
the wire and masking it with the next masking key to be used, the
masking key will effectively unmask the data when the client applies it).
客户端对于每个帧都必须选择一个新的掩码钥匙（key），使用一种不能被提供数据的应用预知的算法。例如，每一个掩码可以基于一个随机生成的健壮的密码的数字产生。假如key已经被使用或者存在生成下一个key的模式，攻击者就可以发送一个消息，经过掩码成为一个HTTP请求（攻击者截获信息的目的是查看网络上的信息并用下一个掩码key进行掩码，客户端在使用它的时候就能通过这个key解码数据）。
It is also necessary that once the transmission of a frame from a
client has begun, the payload (application-supplied data) of that
frame must not be capable of being modified by the application.
Otherwise, an attacker could send a long frame where the initial data
was a known value (such as all zeros), compute the masking key being
used upon receipt of the first part of the data, and then modify the
data that is yet to be sent in the frame to appear as an HTTP request
when masked. (This is essentially the same problem described in the
previous paragraph with using a known or predictable masking key.)
If additional data is to be sent or data to be sent is somehow
changed, that new or changed data must be sent in a new frame and
thus with a new masking key. In short, once transmission of a frame
begins, the contents must not be modifiable by the remote script
(application).
还有非常重要的一点是一旦客户端已经开始传输一个帧，这个帧的负载就不能被应用修改。否则攻击者就可以发送一个长数据帧，初始数据是已知的数据，一旦数据的第一部分接收到就开始计算掩码key，然后修改帧中已经被发送的数据，在进行掩码的时候使之展现为一个HTTP请求。（这个问题同上章描述的已知或预知掩码key的问题一样严重）假如额外的数据被发送或发送的数据被某种方式改变了，新的或改变后的数据必须在一个新的帧中发送并采用一个新的掩码key。简单地说，一旦数据开始传输，应用或脚本就不能再对它进行修改。
The threat model being protected against is one in which the client
sends data that appears to be an HTTP request. As such, the channel
that needs to be masked is the data from the client to the server.
The data from the server to the client can be made to look like a
response, but to accomplish this request, the client must also be
able to forge a request. As such, it was not deemed necessary to
mask data in both directions (the data from the server to the client
is not masked).0
一种被防止的危险是客户端发送HTTP请求的方式。就其本身而论，需要被掩码的是客户端发送到服务端的数据。为了回应服务端发往客户端的响应数据，客户端需要打造一个请求。这种情况下，双方都不需要对数据进行掩码（服务端发往客户端的数据是不掩码的）。
Despite the protection provided by masking, non-compliant HTTP
proxies will still be vulnerable to poisoning attacks of this type by
clients and servers that do not apply masking.
尽管掩码提供了保护，但是不服从的HTTP代理在处理不进行掩码的客户端和服务端的时候依旧容易受到这种攻击的感染。
10.4. Implementation-Specific Limits
Implementations that have implementation- and/or platform-specific
limitations regarding the frame size or total message size after
reassembly from multiple frames MUST protect themselves against
exceeding those limits. (For example, a malicious endpoint can try
to exhaust its peer’s memory or mount a denial-of-service attack by
sending either a single big frame (e.g., of size 2**60) or by sending
a long stream of small frames that are a part of a fragmented
message.) Such an implementation SHOULD impose a limit on frame
sizes and the total message size after reassembly from multiple
frames.
10.4 特定实现的限制
那些从多样化的帧转换过来的、对帧大小或消息大小有特殊限制的实现或平台，需要防止超过这些限制。（例如，一个恶意的终端可以耗费它宝贵的内存资源或执行拒绝服务攻击，通过发送一个大帧或一个分片消息中的多个部分组成的持久帧）从多样化帧转换过来的这样的实现需要在帧大小和消息总大小上设置限制。
10.5. WebSocket Client Authentication
This protocol doesn’t prescribe any particular way that servers can
authenticate clients during the WebSocket handshake. The WebSocket
server can use any client authentication mechanism available to a
generic HTTP server, such as cookies, HTTP authentication, or TLS
authentication.
10.5 WebSocket客户端验证
这个协议中没有为服务端通过WebSocket握手验证客户端提供任何途径。服务端可以使用任何适用于HTTP服务端的客户端的认证机制，如cookies，http认证或TLS认证。
10.6. Connection Confidentiality and Integrity
Connection confidentiality and integrity is provided by running the
WebSocket Protocol over TLS (wss URIs). WebSocket implementations
MUST support TLS and SHOULD employ it when communicating with their
peers.
10.6 连接加密和完整
WebSocket协议通过TLS提供连接的加密和完整性。WebSocket的实现必须实现TLS，当与其它服务器交互的时候应该部署TLS。
For connections using TLS, the amount of benefit provided by TLS
depends greatly on the strength of the algorithms negotiated during
the TLS handshake. For example, some TLS cipher mechanisms don’t
provide connection confidentiality. To achieve reasonable levels of
protection, clients should use only Strong TLS algorithms. "Web
Security Context: User Interface Guidelines"
使用TLS的连接，TLS提供安全的量取决于TLS握手时执行的算法的强壮程度。例如，有些TLS算法不提供连接加密。为了达到要起的安全级别，客户端必须选用强壮的TLS算法。“网络安全上下文：用户接口指导方案”。
[W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS
algorithms. [RFC5246] provides additional guidance in Appendix A.5
and Appendix D.3.
[W3C.REC-wsc-ui-20100812]讨论了强壮TLS算法的组成。这个在[RFC5246]中有额外介绍。
10.7. Handling of Invalid Data
Incoming data MUST always be validated by both clients and servers.
If, at any time, an endpoint is faced with data that it does not
understand or that violates some criteria by which the endpoint
determines safety of input, or when the endpoint sees an opening
handshake that does not correspond to the values it is expecting
(e.g., incorrect path or origin in the client request), the endpoint
MAY drop the TCP connection. If the invalid data was received after
a successful WebSocket handshake, the endpoint SHOULD send a Close
frame with an appropriate status code (Section 7.4) before proceeding
to _Close the WebSocket Connection_. Use of a Close frame with an
appropriate status code can help in diagnosing the problem. If the
invalid data is sent during the WebSocket handshake, the server
SHOULD return an appropriate HTTP [RFC2616] status code.
A common class of security problems arises when sending text data
using the wrong encoding. This protocol specifies that messages with
a Text data type (as opposed to Binary or other types) contain UTF-8-
encoded data. Although the length is still indicated and
applications implementing this protocol should use the length to
determine where the frame actually ends, sending data in an improper
encoding may still break assumptions that applications built on top
of this protocol may make, leading to anything from misinterpretation
of data to loss of data or potential security bugs.
10.7 处理非法数据
客户端和服务端来往的数据必须一直是合法的。假如一个终端接收到这样的数据：它不认识或它违反了某些规则，这些数据来源于输入或终端不期望的开放式握手，它将放弃这个TCP连接。如果接收到了非法的数据，客户端在关闭连接之前会发送一个带有合适关闭码的关闭帧。使用带有合适关闭码的关闭帧可以有效预防这个问题。假如在握手过程中发送了非法数据，服务端需要返回合适的HTTP状态码。一个通常会发生的安全性问题是发送错误编码的文本数据。本协议规定文本数据必须是UTF-8编码的。尽管长度仍然显示并且实现了本协议的应用应该使用长度去决定数据是否真正结束，发送错误编码的数据仍然会打破假设，构建在该协议之上的应用会因为对数据的错误理解导致数据丢或潜在的安全性问题。
10.8. Use of SHA-1 by the WebSocket Handshake
The WebSocket handshake described in this document doesn’t depend on
any security properties of SHA-1, such as collision resistance or
resistance to the second pre-image attack (as described in
[RFC4270]).
10.8 WebSocket握手中SHA-1的使用
本文中描述的WebSocket握手不依赖于SHA-1的任何安全特性，像抗碰撞性或抗第二原像攻击。