<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
* 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.
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.
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:
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 :
- 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.
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 :
* **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**.
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.
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.
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**.
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à**.
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:
Maintenant, téléchargez le fichier `wsHook.js` depuis [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) et **enregistrez-le à l'intérieur du dossier contenant les fichiers web**.\
Les conditions de course dans les WebSockets sont également une chose, [consultez ces informations pour en savoir plus](race-condition.md#rc-in-websockets).
Comme les WebSockets sont un mécanisme pour **envoyer des données côté serveur et côté client**, en fonction de la manière dont le serveur et le client gèrent les informations, **les WebSockets peuvent être utilisés pour exploiter plusieurs autres vulnérabilités telles que XSS, SQLi ou toute autre vulnérabilité web commune en utilisant l'entrée d'un utilisateur à partir d'un websocket.**
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 :
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](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) github repos.