Problemas de autenticación de token y almacenamiento / websocket

2

Mi aplicación está ejecutando una autenticación de API que usa tokens en lugar de cookies.

Esto me lleva a hacer algunas preguntas:

  • ¿Cuál es la forma más segura de almacenar el token?

Al utilizar tokens aleatorios, elimina el problema de los ataques CSRF, pero en el otro lado no hay indicadores Secure y HTTPOnly .

Pensé que tal vez usar algún tipo de truco con las nuevas características ECMAScript Harmony Object.freeze() y Object.seal() , pero esto parece ser más un hack que algo que sería seguro.

  • ¿Cómo debo autenticar WebSocket clientes como Socket.io encima de HTTPS?

La mayoría de las bibliotecas como Socket.io , ws , Sockjs y Faye no permiten configurar encabezados HTTP personalizados o no es compatible con los diversos protocolos de respaldo como los sockets Flash.

Una posibilidad sería enviar el token como parte del protocolo de enlace en los argumentos de consulta de la URL, pero realmente no me gusta porque significa que:

1): los tokens se mostrarán en los archivos de registro que solo registran la URL

2): tendría que autenticarme primero durante el protocolo de enlace y luego cada vez que envíe datos, lo que significaría dos sistemas separados.

Eso está encima de mi cabeza pensando un poco al respecto. Puede haber más problemas subyacentes.

  • ¿Soy demasiado paranoico y esta opción es realmente segura?

También podría implementar algún tipo de esquema asimétrico utilizando un sistema de clave pública / privada, pero esto parece simplemente propenso a errores / complicado para ser una solución confiable.

Mi pregunta final es más una consecuencia de las preguntas anteriores:

  • ¿Vale la pena el hecho de tener tokens aleatorios en lugar de cookies?

Por un lado, no tienes vulnerabilidades de ataque CSRF, pero por otro lado tienes muchos otros casos en los que las respuestas (al menos para mí) no parecen ser tan claras.

¡Gracias de antemano!

    
pregunta Awake Zoldiek 18.12.2013 - 00:10
fuente

1 respuesta

1

Para almacenar el token:

  • Para una aplicación web tradicional (no Ajax), generalmente almacena el token en un campo de formulario oculto.

  • Para una aplicación de una sola página, generalmente almacena el token en una variable de JavaScript y lo incluye en los datos JSON con cada solicitud.

Este enfoque evita que el token esté en la URL y funciona con WebSockets.

La mayoría de las aplicaciones utilizan una cookie como ID de sesión principal, y tienen un segundo token que es puramente para evitar el CSRF. Puede deshacerse de la cookie y usar únicamente el token, como sugiere, pero hacerlo no es una práctica estándar, por lo que solo debe hacerlo si está seguro de que sabe lo que está haciendo.

Como mencionas, las cookies tienen una opción HttpOnly que no es posible con tokens. Aunque los tokens no tienen una marca de seguridad como tal, eso es menos importante, ya que puede ajustar su código para que el token solo se envíe por SSL.

Otra cosa a tener en cuenta es que ahora puedes prevenir el CSRF sin usar tokens, principalmente con encabezado de origen . Sin embargo, la mayoría de los sitios todavía usan tokens.

Puede realizar la autenticación de cookies normal con WebSockets. Esta pregunta contiene información. No sé cuáles son las implicaciones de CSRF de esto.

    
respondido por el paj28 08.04.2014 - 14:41
fuente

Lea otras preguntas en las etiquetas