WebSockets - Sécurité
Le protocole doit être conçu pour des raisons de sécurité. WebSocket est un tout nouveau protocole et tous les navigateurs Web ne l'implémentent pas correctement. Par exemple, certains d'entre eux autorisent toujours le mélange de HTTP et de WS, bien que la spécification implique le contraire. Dans ce chapitre, nous aborderons quelques attaques de sécurité courantes dont un utilisateur doit être conscient.
Déni de service
Les attaques par déni de service (DoS) tentent de rendre une machine ou une ressource réseau indisponible pour les utilisateurs qui en font la demande. Supposons que quelqu'un fasse un nombre infini de requêtes à un serveur Web avec des intervalles de temps inexistants ou minuscules. Le serveur n'est pas en mesure de gérer chaque connexion et cessera de répondre ou continuera de répondre trop lentement. Cela peut être qualifié d'attaque par déni de service.
Le déni de service est très frustrant pour les utilisateurs finaux, qui ne peuvent même pas charger une page Web.
L'attaque DoS peut même s'appliquer aux communications peer-to-peer, forçant les clients d'un réseau P2P à se connecter simultanément au serveur Web de la victime.
L'homme au milieu
Comprenons cela à l'aide d'un exemple.
Supposons qu'une personne A discute avec son ami Bvia un client IM. Une tierce personne souhaite voir les messages que vous échangez. Ainsi, il établit des liens indépendants avec les deux personnes. Il envoie également des messages à la personneA et son ami B, comme intermédiaire invisible de votre communication. Ceci est connu sous le nom d'attaque de l'homme du milieu.
Le type d'attaque de type «man-in-the-middle» est plus facile pour les connexions non chiffrées, car l'intrus peut lire les paquets directement. Lorsque la connexion est cryptée, les informations doivent être décryptées par l'attaquant, ce qui peut être bien trop difficile.
D'un point de vue technique, l'attaquant intercepte un échange de message à clé publique et envoie le message en remplaçant la clé demandée par la sienne. De toute évidence, une stratégie solide pour rendre le travail de l'attaquant difficile consiste à utiliser SSH avec WebSockets.
Surtout lors de l'échange de données critiques, préférez la connexion sécurisée WSS au lieu du WS non chiffré.
XSS
Le cross-site scripting (XSS) est une vulnérabilité qui permet aux attaquants d'injecter des scripts côté client dans des pages Web ou des applications. Un attaquant peut envoyer du code HTML ou Javascript à l'aide de vos hubs d'application et laisser ce code s'exécuter sur les machines des clients.
Mécanismes de défense natifs WebSocket
Par défaut, le protocole WebSocket est conçu pour être sécurisé. Dans le monde réel, l'utilisateur peut rencontrer divers problèmes pouvant survenir en raison d'une mauvaise mise en œuvre du navigateur. Au fil du temps, les fournisseurs de navigateurs résolvent immédiatement les problèmes.
Une couche de sécurité supplémentaire est ajoutée lors de l'utilisation d'une connexion WebSocket sécurisée via SSH (ou TLS).
Dans le monde WebSocket, la principale préoccupation concerne les performances d'une connexion sécurisée. Bien qu'il y ait encore une couche TLS supplémentaire sur le dessus, le protocole lui-même contient des optimisations pour ce type d'utilisation, en outre, WSS fonctionne plus élégamment via des proxys.
Masquage client-serveur
Chaque message transmis entre un serveur WebSocket et un client WebSocket contient une clé spécifique, nommée clé de masquage, qui permet à tout intermédiaire compatible WebSocket de démasquer et d'inspecter le message. Si l'intermédiaire n'est pas compatible WebSocket, le message ne peut pas être affecté. Le navigateur qui implémente le protocole WebSocket gère le masquage.
Boîte à outils de sécurité
Enfin, des outils utiles peuvent être présentés pour étudier le flux d'informations entre vos clients et serveur WebSocket, analyser les données échangées et identifier les risques éventuels.
Outils de développement de navigateur
Chrome, Firefox et Opera sont d'excellents navigateurs en termes de support pour les développeurs. Leurs outils intégrés nous aident à déterminer presque tous les aspects des interactions et des ressources côté client. Il joue un grand rôle à des fins de sécurité.