Problema de seguridad multiusuario de Spring WebSocket, ¿cómo solucionarlo?
WebSocket es una tecnología de red para comunicación full-duplex entre navegadores y servidores que HTML5 comenzó a proporcionar. El protocolo de comunicación WebSocket fue designado como estándar RFC 6455 por el IETF en 2011, y la API WebSocket también fue designada como estándar por el W3C. Actualmente, todos los navegadores convencionales admiten la comunicación WebSocket.
El protocolo WebSocket es un protocolo de comunicación independiente basado en el protocolo TCP. Antes de establecer una conexión de comunicación WebSocket, se debe utilizar el protocolo HTTP para el protocolo de enlace y la conexión HTTP se actualiza a una conexión WebSocket. El navegador y el servidor solo necesitan completar un protocolo de enlace y se puede establecer una conexión persistente directamente entre los dos para la transmisión de datos bidireccional.
WebSocket define dos formatos de URI: "ws://" y "wss://", que son similares a HTTP y HTTPS. "ws://" utiliza transmisión de texto sin formato y el puerto predeterminado. es 80, mientras que "wss://" usa transmisión cifrada TLS y el puerto predeterminado es 443.
ws-URI:?" ws://host[:puerto]ruta[?query]"?wss-URI:?" wss://host[:puerto]ruta[?query]" ?
La fase de protocolo de enlace de WebSocket requiere cierta información del encabezado HTTP, que actualiza la conexión HTTP a una conexión WebSocket, como se muestra en la siguiente tabla.
Una conexión de protocolo de enlace completa se ve así:
Una vez que el servidor devuelve una respuesta 101, el cambio de protocolo WebSocket se completa. El lado del servidor puede cambiar el protocolo de comunicación de http:// o https:// a ws:// o wss:// según el mismo puerto. Una vez que se completa el cambio de protocolo, el navegador y el servidor pueden usar la API WebSocket para enviarse y recibir mensajes de texto y binarios entre sí.
Problemas de seguridad de las aplicaciones WebSocket
La introducción de WebSocket como protocolo de comunicación en las aplicaciones Web no resuelve los problemas de seguridad existentes en las aplicaciones Web. Por tanto, la implementación de seguridad de las aplicaciones WebSocket es de Desarrollador o. Responsabilidad del lado del servidor. Esto requiere que los desarrolladores comprendan los posibles riesgos de seguridad de las aplicaciones WebSocket y cómo desarrollarlas de forma segura para evitar estos problemas de seguridad.
Autenticación
El protocolo WebSocket no especifica cómo el servidor debe autenticar al cliente durante la fase de protocolo de enlace. El servidor puede utilizar cualquier mecanismo de autenticación del cliente del servidor HTTP, como autenticación de cookies, autenticación básica HTTP, autenticación TLS, etc. Las implementaciones de autenticación de aplicaciones WebSocket enfrentan los mismos problemas de seguridad que la autenticación de aplicaciones web tradicionales, como CVE-2015-0201, donde el cliente Java SockJS de Spring Framework genera ID de sesión predecibles que un atacante puede usar para enviar mensajes de sesión CVE-2015-1482; Ansible Tower no autentica la identidad del usuario, lo que permite a atacantes remotos obtener información confidencial a través de conexiones WebSocket.
Autorización
Al igual que la autenticación, el protocolo WebSocket no especifica ningún método de autorización, y la política de autorización para acceder a los recursos del usuario, etc. en la aplicación la implementa el servidor o el desarrollador.
Solicitudes de origen cruzado
WebSocket utiliza un modelo de seguridad basado en el origen. Al iniciar una solicitud de protocolo de enlace WebSocket, el navegador agrega un encabezado HTTP llamado Origen a la solicitud. El campo Origen indica el origen de la solicitud, evitando así el acceso no autorizado entre sitios a la solicitud.
WebSocket no se limita a los navegadores y el cliente no se limita a los navegadores. Por lo tanto, la especificación WebSocket no exige el uso del encabezado Origin durante la fase de protocolo de enlace y WebSocket no está restringido por la política del mismo origen del navegador. No validar el encabezado Origin en el lado del servidor puede resultar en un ataque de secuestro de WebSocket entre sitios. Christian Schneider descubrió y publicó por primera vez esta vulnerabilidad en 2013, denominándola Cross-Site WebSocket Hijacking (CSWSH). El secuestro de sockets web entre sitios es dañino, pero los desarrolladores lo pasan por alto fácilmente. Se pueden encontrar ejemplos en IPython Notebook (CVE-2014-3429), OpenStack Compute (CVE-2015-0259), Zeppelin WebSocket Server y otros secuestros de WebSocket entre sitios.
La figura anterior ilustra el proceso de secuestro de WebSocket entre sitios, es decir, después de que el usuario inicia sesión en la aplicación WebSocket, se le engaña para que acceda a una página web maliciosa y se le muestra un fragmento de código js. incrustado en la página web maliciosa, se iniciará automáticamente un protocolo de enlace WebSocket Solicitud para establecer una conexión WebSocket con la aplicación de destino. Tenga en cuenta que el navegador genera automáticamente Origin y Sec-WebSocket-Key. Cuando el navegador solicita acceso al servidor de destino nuevamente, automáticamente ingresará parámetros de autenticación como cookies. Si el servidor no verifica el encabezado de Origen, la solicitud se conectará con éxito y cambiará al protocolo WebSocket. Las páginas web maliciosas pueden omitir con éxito la autenticación y conectarse al servidor WebSocket, y luego robar la información enviada por el servidor o enviar información falsificada. al servidor para alterar los datos del servidor. Los ataques tradicionales de falsificación de solicitudes entre sitios (CSRF) son principalmente solicitudes de modificación de datos iniciadas silenciosamente por páginas web maliciosas. Por el contrario, los ataques de falsificación de WebSocket entre sitios no solo modifican los datos del servidor, sino que también controlan todo el canal de comunicación bidireccional. Por lo tanto, Christian llamó a la vulnerabilidad "secuestro" en lugar de "falsificación de solicitud".
Ahora que entendemos los principios y el proceso de los ataques de secuestro de WebSocket entre sitios, ¿cómo podemos prevenirlos? Es relativamente sencillo de manejar. Agregue la verificación del encabezado de Origen en el código del lado del servidor. Si la información de Origen enviada por el cliente proviene de un dominio diferente, el servidor puede rechazar la solicitud. Sin embargo, simplemente comprobar Origin no es lo suficientemente seguro. Las páginas web maliciosas pueden falsificar la información del encabezado de Origin para evitar la inspección del encabezado de Origin por parte del servidor, y una mejor solución puede aprender de la solución CSRF: el mecanismo de token.
Denegación de servicio
WebSocket está diseñado como un protocolo orientado a la conexión y puede explotarse para provocar ataques de denegación de servicio del lado del cliente y del servidor. consulte: Vulnerabilidad de denegación de servicio remota F5 BIG-IP (CVE-2016-9253).
1. Denegación de servicio del cliente
Los límites de conexión de WebSocket son diferentes de los límites de conexión HTTP. En comparación con HTTP, WebSocket tiene límites de conexión más altos y los diferentes navegadores tienen su propio número máximo. de conexiones, por ejemplo, el número máximo predeterminado de conexiones de Firefox es 200, puede explotarse para agotar todas las conexiones permitidas mediante el envío de contenido malicioso. Las conexiones Websocket pueden agotar los recursos del navegador y provocar una denegación de servicio.
2. Denegación de servicio del lado del servidor
WebSocket establece una conexión persistente. La conexión WebSocket solo se cerrará cuando el cliente o servidor envíe una solicitud para cerrar la conexión. El atacante puede El servidor envía una gran cantidad de solicitudes para establecer una conexión WebSocket, estableciendo así una conexión persistente, agotando los recursos del servidor y provocando una denegación de servicio. Esto puede provocar una denegación de servicio. Este ataque se puede prevenir estableciendo el número máximo de conexiones que se pueden establecer por una única IP.
Un atacante también puede enviar una única trama de datos grande (por ejemplo, 2^16) o un largo flujo de tramas pequeñas con información fragmentada para agotar la memoria del servidor y desencadenar un ataque de denegación de servicio, lo que se puede lograr limitando el tamaño de la trama y volver a ensamblar varios tamaños totales de mensajes después de los fotogramas para evitarlos.
Ataque de intermediario
WebSocket utiliza el protocolo HTTP o HTTPS para emitir una solicitud de protocolo de enlace. En el caso de utilizar el protocolo HTTP, si el intermediario puede rastrear el tráfico HTTP, entonces el intermediario puede obtener y manipular la solicitud de protocolo de enlace de WebSocket y establecer una conexión WebSocket con el servidor falsificando información del cliente, como se muestra en la figura siguiente. Para evitar este ataque, debe establecer una conexión WebSocket a través de un canal cifrado e iniciar la solicitud de protocolo de enlace utilizando el protocolo HTTPS.
Validación de entrada
Las aplicaciones WebSocket, al igual que las aplicaciones web tradicionales, requieren validación de entrada para evitar ataques XSS del lado del cliente, inyección SQL del lado del servidor e inyección de código.