# Attaques WebSocket
Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)! Autres façons de soutenir HackTricks : * Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) ! * Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com) * Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family) * **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
## Qu'est-ce que WebSockets Les connexions WebSocket sont établies via un **poignée de main HTTP** initial 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 **faible latence ou une communication initiée par le serveur**, telles que les flux de données financières en direct. ### Établissement de connexions WebSocket Une explication détaillée sur l'établissement de connexions WebSocket peut être consultée [**ici**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). En résumé, les connexions WebSocket sont généralement initiées via JavaScript côté client comme indiqué ci-dessous: ```javascript 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**. Pendant 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 demande et que le serveur réponde, comme illustré dans les exemples suivants : Le navigateur envoie une demande de poignée de main : ```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 ``` Réponse de poignée de main du serveur: ```javascript 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 une cache mal configuré(e). - L'en-tête `Sec-WebSocket-Accept` dans la réponse du serveur est un hachage de `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. ```bash websocat --insecure wss://10.10.10.10:8000 -v ``` Ou pour créer un serveur websocat : ```bash websocat -s 0.0.0.0:8000 #Listen in port 8000 ``` ### Attaques de MitM sur les connexions websocket Si vous constatez que des clients sont connectés à un **websocket HTTP** depuis votre réseau local actuel, vous pourriez essayer une [Attaque de Spoofing ARP](../generic-methodologies-and-resources/pentesting-network/#arp-spoofing) pour effectuer une attaque de MitM entre le client et le serveur.\ Une fois que le client tente de se connecter à vous, vous pouvez alors utiliser : ```bash 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**](https://github.com/PalindromeLabs/STEWS) **pour découvrir, identifier et rechercher automatiquement des** **vulnérabilités** connues dans les websockets. ### Outils de débogage Websocket * **Burp Suite** prend en charge la communication MitM des websockets de manière très similaire à celle des communications HTTP classiques. * L'extension [**socketsleuth**](https://github.com/snyk/socketsleuth) **pour Burp Suite** 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**](https://github.com/nccgroup/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**](https://github.com/doyensec/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 en envoyer de nouveaux**, avec un framework facile à utiliser pour **automatiser** cette communication. * [**https://websocketking.com/**](https://websocketking.com/) est un **site web pour communiquer** avec d'autres sites web en utilisant des **websockets**. * [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) entre autres types de communications/protocoles, fournit un **site web pour communiquer** avec d'autres sites web en utilisant des **websockets**. ## Laboratoire Websocket Dans [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) vous avez un code pour lancer un site web utilisant des websockets et dans [**cet article**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) vous pouvez trouver une explication. ## Détournement de WebSocket inter-sites (CSWSH) Le **détournement de WebSocket inter-sites**, également connu sous le nom de **détournement de WebSocket inter-origines**, est identifié comme un cas spécifique de **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** affectant les poignées de main WebSocket. Cette vulnérabilité survient lorsque les poignées de main WebSocket s'authentifient uniquement via les **cookies HTTP** sans **jetons CSRF** ou des mesures de sécurité similaires. Les attaquants peuvent exploiter cela en hébergeant une **page web malveillante** qui initie une connexion WebSocket inter-sites à une application vulnérable. Par conséquent, cette connexion est traitée comme faisant partie de la session de la victime avec l'application, exploitant l'absence de protection CSRF dans le mécanisme de gestion de session. ### Attaque Simple Notez que lors de l'**établissement** d'une connexion **websocket**, le **cookie** est **envoyé** au serveur. Le **serveur** pourrait l'utiliser pour **relier** chaque **utilisateur spécifique** à sa **session websocket basée sur le cookie envoyé**. Ainsi, si par **exemple** le **serveur websocket** **renvoie l'historique de la conversation** d'un utilisateur si un message avec "**READY"** est envoyé, alors un **simple XSS** établissant la connexion (le **cookie** sera **envoyé automatiquement** pour autoriser l'utilisateur victime) **envoyant** "**READY**" pourra **récupérer** l'historique de la **conversation**. ```markup ``` ### Cross Origin + Cookie with a different subdomain Dans ce billet de blog [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/), l'attaquant a réussi à **exécuter du code JavaScript arbitraire dans un sous-domaine** du domaine où la communication websocket avait lieu. Étant donné qu'il s'agissait d'un **sous-domaine**, le **cookie** était **envoyé**, et comme le **Websocket ne vérifiait pas correctement l'Origine**, il était possible de communiquer avec lui et de **voler des jetons à partir de là**. ### Vol de données utilisateur Copiez l'application web que vous souhaitez usurper (les fichiers .html par exemple) et à l'intérieur du script où la communication websocket a lieu, ajoutez ce code: ```javascript //This is the script tag to load the websocket hooker //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