曾德愚

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

關(guān)鍵詞：WebSocket 漏洞 修復(fù)

中圖分類號：TP309 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9416（2016）09-0198-01

1 序言

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

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

2 漏洞原理

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

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

3 漏洞檢測

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

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

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

4 漏洞修復(fù)

跨站W(wǎng)ebSocket劫持漏洞危害較大，它既可以修改服務(wù)器數(shù)據(jù)，還可以控制讀取及修改雙向通道，比通過惡意網(wǎng)頁發(fā)起數(shù)據(jù)修改請求，但不會導(dǎo)致信息泄漏的跨站請求偽造攻擊CSRF危害更大。

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

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

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

參考文獻(xiàn)

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