Si solo uso la autenticación basada en nombre de usuario / contraseña, ¿no serán lo suficientemente seguros?
No, porque solo identifica el QUIÉN está accediendo al servidor API, pero no el QUÉ está accediendo a él.
La diferencia entre QUIÉN y QUÉ es acceder al servidor API
Para comprender mejor las diferencias entre la OMS y la QUÉ están accediendo a un servidor API, usemos esta imagen:
El canal de comunicación previsto representa la aplicación móvil utilizada como usted esperaba, por un usuario legítimo sin intenciones maliciosas, utilizando una versión sin manipular de la aplicación móvil y comunicándose directamente con el servidor API sin ser atacado por un intermediario.
El canal real puede representar varios escenarios diferentes, como un usuario legítimo con intenciones maliciosas que puede estar usando una versión reempaquetada de la aplicación móvil, un pirata informático que usa la versión genuina de la aplicación móvil, mientras que un hombre en el medio la ataca, para entender cómo la comunicación entre la aplicación móvil y el servidor de API se realiza para poder automatizar los ataques contra su API. Son posibles muchos otros escenarios, pero no enumeraremos cada uno aquí.
Espero que a estas alturas ya tenga una idea de por qué el QUIÉN y el QUÉ no son lo mismo, pero si no, se aclarará en un momento.
La OMS es el usuario de la aplicación móvil que podemos autenticar, autorizar e identificar de varias formas, como mediante OpenID Connect u OAUTH2.
OAUTH
Generalmente, OAuth proporciona a los clientes un "acceso delegado seguro" a los recursos del servidor en nombre del propietario del recurso. Especifica un proceso para que los propietarios de recursos autoricen el acceso de terceros a los recursos de su servidor sin compartir sus credenciales. Diseñado específicamente para trabajar con el Protocolo de transferencia de hipertexto (HTTP), OAuth esencialmente permite que un servidor de autorización emita tokens de acceso a clientes de terceros, con la aprobación del propietario del recurso. Luego, el tercero usa el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos.
Conexión OpenID
OpenID Connect 1.0 es una capa de identidad simple sobre el protocolo OAuth 2.0. Permite a los Clientes verificar la identidad del Usuario Final basándose en la autenticación realizada por un Servidor de Autorización, así como obtener información de perfil básica sobre el Usuario Final de una manera interoperable y similar a REST.
Si bien la autenticación de usuario puede permitir que el servidor de API sepa QUIÉN está usando la API, no puede garantizar que las solicitudes se hayan originado en LO que espera, la versión original de la aplicación móvil.
Ahora necesitamos una forma de identificar QUÉ está llamando al servidor API, y aquí las cosas se vuelven más complicadas de lo que la mayoría de los desarrolladores pueden pensar. El QUÉ es lo que hace la solicitud al servidor API. ¿Es realmente una instancia genuina de la aplicación móvil, o es un bot, un script automatizado o un atacante que hurga manualmente en el servidor API, utilizando una herramienta como Postman?
Para su sorpresa, puede terminar descubriendo que puede ser uno de los usuarios legítimos que usa una versión reempaquetada de la aplicación móvil o un script automatizado que está tratando de gamificar y aprovechar el servicio proporcionado por la aplicación.
Bueno, para identificar el QUÉ , los desarrolladores tienden a recurrir a una clave de API que generalmente codifican en el código de su aplicación móvil. Algunos desarrolladores hacen un esfuerzo adicional y calculan la clave en tiempo de ejecución en la aplicación móvil, por lo que se convierte en un secreto en tiempo de ejecución a diferencia del enfoque anterior cuando se incrusta un secreto estático en el código.
El artículo anterior se extrajo de un artículo que escribí, titulado ¿POR QUÉ SU APLICACIÓN MÓVIL NECESITA UNA CLAVE API? , y que puede leer en su totalidad aquí , ese es el primer artículo de una serie de artículos sobre claves API.
Almacenamiento de datos confidenciales en el dispositivo cliente
¿Y no puedo guardar ese nombre de usuario / contraseña en el dispositivo, por supuesto, por razones de seguridad? ¿Debería emitir un GUID para cada usuario en el registro, guardarlo en su dispositivo y recuperarlo cada vez que se realiza una solicitud de API?
Todo lo que guarde en el dispositivo, incluso si está cifrado, se puede realizar ingeniería inversa durante el tiempo de ejecución con herramientas como Frida o Xposed.
Frida
Inyecte sus propios scripts en procesos de caja negra. Enganche cualquier función, espíe las API de cifrado o rastree el código de la aplicación privada, sin necesidad de código fuente. Edite, presione guardar y vea los resultados al instante. Todo sin pasos de compilación ni reinicios del programa.
xPosed
Xposed es un marco para módulos que puede cambiar el comportamiento del sistema y las aplicaciones sin tocar ningún APK. Eso es genial porque significa que los módulos pueden funcionar para diferentes versiones e incluso ROM sin ningún cambio (siempre que el código original
En un dispositivo que controla el atacante, también puede usar un proxy para realizar un Ataque de hombre en el medio para extraer cualquier secreto que pueda usar para identificar el QUÉ o el QUIÉN, como muestro en el artículo Robar esa clave API con un hombre en el ataque. :
Si bien podemos utilizar técnicas avanzadas, como JNI / NDK, para ocultar la clave API en el código de la aplicación móvil, no impedirá que alguien realice un ataque MitM para robar la clave API. De hecho, un ataque MitM es fácil hasta el punto de que incluso los no desarrolladores pueden lograrlo.
Entonces, ¿ahora qué ... ¿Estoy condenado al punto en que no puedo proteger mi servidor API de ser abusado? No hay silencio así que ... ¡¡¡la esperanza todavía existe !!!
Soluciones posibles
¿Alguien puede decirme qué método usan las aplicaciones de Android famosas como Facebook, FourSquare o Twitter para autenticar cada solicitud proveniente de su aplicación móvil en su servidor?
Lo siento, pero no tengo suficiente conocimiento sobre estas aplicaciones para poder dilucidarlo, pero puedo señalarle algunos otros enfoques.
Qué otros patrones están disponibles y cuáles son los más eficientes y seguros, solo necesito un flujo de proceso para ello.
Entonces, cualquier cosa que se ejecute en el lado del cliente y necesite algún secreto para acceder a una API se puede abusar de diferentes maneras y puede obtener más información en esta serie de artículos sobre Técnicas de seguridad de API móviles. Estos artículos le enseñarán cómo las claves de API, los tokens de acceso de usuario, HMAC y TLS Pinning se pueden utilizar para proteger la API y cómo se pueden omitir.
Para resolver el problema de QUÉ es acceder a su aplicación móvil, debe utilizar una o todas las soluciones mencionadas en la serie de artículos sobre Técnicas de seguridad de API móviles que mencioné anteriormente y acepté que solo pueden dificultar el acceso no autorizado a su servidor de API. bypass pero no imposible.
Se puede emplear una mejor solución mediante el uso de una solución de atestación de aplicaciones móviles que permitirá que el servidor API sepa que solo recibe solicitudes de una aplicación móvil genuina.
Certificación de aplicación móvil
El uso de una solución de atestación de aplicaciones móviles permitirá que el servidor de API sepa QUÉ está enviando las solicitudes, lo que permitirá responder solo a las solicitudes de una aplicación móvil genuina y rechazar todas las demás solicitudes de fuentes inseguras.
El papel de una solución de atestación de aplicaciones móviles es garantizar en tiempo de ejecución que su aplicación móvil no fue manipulada, no se está ejecutando en un dispositivo rooteado, no está instrumentada por un marco como xPosed o Frida, no está siendo atacada por MitM, y esto se logra ejecutando un SDK en segundo plano. El servicio que se ejecuta en la nube desafiará a la aplicación y, según las respuestas, atestiguará la integridad de la aplicación móvil y el dispositivo en el que se está ejecutando, por lo que el SDK nunca será responsable de ninguna decisión.
Tras la certificación exitosa de la integridad de la aplicación móvil, se emite un token JWT de corta duración y se firma con un secreto que solo el servidor API y el servicio de certificación de la aplicación móvil en la nube conocen. En caso de falla en la certificación de la aplicación móvil, el token JWT se firma con un secreto que el servidor API no conoce.
Ahora, la aplicación debe enviar con cada llamada a la API el token JWT en los encabezados de la solicitud. Esto permitirá que el servidor de API solo atienda solicitudes cuando pueda verificar la firma y el tiempo de vencimiento en el token JWT y rechazarlas cuando falle la verificación.
Una vez que la aplicación móvil no conoce el secreto utilizado por el servicio de certificación de la aplicación móvil, no es posible realizar ingeniería inversa en el tiempo de ejecución, incluso cuando la aplicación está alterada, ejecutándose en un dispositivo rooteado o comunicándose a través de una conexión que está siendo la objetivo de un ataque de Hombre en el Medio.
El servicio de atestación de aplicaciones móviles ya existe como una solución SAAS en Approov (trabajo aquí) que proporciona SDK para varias plataformas, incluidas iOS, Android, React Native y otras. La integración también necesitará una pequeña verificación en el código del servidor API para verificar el token JWT emitido por el servicio en la nube. Esta verificación es necesaria para que el servidor API pueda decidir qué solicitudes atender y cuáles rechazar.
Conclusión
Al final, la solución a utilizar para proteger su servidor API debe elegirse de acuerdo con el valor de lo que está tratando de proteger y los requisitos legales para ese tipo de datos, como las regulaciones GDPR en Europa.
¿QUIERES HACER UNA MILLA EXTRA?
Proyecto de seguridad móvil OWASP: los 10 riesgos principales
El Proyecto de seguridad móvil de OWASP es un recurso centralizado destinado a brindar a los desarrolladores y equipos de seguridad los recursos que necesitan para crear y mantener aplicaciones móviles seguras. A través del proyecto, nuestro objetivo es clasificar los riesgos de seguridad móvil y proporcionar controles de desarrollo para reducir su impacto o probabilidad de explotación.
