自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

WebSocket通信協(xié)議應(yīng)用安全問(wèn)題分析

開(kāi)發(fā) 前端
WebSocket是HTML5開(kāi)始提供的一種瀏覽器與服務(wù)器間進(jìn)行全雙工通訊的網(wǎng)絡(luò)技術(shù)。WebSocket通信協(xié)議于2011年被IETF定為標(biāo)準(zhǔn)RFC 6455,WebSocket API也被W3C定為標(biāo)準(zhǔn),主流的瀏覽器都已經(jīng)支持WebSocket通信。

WebSocket是HTML5開(kāi)始提供的一種瀏覽器與服務(wù)器間進(jìn)行全雙工通訊的網(wǎng)絡(luò)技術(shù)。WebSocket通信協(xié)議于2011年被IETF定為標(biāo)準(zhǔn)RFC 6455,WebSocket API也被W3C定為標(biāo)準(zhǔn),主流的瀏覽器都已經(jīng)支持WebSocket通信。

WebSocket協(xié)議是基于TCP協(xié)議上的獨(dú)立的通信協(xié)議,在建立WebSocket通信連接前,需要使用HTTP協(xié)議進(jìn)行握手,從HTTP連接升級(jí)為WebSocket連接。瀏覽器和服務(wù)器只需要完成一次握手,兩者之間就直接可以創(chuàng)建持久性的連接,并進(jìn)行雙向數(shù)據(jù)傳輸。

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

 

  1. ws-URI: "ws://host[:port]path[?query]"  
  2. wss-URI: "wss://host[:port]path[?query]" 

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

 

WebSocket應(yīng)用安全問(wèn)題分析

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

WebSocket應(yīng)用安全問(wèn)題分析

一旦服務(wù)器端返回 101 響應(yīng),即可完成 WebSocket 協(xié)議切換。服務(wù)器端可以基于相同端口,將通信協(xié)議從 http://或 https:// 切換到 ws://或 wss://。協(xié)議切換完成后,瀏覽器和服務(wù)器端可以使用 WebSocket API 互相發(fā)送和收取文本和二進(jìn)制消息。

WebSocket應(yīng)用安全問(wèn)題

WebSocket作為一種通信協(xié)議引入到Web應(yīng)用中,并不會(huì)解決Web應(yīng)用中存在的安全問(wèn)題,因此WebSocket應(yīng)用的安全實(shí)現(xiàn)是由開(kāi)發(fā)者或服務(wù)端負(fù)責(zé)。這就要求開(kāi)發(fā)者了解WebSocket應(yīng)用潛在的安全風(fēng)險(xiǎn),以及如何做到安全開(kāi)發(fā)規(guī)避這些安全問(wèn)題。

認(rèn)證

WebSocket 協(xié)議沒(méi)有規(guī)定服務(wù)器在握手階段應(yīng)該如何認(rèn)證客戶端身份。服務(wù)器可以采用任何 HTTP 服務(wù)器的客戶端身份認(rèn)證機(jī)制,如 cookie認(rèn)證,HTTP 基礎(chǔ)認(rèn)證,TLS 身份認(rèn)證等。在WebSocket應(yīng)用認(rèn)證實(shí)現(xiàn)上面臨的安全問(wèn)題和傳統(tǒng)的Web應(yīng)用認(rèn)證是相同的,如: CVE-2015-0201 , Spring框架的Java SockJS客戶端生成可預(yù)測(cè)的會(huì)話ID,攻擊者可利用該漏洞向其他會(huì)話發(fā)送消息; CVE-2015-1482 , Ansible Tower未對(duì)用戶身份進(jìn)行認(rèn)證,遠(yuǎn)程攻擊者通過(guò)websocket連接獲取敏感信息。

授權(quán)

同認(rèn)證一樣,WebSocket協(xié)議沒(méi)有指定任何授權(quán)方式,應(yīng)用程序中用戶資源訪問(wèn)等的授權(quán)策略由服務(wù)端或開(kāi)發(fā)者實(shí)現(xiàn)。WebSocket應(yīng)用也會(huì)存在和傳統(tǒng)Web應(yīng)用相同的安全風(fēng)險(xiǎn),如:垂直權(quán)限提升和水平權(quán)限提升。

跨域請(qǐng)求

WebSocket使用基于源的安全模型,在發(fā)起WebSocket握手請(qǐng)求時(shí),瀏覽器會(huì)在請(qǐng)求中添加一個(gè)名為Origin的HTTP頭,Oringin字段表示發(fā)起請(qǐng)求的源,以此來(lái)防止未經(jīng)授權(quán)的跨站點(diǎn)訪問(wèn)請(qǐng)求。WebSocket 的客戶端不僅僅局限于瀏覽器,因此 WebSocket 規(guī)范沒(méi)有強(qiáng)制規(guī)定握手階段的 Origin 頭是必需的,并且WebSocket不受瀏覽器同源策略的限制。如果服務(wù)端沒(méi)有針對(duì)Origin頭部進(jìn)行驗(yàn)證可能會(huì)導(dǎo)致跨站點(diǎn)WebSocket劫持攻擊。該漏洞最早在 2013 年被Christian Schneider 發(fā)現(xiàn)并公開(kāi),Christian 將之命名為跨站點(diǎn) WebSocket 劫持 (Cross Site WebSocket Hijacking)(CSWSH)??缯军c(diǎn) WebSocket 劫持危害大,但容易被開(kāi)發(fā)人員忽視。相關(guān)案例可以參考: IPython Notebook( CVE-2014-3429 ), OpenStack Compute( CVE-2015-0259 ), Zeppelin WebSocket服務(wù)器 等跨站W(wǎng)ebSocket劫持。

WebSocket應(yīng)用安全問(wèn)題分析

