WebSocket安全漏洞及其修復

曾德愚

摘要： WebSocket使瀏覽器提供對Socket的支持，在客戶端和服務器之間提供基于單TCP連接的雙向通道，常用于實時性要求較高的場合，例如證券行情、在線互動游戲及設備同步等方面。但由于架構設計原因，WebSocket也存在不少安全問題，有些漏洞將導致極大的破壞，本文就危害較大的跨站WebSocket劫持漏洞進行原理分析，提出檢測及修復方法。

關鍵詞：WebSocket 漏洞 修復

中圖分類號：TP309 文獻標識碼：A 文章編號：1007-9416（2016）09-0198-01

1 序言

在WebSocket高效解決信息實時同步問題之前，一般采用輪詢Polling和 Comet技術，不光造成設計復雜，同時帶來系統額外負載。WebSocket較好地解決了此類問題。雖然WebSocket協議在最初設計的時候就充分考慮了安全保障，但任何軟件產品都不可能十全十美，隨著其被廣泛使用，諸如Wireshark漏洞、Asterisk WebSocket Server DoS漏洞、特別是OpenStack Nova console WebSocket漏洞等安全問題出現，引起了業界對危害較大的跨站WebSocket劫持漏洞的關注。

WebSocket是持久化協議，提供全雙工連接，基于TCP實現消息流，基于HTTP協議進行握手協議連接。在瀏覽器向服務器端申請切換到WebSocket協議之后，如果服務器端返回101響應，則服務器端基于相同端口完成協議切換，瀏覽器和服務器端之間可使用WebSocket API傳輸文本和二進制消息。

2 漏洞原理

在創建全雙工通信的過程中，客戶端基于HTTP握手切換到WebSocket協議，在握手Get請求中，Cookie頭部把域名下的Cookie全部發送到服務器端，由于WebSocket協議沒有規定服務器在握手階段認證客戶端身份的手段，所以服務器可采用任何身份認證機制，因此給黑客偽造握手請求繞過身份認證提供了極大可能，從而實現跨站請求偽造攻擊。

例如，某用戶被引導訪問到在某元素中植入了WebSocket握手請求申請跟目標應用建立WebSocket連接的惡意網頁，則自動發起連接請求，如果服務器端沒有增加Origin檢查機制，則該請求將切換到WebSocket協議，惡意網頁不通過身份認證即連接至WebSocket服務器，實現竊取或修改服務器端信息。

3 漏洞檢測

可以通過重發WebSocket協議轉換請求來檢測服務器端是否存在相關漏洞，原理在于使用能攔截WebSocket握手請求的軟件，首先修改請求中的Origin頭信息，然后重新發送請求，如果服務器返回101響應，則說明服務器端沒有執行相關檢查，如果沒有返回101響應，則說明服務器端拒絕來自不同源的連接請求，則可認為是安全的。

本文采用開源OWASP ZAP軟件攔截WebSocket握手請求及WebSocket消息通信，修改Origin后重發請求，如果連接成功后，則重發WebSocket客戶端消息確認漏洞。

具體過程為在瀏覽器中配置ZAP代理后訪問WebSocket應用，請求頭部如有HTTP Basic Authorization信息則表示登錄成功；重發WebSocket協議升級請求，將Origin修改為任意網址并發送；在響應標簽中如服務器端返回101信息則說明協議握手成功；再重發WebSocket消息進一步確認漏洞，如ZAP收到兩條服務器返回消息則可確定應用站點存在跨站WebSocket劫持漏洞。

4 漏洞修復

跨站WebSocket劫持漏洞危害較大，它既可以修改服務器數據，還可以控制讀取及修改雙向通道，比通過惡意網頁發起數據修改請求，但不會導致信息泄漏的跨站請求偽造攻擊CSRF危害更大。

本文提出在服務器端代碼中增加Origin檢查機制修復漏洞，如果瀏覽器發送的Origin信息來源不同，則服務器端拒絕請求并發回拒絕連接403錯誤。

可以使用Java EE提供的允許開發人員重寫配置用來攔截檢查協議握手過程的配置器，繼承并重寫checkOrigin方法，參考代碼如下。

單純的Origin檢查不夠全面，如果WebSocket客戶端是非瀏覽器，則客戶端請求無Origin，在此情形下可以借鑒CSRF的令牌機制進一步增強安全性，因篇幅原因，本文不予深入討論。

參考文獻

[1]何健.深入理解跨站點WebSocket劫持漏洞的原理及防范.2016（05）：10.