【譯】 WebSocket 協(xié)議第十章——安全性考慮（Security Considerations

darkerXi 發(fā)布于2019-08-23 15:20 / 1697人閱讀

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

概述

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

10 安全性考慮（協(xié)議正文）

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

10.1 非瀏覽器客戶端

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

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

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

10.2 源考慮

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

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

10.3 基礎(chǔ)設(shè)施攻擊（添加掩碼）

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

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

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

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

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

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

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

10.4 指定實現(xiàn)的限制

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

10.5 WebSocket 客戶端認(rèn)證

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

10.6 連接保密性和完整性

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

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

10.7 處理無用數(shù)據(jù)

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

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

10.8 在 WebSocket 握手中使用 SHA-1

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