# 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 [**NFTs**](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 **de longue durée**. 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ù des messages à **faible latence ou initiés par le serveur** sont nécessaires, comme les flux de données financières en temps réel.
## Comment les connexions WebSocket sont-elles établies ?
(Ici, vous trouverez un résumé, mais un **guide plus détaillé sur la façon dont une connexion WebSocket** est créée peut être trouvé [**ici**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)).\
Les connexions WebSocket sont normalement créées à l'aide de JavaScript côté client comme suit :
```javascript
var ws = new WebSocket("wss://normal-website.com/chat");
```
Le protocole **`wss`** établit une connexion WebSocket sur 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 sur HTTP. Le navigateur émet 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 demande et la réponse **indiquent** qu'il s'agit d'une **poignée de main WebSocket**.
* L'en-tête de demande **`Sec-WebSocket-Version`** spécifie la **version du protocole WebSocket** que le client souhaite utiliser. C'est généralement `13`.
* L'en-tête de demande **`Sec-WebSocket-Key`** contient une **valeur aléatoire** encodée en Base64, qui doit être générée de manière aléatoire dans chaque demande 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 demande `Sec-WebSocket-Key`, concaténée 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 caches proxy.
L'en-tête **`Sec-WebSocket-Key`** contient une **valeur aléatoire** pour éviter les erreurs des caches proxy, 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 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 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 les** **vulnérabilités** **connues** dans les websockets.
## 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 demande 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 gérera 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 **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 message avec "**READY**" est envoyé, alors un **simple XSS** établissant la connexion (le **cookie** sera **envoyé automatiquement** pour autoriser l'utilisateur victime) **envoyant** "**READY**" sera capable de **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 Javascript arbitraire dans un sous-domaine** du domaine où la communication 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 (par exemple les fichiers .html) et ajoutez ce code à l'intérieur du script où la communication 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