¿Puede alguien explicarme qué ataca la Sec-WebSocket-Key en las direcciones de intercambio de información de WebSocket?
No lo entiendo en la RFC, ni en google.
La descripción de Wikipedia ( enlace ) del protocolo parece resumirlo mejor.
Para citar:
Además de actualizar los encabezados, el cliente envía un encabezado Sec-WebSocket-Key que contiene bytes aleatorios codificados en base64, y el servidor responde con un hash de la clave en el encabezado Sec-WebSocket-Accept. Está pensado para evitar que un proxy de almacenamiento en caché reenvíe una conversación WebSocket anterior, [25] y no proporciona ninguna autenticación, privacidad o integridad. La función de hashing agrega la cadena fija 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (un GUID) al valor de la cabecera Sec-WebSocket-Key (que no está descodificada desde la base64), aplica la función de hashing SHA-1 y codifica la resultado utilizando base64.
Editar: se eliminó la declaración sobre las protecciones de reproducción gracias a Steffen
De las Preguntas frecuentes sobre WebSockets en el IETF:
Al hacer que un cliente envíe un número aleatorio codificado y que un servidor dé una respuesta que solo puede ser generada por un servidor WebSocket, el cliente puede verificar que efectivamente está hablando con un servidor WebSocket y no con algún otro tipo de servidor. . ...
Por lo tanto, la idea principal es que WebSockets no se puede usar para hablar con sockets reales, como servidores de correo, etc. Esto es importante porque desde el navegador a menudo se puede llegar a los servidores de confianza internos y atacarlos o utilizarlos incorrectamente (enviar spam) de esta manera.
Además de eso, también se asegura de que no haya un proxy que se comporte mal y devuelva contenido en caché antiguo en lugar de pasar la conexión de WebSockets directamente al servidor.
Lea otras preguntas en las etiquetas websocket