WebSockets安全漏洞的示例分析

這篇文章主要為大家展示了“WebSockets安全漏洞的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“WebSockets安全漏洞的示例分析”這篇文章吧。

1. WebSockets

WebSockets廣泛用于現(xiàn)代Web應(yīng)用程序中。它們通過HTTP發(fā)起，并通過雙向雙向通信提供長期連接。

WebSocket用于各種目的，包括執(zhí)行用戶操作和傳輸敏感信息。幾乎與常規(guī)HTTP一起出現(xiàn)的任何Web安全漏洞也可能與WebSockets通信有關(guān)。

2. HTTP和WebSockets有什么區(qū)別？

Web瀏覽器和網(wǎng)站之間的大多數(shù)通信使用HTTP。使用HTTP，客戶端發(fā)送請求，服務(wù)器返回響應(yīng)。通常，響應(yīng)立即發(fā)生，并且事務(wù)完成。即使網(wǎng)絡(luò)連接保持打開狀態(tài)，這也將用于請求和響應(yīng)的單獨事務(wù)。

一些現(xiàn)代網(wǎng)站使用WebSockets。WebSocket連接是通過HTTP發(fā)起的，通常是長期存在的。消息可以隨時向任一方向發(fā)送，并且本質(zhì)上不是事務(wù)性的。在客戶端或服務(wù)器準(zhǔn)備發(fā)送消息之前，連接通常將保持打開和空閑狀態(tài)。

WebSocket在需要低延遲或服務(wù)器啟動消息的情況下（例如財務(wù)數(shù)據(jù)的實時提要）特別有用。

3. 如何建立WebSocket連接？

WebSocket連接通常是使用客戶端JavaScript創(chuàng)建的，如下所示：

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

注意

該wss協(xié)議建立在一個加密的TLS連接的WebSocket，而ws協(xié)議使用未加密的連接。

為了建立連接，瀏覽器和服務(wù)器通過HTTP執(zhí)行WebSocket握手。瀏覽器發(fā)出WebSocket握手請求，如下所示：

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

如果服務(wù)器接受連接，則它將返回WebSocket握手響應(yīng)，如下所示：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

此時，網(wǎng)絡(luò)連接保持打開狀態(tài)，并且可以用于向任一方向發(fā)送WebSocket消息。

注意

WebSocket握手消息的幾個功能值得注意：

• 請求和響應(yīng)中 的Connection和Upgrade標(biāo)頭表示這是WebSocket握手。

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

• 請求頭的Sec-WebSocket-Key包含Base64編碼的隨機值，這應(yīng)該在每個握手請求是隨機產(chǎn)生的。

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

4. WebSocket消息是什么樣的？

建立WebSocket連接后，客戶端或服務(wù)器可以在任一方向上異步發(fā)送消息。

可以使用客戶端JavaScript從瀏覽器發(fā)送一條簡單消息，如下所示：

ws.send("Peter Wiener");

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

例如，使用WebSockets的聊天機器人應(yīng)用程序可能會發(fā)送如下消息：

{"user":"Hal Pline","content":"I wanted to be a Playstation growing up, not a device to answer your inane questions"}

5. WebSockets安全漏洞

原則上，實際上與WebSockets有關(guān)的任何Web安全漏洞都可能出現(xiàn)：

• 傳輸?shù)椒?wù)器的用戶提供的輸入可能會以不安全的方式進行處理，從而導(dǎo)致漏洞，例如SQL注入或XML外部實體注入。

• 通過WebSockets達到的某些盲目漏洞可能僅使用帶外（OAST）技術(shù)才能檢測到。

• 如果攻擊者控制的數(shù)據(jù)通過WebSockets傳輸?shù)狡渌麘?yīng)用程序用戶，則可能導(dǎo)致XSS或其他客戶端漏洞。

5.1 處理WebSocket消息以利用漏洞

可以通過篡改WebSocket消息的內(nèi)容來發(fā)現(xiàn)和利用影響WebSocket的大多數(shù)基于輸入的漏洞。

例如，假設(shè)聊天應(yīng)用程序使用WebSockets在瀏覽器和服務(wù)器之間發(fā)送聊天消息。用戶鍵入聊天消息時，將向服務(wù)器發(fā)送如下所示的WebSocket消息：

{"message":"Hello Carlos"}

消息的內(nèi)容（再次通過WebSockets）傳輸?shù)搅硪粋€聊天用戶，并在用戶的瀏覽器中呈現(xiàn)，如下所示：

<td>Hello Carlos</td>

在這種情況下，只要沒有其他輸入處理或防御措施在起作用，攻擊者就可以通過提交以下WebSocket消息來執(zhí)行概念驗證XSS攻擊：

{"message":"<img src=1 onerror='alert(1)'>"}

靶場url：https://portswigger.net/web-security/websockets/lab-manipulating-messages-to-exploit-vulnerabilities

復(fù)現(xiàn)詳情：

首頁存在實時聊天功能，對話框直接插入xss，抓包修改：

修改為：

可以看到payload已成功插入：

成功彈窗：

5.2 操縱WebSocket握手以利用漏洞

只能通過操縱WebSocket握手來發(fā)現(xiàn)和利用某些WebSocket漏洞。這些漏洞往往涉及設(shè)計缺陷，例如：

• 在HTTP標(biāo)頭中放錯位置的信任以執(zhí)行安全性決策，例如X-Forwarded-For標(biāo)頭。

• 會話處理機制存在缺陷，因為處理WebSocket消息的會話上下文通常由握手消息的會話上下文確定。

