¿Desventajas de almacenar un token de autenticación en el lado del cliente?

9

Estoy trabajando en una aplicación web ASP.NET MVC, que recupera sus datos de una API en la parte posterior. Por lo tanto, la autenticación se realiza actualmente a través de la autenticación de formularios ASP.NET, lo que significa que el cliente envía un correo electrónico y una contraseña al sitio web, el sitio web transfiere esos datos a la API que devuelve un token de autenticación, que se almacena dentro de una sesión ASP.NET. Después de eso, la cookie de autenticación se establece en el cliente.

Está bien y es seguro (según mi conocimiento actual), no hay credenciales ni el token se almacena en el lado del cliente.

Como inconveniente, todas las solicitudes de AJAX deben enrutarse a través del sitio web. Como resultado, tengo un gran número de acciones de ASP.NET MVC, que no hacen nada más que reenviar la solicitud a la API y devolver el resultado que regresa de allí.

Eso puede ser un obstáculo en el futuro, porque la infraestructura del sitio web se debe escalar de la misma manera que la infraestructura de la API. Ahora estoy buscando una solución para eliminar estas llamadas redundantes a través del sitio web e ir directamente a la API desde el cliente (a través de AJAX).

Eso requiere autenticación API del cliente. Eso no sería un problema, técnicamente, si almaceno el token de autenticación en LocalStorage (los navegadores antiguos no son compatibles).

¿Pero qué tan seguro es ese enfoque? ¿Qué opciones existen para robar el token, junto a JSONP (que se puede evitar al no incluir scripts externos, verdad?)?

    
pregunta asp_net 04.04.2013 - 11:28
fuente

1 respuesta

5

Ya que harás llamadas al servidor API a través de Ajax (lo que significa que la misma página, y el mismo contexto de JavaScript, será constante) sugeriría crear un token de corta duración en el servidor principal, con la solicitud del navegador una vez, luego usarlo para autenticarse con el servidor API hasta que la página se cierre (o el token caduque, lo que ocurra primero). La próxima vez que el usuario visite la página, genere un nuevo token.

De esta manera, las llamadas al servidor principal serán poco frecuentes (y no podrá evitarlas de todas formas, ya que cada vez que el usuario cierra la sesión o borra las cookies, tendrá que autenticarse nuevamente con el sitio principal), y usted evite la molestia de tener que proteger otro dato.

En cuanto a los vectores de ataque de almacenamiento local, creo que en teoría son aproximadamente los mismos que los relacionados con las cookies: XSS, acceso físico a la máquina, etc., ya que están sujetos a los mismos Política de origen (al menos las creadas por una página protegida con SSL), pero a diferencia de las cookies, no admite una visibilidad restringida por ruta (es decir, todas las páginas del dominio pueden acceder a los datos desde cualquier otra página) . Sin embargo, en la práctica, puede haber inconsistencias en la forma en que se implementa, así como en otros agujeros de seguridad, por lo que no confiaría en ello a menos que estuviera seguro de que es seguro (algo que realmente no puedo afirmar con mi conocimiento actual). De acuerdo con esta guía OWASP que almacena datos confidenciales en el almacenamiento local no se recomienda. SessionStorage es tampoco es a prueba de balas .

    
respondido por el mgibsonbr 04.04.2013 - 12:38
fuente

Lea otras preguntas en las etiquetas