資訊專欄INFORMATION COLUMN
摘要：概述本文為協議的第九章，本文翻譯的主要內容為安全性相關內容。安全性考慮協議正文這一章描述了一些協議的可用的安全性考慮。連接保密性和完整性連接保密性是基于運行的協議的。使用一個合適的狀態碼的關閉幀有助于診斷這個問題。
概述
本文為 WebSocket 協議的第九章，本文翻譯的主要內容為 WebSocket 安全性相關內容。
10 安全性考慮（協議正文）這一章描述了一些 WebSocket 協議的可用的安全性考慮。這一章的小節描述了這些特定的安全性考慮。
10.1 非瀏覽器客戶端WebSocket 協議防止在受信任的應用例如 Web 瀏覽器中執行的惡意 JavaScript 代碼，例如通過檢查Origin頭字段（見下面）。見第 1.6 節去了解更多詳情。這種假設在更有能力的客戶端的情況下不成立。
這個協議可以被網頁中的腳本使用，也可以通過宿主直接使用。這些宿主是代表自己的利益的，因此可以發送假的Origin頭字段來欺騙服務端。因此服務端對于他們正在和已知的源的腳本直接通信的假設需要消息，并且必須認為他們可能通過沒有預期的方式訪問。特別地，服務端不應該相信任何輸入都是有效的。
示例：如果服務端使用輸入的內容作為一部分的 SQL 查詢語句，所有的輸入文本都必須在傳遞給 SQL 服務器時進行編碼，以免服務端受到 SQL 注入攻擊。
10.2 源考慮只處理特定站點，不打算處理任何 Web 頁面的數據服務器應該驗證Origin字段是否是他們預期的。如果服務端收到的源字段是不接受的，那么他應該通過包含 HTTP 禁止狀態碼為 403 的請求響應作為 WebSocket 握手的響應。
當不信任的一方是 JavaScript 應用作者并存在受信任的客戶端中運行時，Origin字段可以避免出現這種攻擊的情況。客戶端可以連接到服務端，通過協議中的Origin字段，確定是否開放連接的權限給 JavaScript 應用。這么做的目的不是組織非瀏覽器應用建立連接，而是保證在受信任的瀏覽器中可能運行的惡意 JavaScript 代碼并不會構建一個假的 WebSocket 握手。
10.3 基礎設施攻擊（添加掩碼）除了終端可能會成為通過 WebSocket 被攻擊的目標之外，網絡基礎設施的另外一部分，例如代理，也有可能是攻擊的對象。
這個協議發展后，通過一個實驗驗證了部署在外部的緩存服務器由于一系列在代理上面的攻擊導致投毒。一般形式的攻擊就是在攻擊者控制下建立一個與服務端的連接，實現一個與 WebSocket 協議建立連接相似的 HTTP UPGRADE 連接，然后通過升級以后的連接發送數據，看起來就像是針對已知的特定資源（在攻擊中，這可能類似于廣泛部署的腳本，用于跟蹤廣告服務網絡上的點擊或資源）進行 GET 請求。遠端服務器可能會通過一些看上去像響應數據的來響應假的 GET 請求，然后這個響應就會按照非零百分比的已部署中介緩存，因此導致緩存投毒。這個攻擊帶來的影響就是，如果一個用戶可以正常的訪問一個攻擊者控制的網網站，那么攻擊者可以針對這個用戶進行緩存投毒，在相同緩存的后面其他用戶會運行其他源的惡意腳本，破壞 Web 安全模型。
為了避免對中介服務的此類攻擊，使用不符合 HTTP 的數據幀中為應用程序的數據添加前綴是不夠的，我們不可能詳細的檢查和測試每一個不合標準的中介服務有沒有跳過這種非 HTTP 幀，或者對幀載荷處理不正確的情況。因此，采用的防御措施是對客戶端發送給服務端的所有數據添加掩碼，這樣的話遠端的腳本（攻擊者）就不能夠控制發送的數據如何出現在線路上，因此就不能夠構造一條被中介誤解的 HTPT請求。
客戶端必須為每一幀選擇一個新的掩碼值，使用一個不能夠被應用預測到的算法來進行傳遞數據。例如，每一個掩碼值可以通過一個加密強隨機數生成器來生成。如果相同的值已經被使用過或者已經存在一種方式能夠判斷出下一個值如何選擇時，攻擊這個可以發送一個添加了掩碼的消息，來模擬一個 HTTP 請求（通過在線路上接收攻擊者希望看到的消息，使用下一個被使用的掩碼值來對數據進行添加掩碼，當客戶端使用它時，這個掩碼值可以有效地反掩碼數據）。
當從客戶端開始傳遞第一幀時，這個幀的有效載荷（應用程序提供的數據）就不能夠被客戶端應用程序修改，這個策略是很重要的。否則，攻擊者可以發送一個都是已知值（例如全部為 0）的初始值的很長的幀，計算收到第一部分數據時使用過的掩碼，然后修改幀中尚未發送的數據，以便在添加掩碼時顯示為 HTTP 請求。（這與我們在之前的段落中描述的使用已知的值和可預測的值作為掩碼值，實際上是相同的問題。）如果另外的數據已經發送了，或者要發送的數據有所改變，那么新的數據或者修改的數據必須使用一個新的數據幀進行發送，因此也需要選擇一個新的掩碼值。簡短來說，一旦一個幀的傳輸開始后，內容不能夠被遠端的腳本（應用）修改。
受保護的威脅模型是客戶端發送看似HTTP請求的數據的模型。因此，從客戶端發送給服務端的頻道數據需要添加掩碼值。從服務端到客戶端的數據看上去像是一個請求的響應，但是，為了完成一次請求，客戶端也需要可以偽造請求。因此，我們不認為需要在雙向傳輸上添加掩碼。（服務端發送給客戶端的數據不需要添加掩碼）
盡管通過添加掩碼提供了保護，但是不兼容的 HTTP 代理仍然由于客戶端和服務端之間不支持添加掩碼而受到這種類型的攻擊。
10.4 指定實現的限制在從多個幀重新組裝后，對于幀大小或總消息大小具有實現和必須避免自己超過相關的多平臺特定限制帶來的影響。（例如：一個惡意的終端可能會嘗試耗盡對端的內存或者通過發送一個大的幀（例如：大小為 2 ** 60）或發送一個長的由許多分片幀構成的流來進行拒絕服務攻擊）。這些實現應該對幀的大小和組裝過后的包的總大小有一定的限制。
10.5 WebSocket 客戶端認證這個協議在 WebSocket 握手時，沒有規定服務端可以使用哪種方式進行認證。WebSocket 服務器可以使用任意 HTTP 服務器通用的認證機制，例如： Cookie、HTTP 認證或者 TLS 認證。
10.6 連接保密性和完整性連接保密性是基于運行 TLS 的 WebSocket 協議（wss 的 URLs）。WebSocket 協議實現必須支持 TLS，并且應該在與對端進行數據傳輸時使用它。
如果在連接中使用 TLS，TLS帶來的連接的收益非常依賴于 TLS 握手時的算法的強度。例如，一些 TLS 的加密算法不提供連接保密性。為了實現合理登記的保護措施，客戶端應該只使用強 TLS 算法。“Web 安全：用戶接口指南”（W3C.REC-wsc-ui-20100812）討論了什么是強 TLS 算法。RFC5246 的附錄 A.5和附錄 D.3提供了另外的指導。
10.7 處理無用數據傳入的數據必須經過客戶端和服務端的認證。如果，在某個時候，一個終端面對它無法理解的數據或者違反了這個終端定義的輸入安全規范和標準，或者這個終端在開始握手時沒有收到對應的預期值時（在客戶端請求中不正確的路徑或者源），終端應該關閉 TCP 連接。如果在成功的握手后收到了無效的數據，終端應該在進入關閉 WebSocket流程前，發送一個帶有合適的狀態碼（第 7.4 節）的關閉幀。使用一個合適的狀態碼的關閉幀有助于診斷這個問題。如果這個無效的數據是在 WebSocket 握手時收到的，服務端應該響應一個合適的 HTTP 狀態碼（RFC2616）。
使用錯誤的編碼來發送數據是一類通用的安全問題。這個協議指定文本類型數據（而不是二進制或者其他類型）的消息使用 UTF-8 編碼。雖然仍然可以得到長度值，但實現此協議的應用程序應使用這個長度來確定幀實際結束的位置，發送不合理的編碼數據仍然會導致基于此協議構建的應用程序可能會導致從數據的錯誤解釋到數據丟失或潛在的安全漏洞出現。
10.8 在 WebSocket 握手中使用 SHA-1在這個文檔中描述的 WebSocket 握手協議是不依賴任意 SHA-1 的安全屬性，流入抗沖擊性和對第二次前映像攻擊的抵抗力（就像 RFC4270 描述的一樣）。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/101851.html
摘要：概述本文為協議的第九章，本文翻譯的主要內容為安全性相關內容。安全性考慮協議正文這一章描述了一些協議的可用的安全性考慮。連接保密性和完整性連接保密性是基于運行的協議的。使用一個合適的狀態碼的關閉幀有助于診斷這個問題。 概述 本文為 WebSocket 協議的第九章，本文翻譯的主要內容為 WebSocket 安全性相關內容。 10 安全性考慮（協議正文） 這一章描述了一些 WebSocke...
摘要：概述經過半年的搗鼓，終于將協議全篇翻譯完成。現在將所有章節全部整理到一篇文章中，方便大家閱讀。如果大家想看具體的翻譯文檔，可以去我的中查看。大家有相關類型的需要，建議大家可以嘗試下。 概述 經過半年的搗鼓，終于將 WebSocket 協議（RFC6455）全篇翻譯完成。現在將所有章節全部整理到一篇文章中，方便大家閱讀。如果大家想看具體的翻譯文檔，可以去我的GitHub中查看。 具體章節...
摘要：概述本文為協議的第十二章，本文翻譯的主要內容為如何使用其他規范中的協議。使用其他規范中的協議協議正文協議旨在由另一規范使用，以提供動態作者定義內容的通用機制。當連接打開時，文檔需要處理收到一條消息第節的場景。 概述 本文為 WebSocket 協議的第十二章，本文翻譯的主要內容為如何使用其他規范中的 WebSocket 協議。 使用其他規范中的WebSocket協議（協議正文） Web...
摘要：概述本文為協議的第六章，本文翻譯的主要內容為消息發送與接收相關內容。在這一幀中的應用數據被定義為消息的數據。接下來的數據幀必須是屬于一條新的消息。像第節中說的那樣，服務端在收到客戶端的數據幀時必須去除掩碼。 概述 本文為 WebSocket 協議的第六章，本文翻譯的主要內容為 WebSocket 消息發送與接收相關內容。 發送與接收消息（協議正文） 6.1 發送數據 為了通過 WebS...
摘要：概述本文為協議的第十一章，本文翻譯的主要內容為的相關注意事項。應用協議使用這個協議規范互操作性注意事項使用時需要使用或者更高版本的協議。安全性注意事項見安全性注意事項一節。 概述 本文為 WebSocket 協議的第十一章，本文翻譯的主要內容為 WebSocket 的 IANA 相關注意事項。 IANA 注意事項（協議正文） 11.1 注冊新 URI 協議 11.1.1 注冊 ws 協...
閱讀 2045·2021-11-08 13:22
閱讀 2506·2021-09-04 16:40
閱讀 1150·2021-09-03 10:29
閱讀 1715·2019-08-30 15:44
閱讀 2124·2019-08-30 11:13
閱讀 2791·2019-08-29 17:07
閱讀 1967·2019-08-29 14:22
閱讀 1247·2019-08-26 14:00
