¿Las aplicaciones web basadas en WebSocket (por ejemplo, las aplicaciones "comet") tienen que preocuparse por CSRF?

  

¿Deben las aplicaciones web que usan websockets (...) incluir nonces verificados por el servidor en cada transmisión para evitar el CSRF?

TL; DR: Esto es deseable, aunque no necesariamente en cada transmisión (una vez por conexión debería ser suficiente) y no para prevenir CSRF, sino XSS. Sin embargo, esto es más una garantía que una necesidad estricta. Detalles a continuación.

Para responder si WebSockets es o no vulnerable a CSRF, primero debemos entender las condiciones que permiten tales ataques a tener lugar:

1. El usuario se autentica en un dominio, generalmente mediante una cookie de sesión;
2. Existe uno o más tipos de solicitud HTTP que, cuando es realizada por un usuario autorizado, tendrá algún tipo de efecto secundario;
3. Debido a las excepciones a la la misma política de origen , un sitio que generalmente no debería ser se le permite hacer una solicitud determinada, y el agente de usuario incluye cookies de autenticación / autorización en esa solicitud.

Por ejemplo, cuando el sitio A incluye una etiqueta img con src apuntando al dominio B, el agente de usuario respeta la solicitud, pasando cualquier cookie que esté configurada para el dominio B. ¿Cuál es el uso de un token CSRF secreto? El objetivo es que parte de los datos de autenticación se incluyen en la propia URL , por lo que un atacante que no conoce el token no puede falsificar una URL que será aceptada por el servidor (ya que esta parte de la autenticación fallará).

AFAIK WebSockets puede abrir conexiones a cualquier servidor y puerto (descargo de responsabilidad: la referencia utilizada en la publicación vinculada puede estar desactualizada ). Pueden tener sus propias cookies (aunque no las mismas que usan las páginas HTTP, ya que el esquema es diferente) y, si mi interpretación de RFC6455 es correcto: estas cookies se enviarán junto con la solicitud de conexión independientemente del sitio que inició la solicitud (aunque el servidor puede rechazar las solicitudes provenientes de un origen diferente) ). Si estas cookies proporcionan todas la autenticación necesaria para cumplir con la solicitud, entonces el servidor cumplirá con la solicitud.

Entonces, para determinar si se puede realizar un ataque CSRF basado en WebSocket, estas preguntas deben ser consideradas (aunque me temo que no puedo darles una respuesta definitiva):

• ¿Su servidor está configurado correctamente para aceptar solo solicitudes de orígenes de confianza? ¿Se puede falsificar el origen (en este contexto)?
• ¿Puede suceder una conexión WebSocket fuera del contexto de una llamada de JavaScript, por ejemplo, creando una URL con ws o wss como esquema y usándola como src o href de un elemento de marcado? ¿Tendría eso algún efecto secundario indeseable? Sé que es una tontería, pero como no tengo una respuesta a esta pregunta, no obstante, debo plantear la posibilidad ...
• ¿Cómo se realiza su autenticación y autorización? Según esta publicación (que también destaca otros posibles problemas, no está directamente relacionado con CSRF) no hay nada integrado, por lo que debe implementarlo usted mismo. Dependiendo de cómo lo hagas y de las suposiciones que hagas sobre el comportamiento del agente de usuario, esto te abrirá para los ataques XSS (lo que, aunque es estrictamente diferente al CSRF, está relacionado en el sentido de que el navegador sería utilice su autoridad para establecer cookies de autenticación en contextos que sean diferentes de los que usted esperaba (de forma correcta o incorrecta).

  

¿Se aplican las mismas consideraciones para las conexiones websocket?

No, los websockets no tienen cookies como tales, solo tienen los datos que se envían explícitamente a través de la conexión websocket.

  

¿Las aplicaciones web que usan websockets (o transportes de reserva como el sondeo JSON, tal como lo emplean Socket.IO o SockJS) incluyen nonces verificados por el servidor en cada transmisión para evitar el CSRF?

Sí, esto es específico de la implementación. Por ejemplo, la documentación sobre la autorización de Socket.IO

  

Cuando el servidor recibe una conexión, comenzará a recopilar datos de la solicitud que podrían ser necesarios más adelante. Esto se hace por dos razones:

     

1. Es posible que los usuarios deseen autorizar a los clientes según la información de los encabezados o la dirección IP.
  
2. No todos los transportes envían encabezados cuando intentan establecer una conexión en tiempo real con el servidor, por lo que almacenamos los datos de intercambio de manera interna, por lo que estamos seguros de que los usuarios pueden reutilizar estos datos nuevamente cuando el cliente está conectado. Por ejemplo, es posible que desee leer el identificador de sesión de los encabezados de las cookies e inicializar la sesión Express para el socket conectado.
  

Por lo tanto, parece que a menos que use una sesión de nonce por usuario, es posible que los transportes de reserva sean vulnerables a CSRF si está aceptando automáticamente valores de cookies en el extremo del lado del servidor del mecanismo de reserva.

  

¿O hay una estrategia de mitigación preferida para websockets?

Los websockets no son vulnerables a CSRF , siempre que el encabezado Origin se valide durante el protocolo de enlace inicial HTTP. Así que la estrategia de mitigación es validar el encabezado Origin enviado desde el cliente.