# Cross-site WebSocket hijacking (CSWSH)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
## Qu'est-ce que les WebSockets
Les connexions WebSocket sont initiées via **HTTP** et sont généralement **durables**. Les messages peuvent être envoyés **dans les deux sens à tout moment** et ne sont pas transactionnels. La connexion restera normalement ouverte et inactive jusqu'à ce que le client ou le serveur soit prêt à envoyer un message.\
Les WebSockets sont particulièrement utiles dans les situations où une **latence faible ou des messages initiés par le serveur** sont nécessaires, comme les flux en temps réel de données financières.
## Comment les connexions WebSocket sont-elles établies ?
(Ici, vous trouverez un résumé, mais un **guide plus détaillé sur la création d'une connexion WebSocket** peut être trouvé [**ici**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)).\
Les connexions WebSocket sont généralement créées à l'aide de JavaScript côté client, comme dans l'exemple suivant :
```javascript
var ws = new WebSocket("wss://normal-website.com/chat");
```
Le protocole **`wss`** établit une connexion WebSocket via une connexion **TLS** chiffrée, tandis que le protocole **`ws`** utilise une connexion **non chiffrée**.
Pour établir la connexion, le navigateur et le serveur effectuent une poignée de main WebSocket via HTTP. Le navigateur envoie une demande de poignée de main WebSocket comme suit :
```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
```
Si le serveur accepte la connexion, il renvoie une réponse de poignée de main WebSocket comme suit:
```javascript
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
```
À ce stade, la connexion réseau reste ouverte et peut être utilisée pour envoyer des messages WebSocket dans les deux sens.
**Remarque**
Plusieurs **caractéristiques** des messages de **poignée de main WebSocket** méritent d'être notées :
* Les en-têtes **`Connection`** et **`Upgrade`** dans la requête et la réponse **indiquent** qu'il s'agit d'une **poignée de main WebSocket**.
* L'en-tête de requête **`Sec-WebSocket-Version`** spécifie la **version du protocole WebSocket** que le client souhaite utiliser. Cela est généralement `13`.
* L'en-tête de requête **`Sec-WebSocket-Key`** contient une **valeur aléatoire** encodée en Base64, qui doit être générée de manière aléatoire à chaque requête de poignée de main.
* L'en-tête de réponse **`Sec-WebSocket-Accept`** contient un hachage de la valeur soumise dans l'en-tête de requête `Sec-WebSocket-Key`, concaténé avec une chaîne spécifique définie dans la spécification du protocole. Cela est fait pour éviter les réponses trompeuses résultant de serveurs mal configurés ou de proxies de mise en cache.
L'en-tête **`Sec-WebSocket-Key`** contient une **valeur aléatoire** pour éviter les erreurs des proxies de mise en cache et **n'est pas utilisé à des fins d'authentification ou de gestion de session** (_Ce n'est pas un jeton CSRF_).
### 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
```
## Connexions websocket MitM
Si vous constatez que des clients sont connectés à un **websocket HTTP** depuis votre réseau local actuel, vous pouvez essayer une [attaque d'ARP Spoofing](../generic-methodologies-and-resources/pentesting-network/#arp-spoofing) pour effectuer une attaque MitM entre le client et le serveur.\
Une fois que le client essaie de se connecter à vous, vous pouvez ensuite 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 des Websockets
* **Burp Suite** prend en charge la communication MitM des websockets de la même manière qu'elle le fait pour la communication HTTP classique.
* [**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 afficher toutes les communications WebSocket et Socket.IO entre le client et le serveur.
* [**wsrepl**](https://github.com/doyensec/wsrepl) est un **REPL interactif pour les websockets** 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) parmi d'autres types de communications/protocoles, il 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.
## Piratage de WebSocket entre sites (CSWSH)
Également connu sous le nom de _piratage de WebSocket entre origines croisées_.\
**Il s'agit d'une** [**falsification de requête entre sites (CSRF)**](csrf-cross-site-request-forgery.md) **sur une poignée de main WebSocket**.
Cela se produit lorsque la requête de **poignée de main WebSocket** repose uniquement sur les **cookies HTTP** pour la gestion de session et ne contient **aucun jeton CSRF** ou autre valeur imprévisible.\
Un attaquant peut créer une **page web malveillante** sur son propre domaine qui **établit une connexion WebSocket entre sites** avec l'application vulnérable. L'application traitera la connexion dans le **contexte de la session de l'utilisateur victime** avec l'application.
### Attaque simple
Notez que lors de l'**établissement** d'une **connexion websocket**, le **cookie** est **envoyé** au serveur. Le **serveur** peut l'utiliser pour **associer** 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 message avec "**READY**" est envoyé, alors une **simple XSS** é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**.
```markup
```
### Cross Origin + Cookie avec un sous-domaine différent
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 du websocket avait lieu. Étant donné que c'était un **sous-domaine**, le **cookie** était **envoyé**, et parce que le **Websocket ne vérifiait pas correctement l'Origine**, il était possible de communiquer avec lui et de **voler des jetons**.
### Vol de données utilisateur
Copiez l'application web que vous souhaitez usurper (les fichiers .html par exemple) et ajoutez ce code à l'intérieur du script où la communication du websocket a lieu :
```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