Negación de servicio (DoS). Los navegadores web limitan el número de conexiones concurrentes hechos hacia un Origen (la página de una aplicación web puede estar constituida de recursos desde varios Orígenes). Este límite suele ser de cuatro o seis para equilibrar la capacidad de respuesta percibida por el navegador con la sobrecarga de conexión impuesta al servidor. Las conexiones WebSockets no tienen las mismas restricciones por origen. Esto no significa se haya ignorado la posibilidad de utilizar WebSockets para hacer DoS hacia un sitio. En cambio el protocolo define comportamientos los cuales deben seguir los navegadores y los servidores. Por lo tanto el diseño del protocolo está destinado a minimizar esta preocupación para los propietarios de los sitios, pero eso no significa los errores de implementación permitendo los ataques DoS aparecerán en los navegadores.

Por ejemplo, una carga útil de inyección HTML podría entregar código JavaScript para crear docenas de conexiones WebSockets desde los navegadores de las víctimas hacia el sitio web. La mera presencia de WebSockets sobre un sitio no es una vulnerabilidad. Este ejemplo describe el uso de WebSockets para agravar otro exploit (cross-site scripting) de forma tal el sitio quede inutilizable.

Protocolos en túnel. La tunelización de protocolos binarios (es decir datos no textuales) a través de WebSockets es una ventaja convincente de esta API. Aunque el protocolo WebSocket puede estar implementado de forma segura, el protocolo tunelizado sobre este puede no estarlo. Los desarrolladores web deben aplicar los mismos principios para la validación de entradas, autenticación, autorización, etc., para la gestión del lado del servidor de los datos llegando a través de una conexión WebSocket. El uso de una conexión wss: // desde un navegador actualizado no tiene relación con los potenciales desbordamientos de búfer para el código en el lado del servidor manejando el chat, la transmisión de imágenes, o cualquier otro elemento enviado a través de la conexión.

Este problema no es específico de los protocolos binarios, pero se destacan aquí porque tienden a ser más difíciles de inspeccionar. Es mucho más fácil para los desarrolladores leer y revisar los datos de texto como las peticiones HTTP y los datos POST, comparado con inspeccionar los flujos de datos binarios. Esto último requiere herramientas adicionales para inspeccionar y verificar. Tener en consideración este problema de seguridad está relacionado con la forma en la cual se utilizan los WebSockets, no una inseguridad en el propio protocolo WebSocket.

Servidor Retransmisor no Fiable. El endpoint ws: // o wss: // podría retransmitir datos desde el navegador hacia un Origen arbitrario, violando las expectativas de privacidad o los controles de seguridad. Por un lado, una conexión a wss: //web. site/ podría enviar datos desde el navegador hacia un servidor VNC, en una red interna normalmente inalcanzable desde la Internet pública, como si fuera una conexión VPN. Este uso no viola ni el espíritu ni la especificación de WebSockets. En otro escenario, una conexión WebSocket podría ser utilizada para retransmitir mensajes desde el navegador hacia un servidor IRC. De nuevo, esto podría ser un uso inteligente de los WebSockets. Sin embargo el retransmisor IRC podría vigilar los mensajes pasados a través de este, incluso retransmitir los mensajes hacia diferentes destinos según se requiera. En otro caso, una conexión WebSocket podría ofrecer un servicio de inicio de sesión único a través de una conexión encriptada wss: //, pero proxear datos como nombre de usuario y contraseña a través de canales no encriptados como HTTP.

No hay más o menos razón para confiar en un servidor ejecutando un servicio WebSocket comparado con uno ejecutando HTTP normal. Un servidor malicioso atacará los datos de un usuario independientemente de la seguridad correspondiente a la conexión o al navegador. Los WebSockets proporcionan un medio para introducir en el navegador protocolos útiles diferentes a HTTP, con posibilidades yendo desde la mensajería de texto hasta la transferencia de vídeo. Sin embargo la capacidad de los WebSockets para transferir datos arbitrarios revivirá antiguas estafas en las cuales los sitios maliciosos actúan como front-ends destinos de medios sociales, bancarios, etc. Los WebSockets serán simplemente otra herramienta la cual permitirá estos esquemas. Igual se debe advertir a los usuarios de no confíen demasiado en la "seguridad" de los certificados SSL, se debe tener cuidado con el tipo de datos transmitiendose a través de las conexiones WebSocket. Los desarrolladores de navegadores y los propietarios de sitios web no pueden hacer mucho para bloquear el phishing, y otros ataques similares de ingeniería social.

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Appli...
https://portswigger.net/web-security/websockets