摘要：概述本文為協(xié)議的第九章，本文翻譯的主要內(nèi)容為安全性相關(guān)內(nèi)容。安全性考慮協(xié)議正文這一章描述了一些協(xié)議的可用的安全性考慮。連接保密性和完整性連接保密性是基于運(yùn)行的協(xié)議的。使用一個(gè)合適的狀態(tài)碼的關(guān)閉幀有助于診斷這個(gè)問題。

本文為 WebSocket 協(xié)議的第九章，本文翻譯的主要內(nèi)容為 WebSocket 安全性相關(guān)內(nèi)容。

這一章描述了一些 WebSocket 協(xié)議的可用的安全性考慮。這一章的小節(jié)描述了這些特定的安全性考慮。

WebSocket 協(xié)議防止在受信任的應(yīng)用例如 Web 瀏覽器中執(zhí)行的惡意 JavaScript 代碼，例如通過檢查Origin頭字段（見下面）。見第 1.6 節(jié)去了解更多詳情。這種假設(shè)在更有能力的客戶端的情況下不成立。

這個(gè)協(xié)議可以被網(wǎng)頁中的腳本使用，也可以通過宿主直接使用。這些宿主是代表自己的利益的，因此可以發(fā)送假的Origin頭字段來欺騙服務(wù)端。因此服務(wù)端對(duì)于他們正在和已知的源的腳本直接通信的假設(shè)需要消息，并且必須認(rèn)為他們可能通過沒有預(yù)期的方式訪問。特別地，服務(wù)端不應(yīng)該相信任何輸入都是有效的。

示例：如果服務(wù)端使用輸入的內(nèi)容作為一部分的 SQL 查詢語句，所有的輸入文本都必須在傳遞給 SQL 服務(wù)器時(shí)進(jìn)行編碼，以免服務(wù)端受到 SQL 注入攻擊。

只處理特定站點(diǎn)，不打算處理任何 Web 頁面的數(shù)據(jù)服務(wù)器應(yīng)該驗(yàn)證Origin字段是否是他們預(yù)期的。如果服務(wù)端收到的源字段是不接受的，那么他應(yīng)該通過包含 HTTP 禁止?fàn)顟B(tài)碼為 403 的請(qǐng)求響應(yīng)作為 WebSocket 握手的響應(yīng)。

當(dāng)不信任的一方是 JavaScript 應(yīng)用作者并存在受信任的客戶端中運(yùn)行時(shí)，Origin字段可以避免出現(xiàn)這種攻擊的情況?？蛻舳丝梢赃B接到服務(wù)端，通過協(xié)議中的Origin字段，確定是否開放連接的權(quán)限給 JavaScript 應(yīng)用。這么做的目的不是組織非瀏覽器應(yīng)用建立連接，而是保證在受信任的瀏覽器中可能運(yùn)行的惡意 JavaScript 代碼并不會(huì)構(gòu)建一個(gè)假的 WebSocket 握手。

除了終端可能會(huì)成為通過 WebSocket 被攻擊的目標(biāo)之外，網(wǎng)絡(luò)基礎(chǔ)設(shè)施的另外一部分，例如代理，也有可能是攻擊的對(duì)象。

這個(gè)協(xié)議發(fā)展后，通過一個(gè)實(shí)驗(yàn)驗(yàn)證了部署在外部的緩存服務(wù)器由于一系列在代理上面的攻擊導(dǎo)致投毒。一般形式的攻擊就是在攻擊者控制下建立一個(gè)與服務(wù)端的連接，實(shí)現(xiàn)一個(gè)與 WebSocket 協(xié)議建立連接相似的 HTTP UPGRADE 連接，然后通過升級(jí)以后的連接發(fā)送數(shù)據(jù)，看起來就像是針對(duì)已知的特定資源（在攻擊中，這可能類似于廣泛部署的腳本，用于跟蹤廣告服務(wù)網(wǎng)絡(luò)上的點(diǎn)擊或資源）進(jìn)行 GET 請(qǐng)求。遠(yuǎn)端服務(wù)器可能會(huì)通過一些看上去像響應(yīng)數(shù)據(jù)的來響應(yīng)假的 GET 請(qǐng)求，然后這個(gè)響應(yīng)就會(huì)按照非零百分比的已部署中介緩存，因此導(dǎo)致緩存投毒。這個(gè)攻擊帶來的影響就是，如果一個(gè)用戶可以正常的訪問一個(gè)攻擊者控制的網(wǎng)網(wǎng)站，那么攻擊者可以針對(duì)這個(gè)用戶進(jìn)行緩存投毒，在相同緩存的后面其他用戶會(huì)運(yùn)行其他源的惡意腳本，破壞 Web 安全模型。

