Prevención de ataques CSRF contra las comunicaciones de WebSocket

Es posible un ataque CSRF en WebSocket, si confía en las cookies de autenticación. De RFC 6455 §1.3:

  

El | Origen | el campo de encabezado [RFC6454] se usa para proteger contra el uso de origen cruzado no autorizado de un servidor WebSocket mediante scripts utilizando la API de WebSocket en un navegador web . Se informa al servidor del origen del script que genera la solicitud de conexión de WebSocket. Si el servidor no desea aceptar conexiones desde este origen, puede elegir rechazar la conexión mediante el envío de un código de error HTTP adecuado. Este campo de encabezado es enviado por los clientes del navegador; para los clientes que no son navegadores, este campo encabezado se puede enviar si tiene sentido en el contexto de esos clientes.

He resaltado algunas partes. La primera palabra mágica es lata y la segunda es la de mayo. Los servidores WebSocket pueden verificar el origen, pero esto es opcional. Los clientes que no son navegadores pueden enviar el encabezado de origen, pero esto no es obligatorio.

Un actor malintencionado podría usar un ataque CSRF para abrir una conexión WebSocket a un servidor WebSocket y el navegador agregaría las cookies a la solicitud. Si el servidor no comprueba el origen, o si comprueba el origen pero el origen está falsificado, entonces el ataque adquiere un túnel de lectura y escritura al servidor WebSocket con los permisos de la víctima.

La verificación del origen probablemente cubre la mayoría de los ataques, ya que los humanos tradicionalmente usan los principales navegadores que envían el encabezado de origen correcto. Sin embargo, frente a los clientes que no son navegadores, que pueden " enviar campos de encabezado | Origen | falsos, confundiendo al servidor " [RFC 6455 §10.1], se deben aplicar otros mecanismos. Esta publicación del blog sugiere tanto verificar el origen como usar tokens aleatorios de sesión individuales como contramedidas. Supongo que también se puede realizar algún tipo de autenticación a través de la conexión WebSocket, una vez establecida, aunque esto puede dañar la usabilidad.

Nota, mi respuesta a continuación asume que el encabezado de Origen se está comprobando correctamente y responde a su pregunta específicamente.

El secuestro de sockets es posible si no hay verificaciones de origen u otras verificaciones de autenticación válidas realizadas en su propio código al abrir un nuevo websocket.

La respuesta original sigue ...

  

¿Es posible que un atacante provoque (al atraer a la víctima a presionar un enlace) a un usuario legítimo para que abra un websocket hacia el servicio legítimo y / o haga que la víctima envíe mensajes creados por un atacante dentro del websocket existente de la víctima? ? (similar a un ataque CSRF estándar en el contexto de HTTP).

No, un atacante no podría realizar CSRF con websockets abriendo un nuevo websocket o reutilizando el websocket existente de la víctima.

Al abrir un nuevo websocket: un atacante podría hacer esto, pero no tendría ningún mecanismo para proporcionar credenciales de autenticación al oyente de socket. Durante una solicitud HTTP inicial de reconocimiento, el encabezado Origin se puede usar en el lado del servidor para verificar que se trata de un origen válido. Para el socket en sí, a diferencia de una solicitud HTTP normal, no hay encabezados enviados por el navegador para identificar o autenticar al usuario de forma predeterminada.

Reutilizando el websocket existente de la víctima: Diga que el websocket está declarado así en la página de inicio de www.example.com :

var exampleSocket = new WebSocket("ws://www.example.com/socketserver", "protocolOne");

Un atacante no podrá obtener una referencia a exampleSocket ya que el acceso al www.example.com 's DOM está protegido por Política del mismo origen .