Qu'est-ce que le masque dans un cadre WebSocket?
Je travaille sur une implémentation websocket et je ne sais pas quel est le sens d'un masque dans un cadre.
Quelqu'un pourrait-il m'expliquer ce qu'il fait et pourquoi il est recommandé?
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
Les Websockets sont définis dans la RFC6455, qui indique dans Section 5. :
L'imprévisibilité de la clé de masquage est essentielle pour empêcher les auteurs d'applications malveillantes de sélectionner les octets qui apparaissent sur le fil.
Dans une entrée de blog sur Websockets j'ai trouvé l'explication suivante:
clé de masquage (32 bits): si le bit de masque est défini (et croyez-moi, c'est si vous écrivez pour le côté serveur), vous pouvez lire ici les octets non signés qui sont utilisés pour xor la charge utile avec. Il est utilisé pour garantir que les mandataires de merde ne peuvent pas être abusés par les attaquants du côté client .
Mais la réponse la plus claire que j'ai trouvée dans un archive de la liste de diffusion . Là, John Tamplin déclare:
Fondamentalement, WebSockets est unique en ce sens que vous devez protéger l'infrastructure réseau, même si vous avez du code hostile en cours d'exécution sur le client, un contrôle hostile complet du serveur et que le seul élément auquel vous pouvez faire confiance est le navigateur client. En faisant générer par le navigateur un masque aléatoire pour chaque trame, le code client hostile ne peut pas choisir les modèles d'octets qui apparaissent sur le fil et les utiliser pour attaquer l'infrastructure réseau vulnérable .
Comme l'a indiqué kmkaplan, le vecteur d'attaque est décrit dans Section 10. du RFC.
Il s'agit d'une mesure pour empêcher les attaques d'empoisonnement du cache proxy (voir Document sur l'attaque ). Ce qu'il fait, c'est de créer un certain hasard. Vous devez XOR la charge utile avec la clé de masquage aléatoire.
Soit dit en passant: ce n'est pas seulement recommandé. C'est obligatoire .
De cet article :
Le masquage du trafic WebSocket du client vers le serveur est requis en raison de la probabilité improbable qu'un code malveillant puisse faire en sorte que certains proxys brisés fassent la mauvaise chose et l'utilisent comme une attaque quelconque. Personne n'a prouvé que cela pouvait réellement se produire, mais comme le fait que cela pouvait se produire était une raison suffisante pour que les fournisseurs de navigateurs deviennent nerveux, un masquage a été ajouté pour supprimer la possibilité qu'il soit utilisé comme une attaque.
Donc, en supposant que les attaquants ont pu compromettre à la fois le code JavaScript exécuté dans un navigateur et le serveur principal, le masquage est conçu pour empêcher la séquence d'octets envoyée entre ces deux points de terminaison d'être conçue d'une manière spéciale qui pourrait perturber les proxys cassés entre ces deux points de terminaison (par cassé, cela signifie des mandataires qui pourraient tenter d'interpréter un flux de socket Web comme HTTP alors qu'en fait ils ne devraient pas).
Le navigateur (et non le code JavaScript du navigateur) a le dernier mot sur le masque généré de manière aléatoire utilisé pour envoyer le message, c'est pourquoi il est impossible pour les attaquants de savoir quel sera le flux final d'octets que le proxy pourrait voir.
Notez que le masque est redondant si votre flux WebSocket est chiffré (comme il se doit). Article de l'auteur de Python's Flask:
Pourquoi y a-t-il du masquage? Parce qu'apparemment, il y a suffisamment d'infrastructure cassée qui permet à l'en-tête de mise à niveau de passer, puis gère le reste de la connexion comme une deuxième requête HTTP qu'il place ensuite dans le cache. Je n'ai pas de mots pour ça. Dans tous les cas, la défense contre cela est fondamentalement un nombre aléatoire fort de 32 bits comme clé de masquage. Ou vous savez… utilisez TLS et n'utilisez pas de mandataires de merde.