為了避免對(duì)中介服務(wù)的此類攻擊，使用不符合 HTTP 的數(shù)據(jù)幀中為應(yīng)用程序的數(shù)據(jù)添加前綴是不夠的，我們不可能詳細(xì)的檢查和測(cè)試每一個(gè)不合標(biāo)準(zhǔn)的中介服務(wù)有沒有跳過這種非 HTTP 幀，或者對(duì)幀載荷處理不正確的情況。因此，采用的防御措施是對(duì)客戶端發(fā)送給服務(wù)端的所有數(shù)據(jù)添加掩碼，這樣的話遠(yuǎn)端的腳本（攻擊者）就不能夠控制發(fā)送的數(shù)據(jù)如何出現(xiàn)在線路上，因此就不能夠構(gòu)造一條被中介誤解的 HTPT請(qǐng)求。

客戶端必須為每一幀選擇一個(gè)新的掩碼值，使用一個(gè)不能夠被應(yīng)用預(yù)測(cè)到的算法來進(jìn)行傳遞數(shù)據(jù)。例如，每一個(gè)掩碼值可以通過一個(gè)加密強(qiáng)隨機(jī)數(shù)生成器來生成。如果相同的值已經(jīng)被使用過或者已經(jīng)存在一種方式能夠判斷出下一個(gè)值如何選擇時(shí)，攻擊這個(gè)可以發(fā)送一個(gè)添加了掩碼的消息，來模擬一個(gè) HTTP 請(qǐng)求（通過在線路上接收攻擊者希望看到的消息，使用下一個(gè)被使用的掩碼值來對(duì)數(shù)據(jù)進(jìn)行添加掩碼，當(dāng)客戶端使用它時(shí)，這個(gè)掩碼值可以有效地反掩碼數(shù)據(jù)）。

當(dāng)從客戶端開始傳遞第一幀時(shí)，這個(gè)幀的有效載荷（應(yīng)用程序提供的數(shù)據(jù)）就不能夠被客戶端應(yīng)用程序修改，這個(gè)策略是很重要的。否則，攻擊者可以發(fā)送一個(gè)都是已知值（例如全部為 0）的初始值的很長(zhǎng)的幀，計(jì)算收到第一部分?jǐn)?shù)據(jù)時(shí)使用過的掩碼，然后修改幀中尚未發(fā)送的數(shù)據(jù)，以便在添加掩碼時(shí)顯示為 HTTP 請(qǐng)求。（這與我們?cè)谥暗亩温渲忻枋龅氖褂靡阎闹岛涂深A(yù)測(cè)的值作為掩碼值，實(shí)際上是相同的問題。）如果另外的數(shù)據(jù)已經(jīng)發(fā)送了，或者要發(fā)送的數(shù)據(jù)有所改變，那么新的數(shù)據(jù)或者修改的數(shù)據(jù)必須使用一個(gè)新的數(shù)據(jù)幀進(jìn)行發(fā)送，因此也需要選擇一個(gè)新的掩碼值。簡(jiǎn)短來說，一旦一個(gè)幀的傳輸開始后，內(nèi)容不能夠被遠(yuǎn)端的腳本（應(yīng)用）修改。

受保護(hù)的威脅模型是客戶端發(fā)送看似HTTP請(qǐng)求的數(shù)據(jù)的模型。因此，從客戶端發(fā)送給服務(wù)端的頻道數(shù)據(jù)需要添加掩碼值。從服務(wù)端到客戶端的數(shù)據(jù)看上去像是一個(gè)請(qǐng)求的響應(yīng)，但是，為了完成一次請(qǐng)求，客戶端也需要可以偽造請(qǐng)求。因此，我們不認(rèn)為需要在雙向傳輸上添加掩碼。（服務(wù)端發(fā)送給客戶端的數(shù)據(jù)不需要添加掩碼）

盡管通過添加掩碼提供了保護(hù)，但是不兼容的 HTTP 代理仍然由于客戶端和服務(wù)端之間不支持添加掩碼而受到這種類型的攻擊。

