WebSocket應用安全問題分析

1. WebSocket特性介紹

WebSocket是HTML5開始提供的一種瀏覽器與服務器間進行全雙工通訊的網絡技術。WebSocket通信協議于2011年被IETF定為標準RFC 6455，WebSocket API也被W3C定為標準，主流的瀏覽器都已經支持WebSocket通信。

WebSocket協議是基于TCP協議上的獨立的通信協議，在建立WebSocket通信連接前，需要使用HTTP協議進行握手，從HTTP連接升級為WebSocket連接。瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接，并進行雙向數據傳輸。

WebSocket定義了兩種URI格式, “ws://“和“wss://”，類似于HTTP和HTTPS, “ws://“使用明文傳輸，默認端口為80，”wss://“使用TLS加密傳輸，默認端口為443。

	
	

		 ws-URI : "ws://host[:port]path[?query]"
	

	

		 wss-URI : "wss://host[:port]path[?query]"
	

WebSocket 握手階段，需要用到一些HTTP頭，升級HTTP連接為WebSocket連接如下表所示。

一次完整的握手連接如下圖:

一旦服務器端返回 101 響應，即可完成 WebSocket 協議切換。服務器端可以基于相同端口，將通信協議從 http://或 https:// 切換到 ws://或 wss://。協議切換完成后，瀏覽器和服務器端可以使用 WebSocket API 互相發送和收取文本和二進制消息。

2. WebSocket應用安全問題

WebSocket作為一種通信協議引入到Web應用中，并不會解決Web應用中存在的安全問題，因此WebSocket應用的安全實現是由開發者或服務端負責。這就要求開發者了解WebSocket應用潛在的安全風險，以及如何做到安全開發規避這些安全問題。

2.1 認證

WebSocket 協議沒有規定服務器在握手階段應該如何認證客戶端身份。服務器可以采用任何 HTTP 服務器的客戶端身份認證機制，如 cookie認證，HTTP 基礎認證，TLS 身份認證等。在WebSocket應用認證實現上面臨的安全問題和傳統的Web應用認證是相同的，如：CVE-2015-0201, Spring框架的Java SockJS客戶端生成可預測的會話ID，攻擊者可利用該漏洞向其他會話發送消息; CVE-2015-1482, Ansible Tower未對用戶身份進行認證，遠程攻擊者通過websocket連接獲取敏感信息。

2.2 授權

同認證一樣，WebSocket協議沒有指定任何授權方式，應用程序中用戶資源訪問等的授權策略由服務端或開發者實現。WebSocket應用也會存在和傳統Web應用相同的安全風險，如：垂直權限提升和水平權限提升。

2.3 跨域請求

WebSocket使用基于源的安全模型，在發起WebSocket握手請求時，瀏覽器會在請求中添加一個名為Origin的HTTP頭，Oringin字段表示發起請求的源，以此來防止未經授權的跨站點訪問請求。WebSocket 的客戶端不僅僅局限于瀏覽器，因此 WebSocket 規范沒有強制規定握手階段的 Origin 頭是必需的，并且WebSocket不受瀏覽器同源策略的限制。如果服務端沒有針對Origin頭部進行驗證可能會導致跨站點WebSocket劫持攻擊。該漏洞最早在 2013 年被Christian Schneider 發現并公開，Christian 將之命名為跨站點 WebSocket 劫持 (Cross Site WebSocket Hijacking)(CSWSH)。跨站點 WebSocket 劫持危害大，但容易被開發人員忽視。相關案例可以參考: IPython Notebook(CVE-2014-3429), OpenStack Compute(CVE-2015-0259), Zeppelin WebSocket服務器等跨站WebSocket劫持。

