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的任何安全特性，像抗碰撞性或抗第二原像攻擊。