Los navegadores exponen la mínima API necesaria para JavaScript interactúe con los WebSockets, utilizando eventos como onopen, onerror, onclose, y onmessage, además de métodos como close y send. Los mecanismos para transferir los datos en crudo para las llamadas desde JavaScript hacia el tráfico de red se manejan en lo más profundo del código correspondiente al navegador. La principal preocupación desde la perspectiva de la seguridad en las aplicaciones web, es como un sitio web utiliza los WebSockets: ¿Sigue validando los datos para evitar la inyección SQL o los ataques XSS? ¿Realiza la aplicación correctamente la autenticación y autorización para los usuarios accedan hacia páginas uttilizando WebSockets?

No obstante, sigue siendo interesante tener una idea básica de cómo funcionan los WebSockets en la red. En términos de WebSockets, como la tramas de datos envían datos. La referencia completa está en la sección cinco del RFC 6455. Aquí se destacan algunos aspectos interesantes.

000002AB 81 9b 82 6e f6 68 cb 1d d6 1c ea 0b 84 0d a2 0f ...n.h..........
000002BB 98 11 e0 01 92 11 a2 01 83 1c a2 1a 9e 0d f0 0b ................
000002CB c9.

La anterior trama de datos fue enviada por el navegador. El primer byte, 0×81, tiene dos mitades importantes. El valor, 0×81, representa en binario como 10000001b. El primer bit representa la bandera FIN (mensaje terminado), puesta a 1. Los tres bits siguientes no se utilizan actualmente y deben ser siempre 0. Los cuatro bits finales pueden ser uno de varios opcodes. La siguiente imagen enumera los posibles opcodes.

Observando el primer byte del ejemplo, 0×81, se determina se trata de un único fragmento (el bit FIN está activado) contiendo texto (opcode 0×01). El siguiente byte, 0x1b, indica la longitud del mensaje, 27 caracteres. Este tipo de campo de longitud prefijada es común a muchos protocolos. Si se saliera de la seguridad en las aplicaciones web para sumergirse en las pruebas de protocolo, una de las primeras pruebas sería modificar la longitud de la trama de datos para ver como reacciona el servidor a los excesos y rebasamientos de tamaño. Definir valores de gran tamaño para mensajes pequeños también podría llevar hacia un DoS, si el servidor reservase alegremente la cantidad de memoria solicitada antes de percatarse el mensaje real no era ni de lejos tan grande.

00000150 81 1b 49 73 20 74 68 65 72 65 20 61 6e 79 62 6f ..Is there anybo
00000160 64 79 20 6f 75 74 20 74 68 65 72 65 3f dy out t there?

Finalmente se tiene una trama de datos de cierre. El bit FIN está definido y el opcode 0×08 le indica al extremo remoto termine la conexión.

000002CC 88 82 04 4c 3a 56 07 a4 ...L:V..

Las tramas de datos en WebSockets tienen otros tipos de composición. Sin embargo estos aspectos están en gran medida fuera del alcance de las pruebas contra las aplicaciones web, pues son los desarrolladores de los navegadores y los desarrolladores de los servidores web quienes se encargan de esto. Aun así un proyecto paralelo para probar una implementación particular de WebSockets podría ser divertido. He aquí algunos consejos finales sobre las áreas a revisar en la capa de protocolo:

• Establecer valores de longitud no válidos;
• Establecer banderas no utilizadas;
• Banderas de enmascaramiento y claves de enmascaramiento no coincidentes;
• Respuesta de mensajes;
• Envío de tramas fuera de orden o fragmentos superpuestos;
• Fijación de secuencias UTF-8 no válidas en mensajes de texto (opcode 0×01).

La especificación define cómo deben reaccionar los clientes y servidores ante situaciones de error, pero no hay razón para esperar un código libre de errores en los navegadores o servidores. Esta es la diferencia entre seguridad de diseño y seguridad de implementación.

Fuentes:

https://www.rfc-editor.org/rfc/rfc6455
https://www.rfc-editor.org/rfc/rfc6455#section-5