tcp - nodejs - websocket server php

¿Cuál es la máscara en un marco WebSocket?

Question

Estoy trabajando en una implementación de websocket y no sé cuál es el sentido de una máscara en un marco.

¿Alguien podría explicarme qué hace y por qué se lo recomienda?

 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 ... |
+---------------------------------------------------------------+

Answer 1

De este artículo :

Se requiere el enmascaramiento del tráfico de WebSocket de cliente a servidor debido a la improbable posibilidad de que un código malicioso haga que algunos proxies rotos hagan algo incorrecto y lo usen como un ataque de algún tipo. Nadie ha probado que esto realmente podría suceder, pero dado que el hecho de que podría suceder era motivo suficiente para que los proveedores de navegadores se pusieran nerviosos, se agregó máscaras para eliminar la posibilidad de que se use como un ataque.

Entonces, suponiendo que los atacantes pudieran comprometer tanto el código JavaScript ejecutado en un navegador como el servidor backend, el enmascaramiento está diseñado para evitar que la secuencia de bytes enviados entre estos dos extremos esté diseñada de una manera especial que podría interrumpir cualquier proxies rotos. entre estos dos puntos finales (por roto esto significa proxies que podrían intentar interpretar una secuencia de websocket como HTTP cuando de hecho no deberían).

El navegador (y no el código JavaScript en el navegador) tiene la última palabra sobre la máscara generada aleatoriamente utilizada para enviar el mensaje y es por eso que es imposible para los atacantes saber cuál será la secuencia final de bytes que verá el proxy.

Tenga en cuenta que la máscara es redundante si su secuencia de WebSocket está encriptada (como debería ser). Artículo del autor de Python''s Flask:

¿Por qué hay enmascaramiento en absoluto? Porque aparentemente hay suficiente infraestructura rota que deja pasar el encabezado de actualización y luego maneja el resto de la conexión como una segunda solicitud HTTP que luego carga en el caché. No tengo palabras para esto. En cualquier caso, la defensa contra eso es básicamente un fuerte número aleatorio de 32 bits como clave de enmascaramiento. O ya sabes ... usa TLS y no uses proxenetas de mierda.

Answer 2

Websockets se definen en RFC6455, que establece en la Sección 5.3 :

La imprevisibilidad de la clave de enmascaramiento es esencial para evitar que los autores de aplicaciones malintencionadas seleccionen los bytes que aparecen en el cable.

En una entrada de blog sobre Websockets encontré la siguiente explicación:

clave de enmascaramiento (32 bits): si se establece el bit de máscara (y créanme, es si se escribe para el lado del servidor) puede leer aquí los bytes sin signo que se utilizan para xor la carga. Se utiliza para garantizar que los atacantes no puedan abusar de los poderes maliciosos del lado del cliente .

Pero la respuesta más clara que encontré en un archivo de la lista de correo . Allí John Tamplin dice:

Básicamente, WebSockets es único en cuanto a que necesita proteger la infraestructura de la red, incluso si tiene un código hostil ejecutándose en el cliente, un control totalmente hostil del servidor, y la única pieza en la que puede confiar es en el navegador del cliente. Al hacer que el navegador genere una máscara aleatoria para cada cuadro, el código de cliente hostil no puede elegir los patrones de bytes que aparecen en el cable y usarlos para atacar la infraestructura de red vulnerable .

Como declaró kmkaplan, el vector de ataque se describe en la Sección 10.3 de la RFC.
Esta es una medida para prevenir los ataques de envenenamiento de la memoria caché de proxy (ver el artículo sobre el ataque ). Lo que hace, es crear algo de aleatoriedad. Tienes que XOR la ​​carga útil con la clave de máscara aleatoria.

Por cierto: no es solo recomendable. Es obligatorio