上圖展示了跨站WebSocket劫持的過程，某個用戶已經登錄了WebSocket應用程序，如果他被誘騙訪問了某個惡意網頁，而惡意網頁中植入了一段js代碼，自動發起 WebSocket 握手請求跟目標應用建立 WebSocket 連接。注意到，Origin 和 Sec-WebSocket-Key 都是由瀏覽器自動生成的，瀏覽器再次發起請求訪問目標服務器會自動帶上cookie 等身份認證參數。如果服務器端沒有檢查 Origin頭，則該請求會成功握手切換到 WebSocket 協議，惡意網頁就可以成功繞過身份認證連接到 WebSocket 服務器，進而竊取到服務器端發來的信息，或者發送偽造信息到服務器端篡改服務器端數據。與傳統跨站請求偽造(CSRF)攻擊相比，CSRF 主要是通過惡意網頁悄悄發起數據修改請求，而跨站 WebSocket 偽造攻擊不僅可以修改服務器數據，還可以控制整個雙向通信通道。也正是因為這個原因，Christian 將這個漏洞命名為劫持(Hijacking)，而不是請求偽造(Request Forgery)。

理解了跨站WebSocket劫持攻擊的原理和過程，那么如何防范這種攻擊呢？處理也比較簡單，在服務器端的代碼中增加 對Origin頭的檢查，如果客戶端發來的 Origin 信息來自不同域，服務器端可以拒絕該請求。但是僅僅檢查 Origin 仍然是不夠安全的，惡意網頁可以偽造Origin頭信息，繞過服務端對Origin頭的檢查，更完善的解決方案可以借鑒CSRF的解決方案-令牌機制。

2.4 拒絕服務

WebSocket設計為面向連接的協議，可被利用引起客戶端和服務器端拒絕服務攻擊，相關案例可參考: F5 BIG-IP遠程拒絕服務漏洞(CVE-2016-9253)。

(1). 客戶端拒絕服務

WebSocket連接限制不同于HTTP連接限制，和HTTP相比，WebSocket有一個更高的連接限制，不同的瀏覽器有自己特定的最大連接數,如：火狐瀏覽器默認最大連接數為200。通過發送惡意內容，用盡允許的所有Websocket連接耗盡瀏覽器資源，引起拒絕服務。

(2). 服務器端拒絕服務

WebSocket建立的是持久連接，只有客戶端或服務端其中一發提出關閉連接的請求，WebSocket連接才關閉，因此攻擊者可以向服務器發起大量的申請建立WebSocket連接的請求，建立持久連接，耗盡服務器資源，引發拒絕服務。針對這種攻，可以通過設置單IP可建立連接的最大連接數的方式防范。攻擊者還可以通過發送一個單一的龐大的數據幀(如, 2^16)，或者發送一個長流的分片消息的小幀，來耗盡服務器的內存，引發拒絕服務攻擊, 針對這種攻擊，通過限制幀大小和多個幀重組后的總消息大小的方式防范。

2.5 中間人攻擊

WebSocket使用HTTP或HTTPS協議進行握手請求，在使用HTTP協議的情況下，若存在中間人可以嗅探HTTP流量，那么中間人可以獲取并篡改WebSocket握手請求，通過偽造客戶端信息與服務器建立WebSocket連接，如下圖所示。防范這種攻擊，需要在加密信道上建立WebSocket連接，使用HTTPS協議發起握手請求。

2.6 輸入校驗

WebSocket應用和傳統Web應用一樣，都需要對輸入進行校驗，來防范來客戶端的XSS攻擊，服務端的SQL注入，代碼注入等攻擊。

3. 總結

Websocket是一個基于TCP的HTML5的新協議，可以實現瀏覽器和服務器之間的全雙工通訊。在即時通訊等應用中，WebSocket具有很大的性能優勢, 并且非常適合全雙工通信，但是，和任何其他技術一樣，開發WebSocket應用也需要考慮潛在的安全風險。

4. 參考

• BH_US_12_Shekyan_Toukharian_Hacking_Websocket
• http://blog.stratumsecurity.com/2016/06/13/websockets-auth/
• http://resources.infosecinstitute.com/websocket-security-issues/#gref
• http://blog.ironwasp.org/2014/11/analysing-testing-and-fuzzing-websocket.html
• https://www.ibm.com/developerworks/cn/java/j-lo-websocket-cross-site/index.html
• http://www.cnblogs.com/r00tgrok/p/3848789.html
• http://lambdaops.com/cross-origin-websocket-hijacking-of-ipython/
• https://github.com/zhangkaitao/websocket-protocol/wiki/10.%E5%AE%89%E5%85%A8%E6%B3%A8%E6%84%8F%E4%BA%8B%E9%A1%B9