上圖展示了跨站W(wǎng)ebSocket劫持的過(guò)程,某個(gè)用戶已經(jīng)登錄了WebSocket應(yīng)用程序,如果他被誘騙訪問(wèn)了某個(gè)惡意網(wǎng)頁(yè),而惡意網(wǎng)頁(yè)中植入了一段js代碼,自動(dòng)發(fā)起 WebSocket 握手請(qǐng)求跟目標(biāo)應(yīng)用建立 WebSocket 連接。注意到,Origin 和 Sec-WebSocket-Key 都是由瀏覽器自動(dòng)生成的,瀏覽器再次發(fā)起請(qǐng)求訪問(wèn)目標(biāo)服務(wù)器會(huì)自動(dòng)帶上Cookie 等身份認(rèn)證參數(shù)。如果服務(wù)器端沒(méi)有檢查 Origin頭,則該請(qǐng)求會(huì)成功握手切換到 WebSocket 協(xié)議,惡意網(wǎng)頁(yè)就可以成功繞過(guò)身份認(rèn)證連接到 WebSocket 服務(wù)器,進(jìn)而竊取到服務(wù)器端發(fā)來(lái)的信息,或者發(fā)送偽造信息到服務(wù)器端篡改服務(wù)器端數(shù)據(jù)。與傳統(tǒng)跨站請(qǐng)求偽造(CSRF)攻擊相比,CSRF 主要是通過(guò)惡意網(wǎng)頁(yè)悄悄發(fā)起數(shù)據(jù)修改請(qǐng)求,而跨站 WebSocket 偽造攻擊不僅可以修改服務(wù)器數(shù)據(jù),還可以控制整個(gè)雙向通信通道。也正是因?yàn)檫@個(gè)原因,Christian 將這個(gè)漏洞命名為劫持(Hijacking),而不是請(qǐng)求偽造(Request Forgery)。

理解了跨站W(wǎng)ebSocket劫持攻擊的原理和過(guò)程,那么如何防范這種攻擊呢?處理也比較簡(jiǎn)單,在服務(wù)器端的代碼中增加 對(duì)Origin頭的檢查,如果客戶端發(fā)來(lái)的 Origin 信息來(lái)自不同域,服務(wù)器端可以拒絕該請(qǐng)求。但是僅僅檢查 Origin 仍然是不夠安全的,惡意網(wǎng)頁(yè)可以偽造Origin頭信息,繞過(guò)服務(wù)端對(duì)Origin頭的檢查,更完善的解決方案可以借鑒CSRF的解決方案-令牌機(jī)制。

拒絕服務(wù)

WebSocket設(shè)計(jì)為面向連接的協(xié)議,可被利用引起客戶端和服務(wù)器端拒絕服務(wù)攻擊,相關(guān)案例可參考: F5 BIG-IP遠(yuǎn)程拒絕服務(wù)漏洞( CVE-2016-9253 )。

1. 客戶端拒絕服務(wù)

WebSocket連接限制不同于HTTP連接限制,和HTTP相比,WebSocket有一個(gè)更高的連接限制,不同的瀏覽器有自己特定的最大連接數(shù),如:火狐瀏覽器默認(rèn)最大連接數(shù)為200。通過(guò)發(fā)送惡意內(nèi)容,用盡允許的所有Websocket連接耗盡瀏覽器資源,引起拒絕服務(wù)。

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

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

中間人攻擊

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

WebSocket應(yīng)用安全問(wèn)題分析

輸入校驗(yàn)

WebSocket應(yīng)用和傳統(tǒng)Web應(yīng)用一樣,都需要對(duì)輸入進(jìn)行校驗(yàn),來(lái)防范來(lái)客戶端的XSS攻擊,服務(wù)端的SQL注入,代碼注入等攻擊。

總結(jié)

Websocket是一個(gè)基于TCP的HTML5的新協(xié)議,可以實(shí)現(xiàn)瀏覽器和服務(wù)器之間的全雙工通訊。在即時(shí)通訊等應(yīng)用中,WebSocket具有很大的性能優(yōu)勢(shì), 并且非常適合全雙工通信,但是,和任何其他技術(shù)一樣,開(kāi)發(fā)WebSocket應(yīng)用也需要考慮潛在的安全風(fēng)險(xiǎn)。

責(zé)任編輯:未麗燕 來(lái)源: 騰訊安全響應(yīng)中心
相關(guān)推薦

2010-06-11 14:31:08

通信協(xié)議

2023-10-12 19:37:50

通信協(xié)議HTTP

2010-06-28 15:52:17

2023-06-28 07:16:11

2022-12-02 14:42:37

2015-10-16 10:10:18

應(yīng)用層通信協(xié)議

2010-07-06 17:14:03

網(wǎng)關(guān)通信協(xié)議

2019-05-27 06:05:20

物聯(lián)網(wǎng)協(xié)議物聯(lián)網(wǎng)IOT

2010-06-11 14:25:08

通信協(xié)議

2010-06-25 14:43:46

通信協(xié)議

2019-09-26 05:30:03

物聯(lián)網(wǎng)通信協(xié)議IOT

2010-07-06 16:34:47

NetBIOS協(xié)議

2010-06-09 10:43:54

廣義網(wǎng)協(xié)議

2019-08-23 12:49:18

USB通信協(xié)議

2019-04-29 10:26:49

TCP網(wǎng)絡(luò)協(xié)議網(wǎng)絡(luò)通信

2009-12-22 09:37:47

網(wǎng)關(guān)設(shè)置通信協(xié)議

2024-02-20 19:53:57

網(wǎng)絡(luò)通信協(xié)議

2022-07-07 09:00:00

區(qū)塊鏈加密貨幣安全

2012-12-18 13:56:55

2019-09-02 15:01:18

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)