• 應(yīng)用程序使用的自定義HTTP標(biāo)頭引入的攻擊面。

靶機url：https://portswigger.net/web-security/websockets/lab-manipulating-handshake-to-exploit-vulnerabilities

復(fù)現(xiàn)詳情：

同理，直接在實時聊天的對話框中插入xss，觀察到攻擊已被阻止，并且WebSocket連接已終止。重新加載后，觀察到連接嘗試失敗，因為IP地址已被禁止。

重新請求并抓包，修改請求頭，添加xff：

可以重新連接WebSocket，并嘗試有效的xss：

成功彈窗：

5.3 使用跨站點WebSocket利用漏洞

當(dāng)攻擊者從攻擊者控制的網(wǎng)站建立跨域WebSocket連接時，會出現(xiàn)一些WebSockets安全漏洞。這稱為跨站點WebSocket劫持攻擊，它涉及利用WebSocket握手上的跨站點請求偽造（CSRF）漏洞。攻擊通常會產(chǎn)生嚴(yán)重的影響，使攻擊者可以代表受害者用戶執(zhí)行特權(quán)操作或捕獲受害者用戶可以訪問的敏感數(shù)據(jù)。

5.3.1 什么是跨站點WebSocket劫持？

跨站點WebSocket劫持（也稱為跨域WebSocket劫持）涉及WebSocket握手上的跨站點請求偽造（CSRF）漏洞。當(dāng)WebSocket握手請求僅依靠HTTP cookie進行會話處理并且不包含任何CSRF令牌或其他不可預(yù)測的值時，就會出現(xiàn)這種情況。

攻擊者可以在自己的域上創(chuàng)建惡意網(wǎng)頁，從而建立與易受攻擊的應(yīng)用程序的跨站點WebSocket連接。該應(yīng)用程序?qū)⒃谑芎τ脩襞c該應(yīng)用程序的會話的上下文中處理連接。

然后，攻擊者的頁面可以通過連接向服務(wù)器發(fā)送任意消息，并讀取從服務(wù)器接收回的消息內(nèi)容。這意味著，與常規(guī)CSRF不同，攻擊者可以與受感染的應(yīng)用程序進行雙向交互。

5.3.2 跨站點WebSocket劫持有什么影響？

成功的跨站點WebSocket劫持攻擊通常會使攻擊者能夠：

• 執(zhí)行偽裝成受害者用戶的未授權(quán)操作。與常規(guī)CSRF一樣，攻擊者可以將任意消息發(fā)送到服務(wù)器端應(yīng)用程序。如果應(yīng)用程序使用客戶端生成的WebSocket消息執(zhí)行任何敏感操作，則攻擊者可以跨域生成合適的消息并觸發(fā)這些操作。

• 檢索用戶可以訪問的敏感數(shù)據(jù)。與常規(guī)CSRF不同，跨站點WebSocket劫持使攻擊者可以通過劫持的WebSocket與易受攻擊的應(yīng)用程序進行雙向交互。如果應(yīng)用程序使用服務(wù)器生成的WebSocket消息將任何敏感數(shù)據(jù)返回給用戶，則攻擊者可以攔截這些消息并捕獲受害用戶的數(shù)據(jù)。

5.3.3 執(zhí)行跨站點WebSocket劫持攻擊

由于跨站點WebSocket劫持攻擊本質(zhì)上是WebSocket握手上的CSRF漏洞，因此執(zhí)行攻擊的第一步是檢查應(yīng)用程序執(zhí)行的WebSocket握手，并確定是否針對CSRF進行了保護。

就CSRF攻擊的正常情況而言，您通常需要查找僅依賴HTTP cookie進行會話處理并且在請求參數(shù)中不使用任何令牌或其他不可預(yù)測值的握手消息。

例如，以下WebSocket握手請求可能容易受到CSRF的攻擊，因為唯一的會話令牌是在cookie中傳輸?shù)模?/p>

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

注意

該Sec-WebSocket-Key頭包含一個隨機值，以防止緩存代理的錯誤，而不是用于身份驗證或會話處理的目的。

如果WebSocket握手請求容易受到CSRF的攻擊，則攻擊者的網(wǎng)頁可以執(zhí)行跨站點請求以在易受攻擊的站點上打開WebSocket。攻擊的下一步將完全取決于應(yīng)用程序的邏輯以及它如何使用WebSockets。攻擊可能涉及：

• 發(fā)送WebSocket消息以代表受害者用戶執(zhí)行未經(jīng)授權(quán)的操作。

• 發(fā)送WebSocket消息以檢索敏感數(shù)據(jù)。

• 有時，只是等待包含敏感數(shù)據(jù)的傳入消息到達。

6. 如何保護WebSocket連接

為了將WebSocket引起的安全漏洞的風(fēng)險降至最低，請使用以下準(zhǔn)則：

• 使用wss://協(xié)議（基于TLS的WebSockets）。

• 硬編碼WebSockets終結(jié)點的URL，當(dāng)然不要將用戶可控制的數(shù)據(jù)合并到此URL中。

• 保護WebSocket握手消息免受CSRF的攻擊，以避免跨站點WebSocket劫持漏洞。

• 雙向?qū)⑼ㄟ^WebSocket接收的數(shù)據(jù)視為不可信。在服務(wù)器和客戶端上安全地處理數(shù)據(jù)，以防止基于輸入的漏洞，例如SQL注入和跨站點腳本。

以上是“WebSockets安全漏洞的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！