Evitar la suplantación del cliente con Rest Api

2

Estoy seguro de que este caso de uso tiene una solución conocida, pero no puedo encontrar nada en Google o no sé qué palabras clave utilizar. Estamos construyendo una aplicación Angular que está respaldada por un Api Rest. Para la Autorización, estamos usando OAUTH 2 y estamos almacenando el token en una cookie HTTP solamente y también estamos usando la protección XSRF ( Cross Protección de falsificación de solicitudes del sitio )

También recibimos una solicitud para crear una aplicación móvil. No encontré ningún material claro sobre cómo exponer a la aplicación móvil REST a la aplicación móvil, sin crear la posibilidad de que un pirata informático pudiera crear un cliente falso que pudiera hacerse pasar por nuestro servicio y engañar a los usuarios para que inicien sesión usando el cliente falso.

Actualizar

Déjame explicarte más. Asumamos el siguiente escenario.

La api está alojada en api.com . La api tiene dos puntos finales

  • / Token - > este punto final generará un token JWT, si las credenciales pasadas con POST son válidas

  • / GetData - > Este es un punto final, que será accesible por un usuario autorizado.

la aplicación de una sola página está alojada en spa.com .

Nuestra arquitectura de seguridad se basa en este artículo . La idea principal es que no es seguro almacenar tokens jwt en el almacenamiento local y debemos aprovechar las cookies para esto. La api establecerá dos cookies después de una solicitud exitosa para / Iniciar sesión

  • Una cookie solo http, que contiene el token jwt. Esta cookie se pasará en la siguiente solicitud solo al dominio de la API.
    • Un token de XSRF. Este es un token aleatorio que no es solo http, pero está configurado para el dominio spa.com. Solo se puede acceder a esta cookie desde javascript que se ejecuta en spa.com. Esta es una protección contra XSRF, porque cada solicitud, que se envía desde el SPA, contendrá este token en el encabezado de la solicitud.

No soy un experto en seguridad, pero basándome en la lectura de un material de stormpath y otros, creo que esta es una arquitectura de seguridad decente para la aplicación web.

Segundo escenario, aplicación móvil.

Como dije, la API comprueba dos tokens para autorizar a un usuario. Imaginemos que hay un tercer punto final en api.com:

  • / TokenMobile - > este punto final obtendrá las credenciales que envía una aplicación móvil.

Como todos sabemos, las aplicaciones móviles no son seguras. Se pueden descompilar. SSL puede ser evitado. Un pirata informático, con tiempo y conocimientos suficientes, podría descubrir cómo estoy haciendo todas mis solicitudes y cómo estoy autorizando a un usuario. Este pirata informático podría crear un sitio web improvisado que se parece a nuestra aplicación y utilizar los puntos finales móviles para iniciar sesión en el usuario. Por supuesto, esto puede ser posible con algo de ingeniería social.

Así que mis preguntas: ¿Me estoy perdiendo de algo? ¿Puedo proteger a mis usuarios de la suplantación de servicios? ¿Soy paranoico? ¿Es este caso de uso realmente un problema de seguridad?

    
pregunta Alex Maie 15.01.2016 - 15:04
fuente

0 respuestas

Lea otras preguntas en las etiquetas