# 安全注意事項
本章描述了一些適用于WebSocket協(xié)議的安全注意事項。具體的安全注意事項在本章的字章節(jié)描述。
## 10.1.非瀏覽器客戶端
WebSocket協(xié)議防止惡意的JavaScript運(yùn)行在一個受信任的應(yīng)用內(nèi)部，比如web瀏覽器，例如，通過檢查頭字段|Origin|（見下文）。更多細(xì)節(jié)請參考1.6節(jié)。在一個更強(qiáng)大的客戶端的情況下，這樣的假設(shè)不成立。
雖然該協(xié)議的目的是被web頁面中的腳本使用，它也可以被主機(jī)直接使用。這樣的主機(jī)按照它們自己的行為行事，因此可以發(fā)送偽造的|Origin|頭字段，騙過服務(wù)器。因此服務(wù)器應(yīng)該小心，假設(shè)它們是直接與來自已知源的腳本通信，且必須考慮到它們可能以非預(yù)期方式訪問。尤其，服務(wù)器不應(yīng)該相信任何輸入是有效的。
例如：如果服務(wù)器使用輸入作為SQL查詢的一部分，所有輸入文本在傳輸?shù)絊QL服務(wù)器之前應(yīng)該被轉(zhuǎn)義，以免服務(wù)器受到SQL注入攻擊。
## 10.2. Origin注意事項
服務(wù)器不打算處理來自任意web頁面的輸入，但僅限于網(wǎng)站應(yīng)該驗證|Origin|頭是一個它們盼望的源。如果源指示是服務(wù)器不可接受的，那么它應(yīng)該以一個包含HTTP 403 Forbidden的狀態(tài)碼的回復(fù)響應(yīng)WebSocket握手。
當(dāng)不受信任方通常是一個執(zhí)行在受信任的客戶端上下文中的JavaScript應(yīng)用的作者時，|Origin|頭字段可以保護(hù)攻擊的情況?？蛻舳吮旧砜梢耘c服務(wù)器聯(lián)系，并通過| Origin|頭字段機(jī)制，決定是否提供JavaScript應(yīng)用的這些通信權(quán)限。目的不是為了阻止非瀏覽器建立連接，而是確保受信的瀏覽器在潛在的惡意JavaScript控制下不能偽造WebSocket握手。
## 10.3.攻擊基礎(chǔ)設(shè)施（掩碼）
除了端點是WebSocket攻擊的目標(biāo)之外，web基礎(chǔ)設(shè)施的其他部分，如代理，也可能是攻擊的對象。在本協(xié)議正在開發(fā)時，進(jìn)行了一個實驗旨在演示一類代理上的攻擊，其導(dǎo)致部署在野的緩存代理中毒[討論]。一般的攻擊形式是在“攻擊者”的控制下建立一個到服務(wù)器的連接，執(zhí)行類似于WebSocket協(xié)議建立連接的HTTP連接上的UPGRADE，且隨后在已經(jīng)UPGRADE的連接上發(fā)送數(shù)據(jù)，看起來像一個GET請求一個特定的已知資源（在一次攻擊中，很可能會像廣泛部署的用于跟蹤點擊或一個廣告服務(wù)網(wǎng)絡(luò)資源的腳本）。遠(yuǎn)程服務(wù)器響應(yīng)的東西看起來像是到偽造的GET請求的一個響應(yīng)，且這個響應(yīng)將被一個非零百分比的部署的中間件緩存，因此使緩存中毒了。這種攻擊的靜效應(yīng)將是如果能說服用戶去訪問攻擊者控制的網(wǎng)站，攻擊者可能使用戶和其他晚于相同緩存的用戶的緩存中毒且在其他源運(yùn)行惡意腳本，影響網(wǎng)絡(luò)安全模型。
為避免這種部署的中間件上的攻擊，前置不兼容HTTP的和幀一起的應(yīng)用提供的數(shù)據(jù)是不夠的，因為無法詳盡地發(fā)現(xiàn)和測試每一個不符合中間件的不跳過這樣的非HTTP幀和錯誤地假裝幀負(fù)載。
因此，采用的防御是掩碼所有從客戶端到服務(wù)器端發(fā)送的數(shù)據(jù)，使遠(yuǎn)程腳本（攻擊者）無法控制數(shù)據(jù)如何在電線上發(fā)送，從而無法構(gòu)造一個可能被中間件誤解釋的作為一個HTTP請求的消息。
客戶端必須為每一幀選擇一個新的掩碼密鑰，使用一個不能被提供數(shù)據(jù)的終端應(yīng)用預(yù)測。例如，每次掩碼可以從一個強(qiáng)加密的隨機(jī)數(shù)生成器獲取。如果使用相同的密鑰或存在一個可預(yù)測的模式用于選擇下一個密鑰，當(dāng)掩碼后，攻擊者可以發(fā)送一個消息，可能作為一個HTTP請求出現(xiàn)（通過交換消息，攻擊者希望觀察線上并用下一個將被使用的掩碼密鑰掩碼它，當(dāng)客戶端應(yīng)用它時掩碼密鑰將有效的解碼數(shù)據(jù)）。 一旦從客戶端傳輸一個幀已經(jīng)開始，幀的負(fù)載（應(yīng)用提供的數(shù)據(jù)）必須不能被應(yīng)用修改也是必要的。
否則，攻擊者可能發(fā)送一個已知初始數(shù)據(jù)（如都是0）的長幀，一收到數(shù)據(jù)的第一部分后就開始計算使用的掩碼密鑰，當(dāng)掩碼后，接著修改尚未發(fā)送的作為一個請求出現(xiàn)的幀中的數(shù)據(jù)（這本質(zhì)上是和前面段落描述的使用一個已知的或可預(yù)測的掩碼密鑰是相同的問題）。 如果需要發(fā)送額外的數(shù)據(jù)或要發(fā)送的數(shù)據(jù)以某種方式修改了，新的或修改了的數(shù)據(jù)必須在一個新的幀中發(fā)送，那么需要一個新的掩碼密鑰?？傊坏╅_始傳輸一個幀，對于遠(yuǎn)程腳本（應(yīng)用）來說，內(nèi)容必須不能是可修改的。
威脅模型用來保護(hù)客戶端發(fā)送的在一個請求出現(xiàn)的數(shù)據(jù)。因此，需要掩碼的信道是從客戶端到服務(wù)器的數(shù)據(jù)。服務(wù)器到客戶端的數(shù)據(jù)可以作出看起來像一個響應(yīng)，但為了完成這個請求，客戶端也必須有能力去偽造一個請求。因此，沒必要在兩個方向上掩碼數(shù)據(jù)（從客戶端到服務(wù)器的數(shù)據(jù)沒有掩碼）。
盡管掩碼提供了保護(hù)，對于客戶端和服務(wù)器沒有掩碼的這種類型的中毒攻擊，非兼容HTTP代理將依然是脆弱的。
## 10.4.實現(xiàn)特定限制
實現(xiàn)已經(jīng)實現(xiàn)— 和/或特定平臺的有關(guān)幀大小或總消息大小的限制，從多個幀重新組裝后，必須保證它們自己不超過這些限制。（例如，一個惡意終端無論是通過單一的大幀（例如，2**60大?。┻€是通過發(fā)送一個長流的分片消息的一部分的小幀，可以設(shè)法耗盡它的對等體端點（Peer，即要攻擊的那一方）的內(nèi)存或安裝一個拒絕服務(wù)攻擊）。這樣的實現(xiàn)應(yīng)該對幀大小和和從多個幀重組后的總消息大小加以限制。
## 10.5.WebSocket客戶端驗證
本規(guī)范沒有規(guī)定任何特定的方式在WebSocket握手期間服務(wù)器可以驗證客戶端。WebSocket服務(wù)器可以使用任何客戶端對普通HTTP服務(wù)器可用的驗證機(jī)制，如Cookie，HTTP驗證，或者TLS驗證。
## 10.6.連接的保密性和完整性
連接的保密性和完整性是通過運(yùn)行在TLS（wss URI）上WebSocket協(xié)議提供的。WebSocket實現(xiàn)必須支持TLS并應(yīng)該在與它們的對等端點通信時使用它。
對于使用TLS的連接，TLS提供的受益量在很大程度上取決于在TLS握手期間協(xié)商的算法強(qiáng)度。例如，一些TLS加密機(jī)制不提供連接的保密性。為了實現(xiàn)合理級別的保護(hù)，客戶端應(yīng)該僅適用強(qiáng)TLS算法?！癢eb安全上下文：用戶接口指南”[[W3C.REC-wsc-ui-20100812](http://tools.ietf.org/html/rfc6455#ref-W3C.REC-wsc-ui-20100812)]討論了什么構(gòu)成強(qiáng)TLS算法。[[RFC5246](http://www.faqs.org/rfcs/rfc5246.html)]的[附錄A.5](http://tools.ietf.org/html/rfc6455#appendix-A.5)和[附錄D.3](http://tools.ietf.org/html/rfc6455#appendix-D.3)中提供了額外的指導(dǎo)。
## 10.7.處理無效數(shù)據(jù)
傳入的數(shù)據(jù)必須始終由客戶端和服務(wù)器驗證。如果，在任何時候，一個端點不理解它的數(shù)據(jù)或違反了一些端點確定的安全輸入標(biāo)準(zhǔn)，或當(dāng)端點看到一個打開階段握手沒有符合它盼望的值（例如，在客戶端請求中不正確的路徑或源），端點可以終止TCP連接。如果在WebSocket握手成功后接收到了無效數(shù)據(jù)，端點應(yīng)該在進(jìn)行*關(guān)閉WebSocket連接*之前發(fā)送一個帶有適當(dāng)狀態(tài)碼（[7.4節(jié)](http://tools.ietf.org/html/rfc6455#section-7.4)）的關(guān)閉幀。使用一個帶有適當(dāng)狀態(tài)碼的關(guān)閉幀能幫助診斷問題。如果在WebSocket握手期間發(fā)送了無效的數(shù)據(jù)，服務(wù)器應(yīng)該返回一個適當(dāng)?shù)腍TTP[[RFC2616](http://tools.ietf.org/html/rfc2616)]狀態(tài)碼。使用錯誤的編碼發(fā)送文本數(shù)據(jù)是通常出現(xiàn)的一類安全問題。本協(xié)議規(guī)定一個Text數(shù)據(jù)類型（而不是Binary或其他類型）的消息包含UTF-8編碼的數(shù)據(jù)。雖然仍指定了長度，且實現(xiàn)本協(xié)議的應(yīng)用應(yīng)該使用長度來決定幀從哪真正結(jié)束，但以一個不當(dāng)?shù)木幋a發(fā)送數(shù)據(jù)仍可能打破建立在本協(xié)議之上的應(yīng)用的假設(shè)，導(dǎo)致從誤解釋數(shù)據(jù)到丟失數(shù)據(jù)或潛在的安全漏洞。
## 10.8.使用SHA-1的WebSocket握手
本文檔中描述的WebSocket握手不依賴于任何SHA-1安全特性，例如抗碰撞性或抗第二前像攻擊（如同[[RFC4270](http://tools.ietf.org/html/rfc4270)]中的描述）。