在從多個(gè)幀重新組裝后，對(duì)于幀大小或總消息大小具有實(shí)現(xiàn)和必須避免自己超過相關(guān)的多平臺(tái)特定限制帶來的影響。（例如：一個(gè)惡意的終端可能會(huì)嘗試耗盡對(duì)端的內(nèi)存或者通過發(fā)送一個(gè)大的幀（例如：大小為 2 ** 60）或發(fā)送一個(gè)長(zhǎng)的由許多分片幀構(gòu)成的流來進(jìn)行拒絕服務(wù)攻擊）。這些實(shí)現(xiàn)應(yīng)該對(duì)幀的大小和組裝過后的包的總大小有一定的限制。

這個(gè)協(xié)議在 WebSocket 握手時(shí)，沒有規(guī)定服務(wù)端可以使用哪種方式進(jìn)行認(rèn)證。WebSocket 服務(wù)器可以使用任意 HTTP 服務(wù)器通用的認(rèn)證機(jī)制，例如： Cookie、HTTP 認(rèn)證或者 TLS 認(rèn)證。

連接保密性是基于運(yùn)行 TLS 的 WebSocket 協(xié)議（wss 的 URLs）。WebSocket 協(xié)議實(shí)現(xiàn)必須支持 TLS，并且應(yīng)該在與對(duì)端進(jìn)行數(shù)據(jù)傳輸時(shí)使用它。

如果在連接中使用 TLS，TLS帶來的連接的收益非常依賴于 TLS 握手時(shí)的算法的強(qiáng)度。例如，一些 TLS 的加密算法不提供連接保密性。為了實(shí)現(xiàn)合理登記的保護(hù)措施，客戶端應(yīng)該只使用強(qiáng) TLS 算法。“Web 安全：用戶接口指南”（W3C.REC-wsc-ui-20100812）討論了什么是強(qiáng) TLS 算法。RFC5246 的附錄 A.5和附錄 D.3提供了另外的指導(dǎo)。

傳入的數(shù)據(jù)必須經(jīng)過客戶端和服務(wù)端的認(rèn)證。如果，在某個(gè)時(shí)候，一個(gè)終端面對(duì)它無法理解的數(shù)據(jù)或者違反了這個(gè)終端定義的輸入安全規(guī)范和標(biāo)準(zhǔn)，或者這個(gè)終端在開始握手時(shí)沒有收到對(duì)應(yīng)的預(yù)期值時(shí)（在客戶端請(qǐng)求中不正確的路徑或者源），終端應(yīng)該關(guān)閉 TCP 連接。如果在成功的握手后收到了無效的數(shù)據(jù)，終端應(yīng)該在進(jìn)入關(guān)閉 WebSocket流程前，發(fā)送一個(gè)帶有合適的狀態(tài)碼（第 7.4 節(jié)）的關(guān)閉幀。使用一個(gè)合適的狀態(tài)碼的關(guān)閉幀有助于診斷這個(gè)問題。如果這個(gè)無效的數(shù)據(jù)是在 WebSocket 握手時(shí)收到的，服務(wù)端應(yīng)該響應(yīng)一個(gè)合適的 HTTP 狀態(tài)碼（RFC2616）。

使用錯(cuò)誤的編碼來發(fā)送數(shù)據(jù)是一類通用的安全問題。這個(gè)協(xié)議指定文本類型數(shù)據(jù)（而不是二進(jìn)制或者其他類型）的消息使用 UTF-8 編碼。雖然仍然可以得到長(zhǎng)度值，但實(shí)現(xiàn)此協(xié)議的應(yīng)用程序應(yīng)使用這個(gè)長(zhǎng)度來確定幀實(shí)際結(jié)束的位置，發(fā)送不合理的編碼數(shù)據(jù)仍然會(huì)導(dǎo)致基于此協(xié)議構(gòu)建的應(yīng)用程序可能會(huì)導(dǎo)致從數(shù)據(jù)的錯(cuò)誤解釋到數(shù)據(jù)丟失或潛在的安全漏洞出現(xiàn)。

在這個(gè)文檔中描述的 WebSocket 握手協(xié)議是不依賴任意 SHA-1 的安全屬性，流入抗沖擊性和對(duì)第二次前映像攻擊的抵抗力（就像 RFC4270 描述的一樣）。