2012-03-22 6 views
17

Estamos desarrollando una aplicación móvil y queremos implementar algún tipo de autenticación para asegurarnos de que nuestra aplicación solo acceda a la API. Los usuarios de la aplicación son anónimos, sin inicios de sesión, aunque sí los identifico a través de la identificación del dispositivo para mantener la configuración y demás.¿Cómo asegurarnos de que las solicitudes de API provengan de nuestra aplicación móvil (ios/android)?

El enfoque más fácil parece ser la generación de una clave Guid/API que envío con cada solicitud a través de SSL.

Lo que me preocupa es la posibilidad de que una persona malintencionada con mucho tiempo libre descargue la aplicación, la descompile para obtener la clave API y las solicitudes JSON, y luego destruya mi base de datos lo mejor que pueda.

¿Es suficiente SSL, una clave de API, una identificación de dispositivo y una API con llamadas lo más limitadas posible? ¿Debo tomar un enfoque diferente? ¿Mis miedos están fundados o son infundados?

Respuesta

18

NO incruste una sola clave de API en la aplicación. Sus preocupaciones son válidas con respecto al efecto de los usuarios maliciosos. Además, tiene una vulnerabilidad grave en su configuración actual en la que podría hacer que un usuario API malintencionado cambie las preferencias de otros usuarios al proporcionar UDID falsos.

En su lugar, cree un servicio de "registro" que se llama al inicio de la aplicación por primera vez en el dispositivo que genera y devuelve un GUID basado en el UDID. Almacene el GUID en las preferencias de usuario local de su dispositivo y en el servidor. Mantenga un registro del GUID y compárelo con el UDID en cada solicitud en su servidor.

Asegúrese de que todo esto ocurra a través de SSL.

Con este enfoque, no se debe abusar de ninguna clave maestra API integrada. Además, puede poner en la lista negra a los usuarios abusivos marcando las combinaciones de GUID/UDID y también puede eliminar su problema existente de posible enmascaramiento de los dispositivos registrados existentes. Sin embargo, no puede evitar el registro malicioso de dispositivos que aún no se hayan registrado con su servicio. Ese siempre será un riesgo potencial de usar una identificación de dispositivo como un identificador de usuario.

Existen mecanismos de autenticación aún mejores y más establecidos que adoptan un mejor enfoque, es decir. OAuth, JSessionIDs, etc. que deberías ver.

Además, en el futuro no deberías estar usando el UDID para identificar a tus usuarios, ya que el acceso al mismo ha quedado obsoleto. Puede mimetizar el UDID para sus propósitos creando un GUID de dispositivo personalizado en el dispositivo al momento de la instalación de la aplicación y guardándolo en sus preferencias de usuario local.

+0

No entiendo cómo esto hace que algo sea más seguro. El punto de vulnerabilidad solo es diferente en su caso: el servicio de registro. Puedo atacar eso y también tengo acceso completo. Creo que para Android, al menos, es posible hacer algo como esto: http://android-developers.blogspot.de/2013/01/verifying-back-end-calls-from-android.html – therealmarv

+0

¿Cómo atacarías el servicio de registro para obtener acceso completo? –

Cuestiones relacionadas