Uso no seguro de la API

Categoría de OWASP: MASVS-PLATFORM: Interacción con la plataforma

Descripción general

Muchas aplicaciones para dispositivos móviles usan una API externa para proporcionar funciones. Tradicionalmente, se usa un token o una clave estáticos para autenticar la aplicación que se conecta al servicio.

Sin embargo, en el contexto de una configuración cliente-servidor (o una app para dispositivos móviles y una API), usar una clave estática no se considera un método de autenticación seguro para acceder a datos o servicios sensibles. A diferencia de la infraestructura interna, cualquier persona puede acceder a una API externa y abusar del servicio si tiene acceso a esta clave.

Por ejemplo, es posible que una clave estática se someta a ingeniería inversa desde la aplicación o se intercepte cuando una aplicación para dispositivos móviles se comunica con la API externa. También es más probable que esta clave estática esté codificada de forma rígida dentro de la aplicación.

El riesgo para los datos y los servicios de la API se produce cuando no se usan controles de acceso y autenticación suficientemente seguros.

Cuando se usa una clave estática, se puede aprovechar la API repitiendo solicitudes o creando solicitudes nuevas con la clave (interceptada o sometida a ingeniería inversa) sin restricciones de tiempo.

Impacto

Si un desarrollador paga por un servicio de API de IA o AA, sería relativamente fácil para un atacante robar esta clave y generar deuda en su servicio o usarla para crear contenido falso.

Cualquier dato del usuario, archivo o PII almacenado en la API estaría disponible libremente, lo que provocaría filtraciones perjudiciales.

Un atacante también podría usar este acceso para cometer fraude, redireccionar servicios y, en casos excepcionales, obtener el control total de los servidores.

Mitigaciones

API con estado

Si la aplicación proporciona un acceso del usuario o tiene la capacidad de hacer un seguimiento de las sesiones del usuario, recomendamos a los desarrolladores que utilicen un servicio de API como Google Cloud para la integración con estado en su app.

Además, usa la autenticación segura, la validación del cliente y los controles de sesión que proporciona el servicio de API, y considera usar un token dinámico como alternativa a una clave estática. Asegúrate de que el token venza en un período razonablemente corto (1 hora es lo habitual).

Luego, se debe usar el token dinámico para la autenticación y, así, proporcionar acceso a la API. En estas instrucciones, se muestra cómo lograr esto con OAuth 2.0. Además de esos lineamientos, OAuth 2.0 se puede fortalecer aún más para reducir las vulnerabilidades en tu app para Android implementando las siguientes funciones.

Implementa un registro y un manejo de errores adecuados:

  • Maneja los errores de OAuth de forma correcta y visible, y regístralos para depuración.
    • Una superficie de ataque reducida también te ayudará a identificar y solucionar cualquier problema que pueda surgir.
    • Asegúrate de que los mensajes registrados o presentados al usuario sean claros, pero no contengan información útil para un adversario.

Configura OAuth de forma segura en la aplicación:

  • Envía el parámetro redirect_uri a los extremos de autorización y de token.
  • Si tu app usa OAuth con un servicio de terceros, configura el uso compartido de recursos entre dominios (CORS) para restringir el acceso a los recursos de tu app.
    • Esto ayudará a prevenir ataques no autorizados de secuencias de comandos entre sitios (XSS).
  • Usa el parámetro state para evitar ataques de CSRF.

Usa una biblioteca de seguridad:

  • Considera usar una biblioteca de seguridad como AppAuth para simplificar la implementación de flujos seguros de OAuth.
    • Estas bibliotecas de Android pueden ayudar a automatizar muchas de las prácticas recomendadas de seguridad mencionadas anteriormente.

En la documentación de OpenAPI, se describen otros métodos de autenticación, incluidos los tokens de ID de Firebase y Google.

API sin estado

Si el servicio de API no ofrece ninguna de las protecciones recomendadas anteriormente y se requiere sesiones sin estado sin acceso del usuario, es posible que los desarrolladores deban proporcionar sus propias soluciones de middleware.

Esto implicaría solicitudes de "proxy" entre la app y el extremo de la API. Un método para hacerlo es usar tokens web JSON (JWT) y firmas web JSON (JWS), o bien proporcionar un servicio completamente autenticado, como se recomendó anteriormente. Esto proporciona una forma de almacenar la clave estática vulnerable en el servidor en lugar de en la aplicación (cliente).

Existen problemas inherentes a la provisión de una solución sin estado de extremo a extremo en las aplicaciones para dispositivos móviles. Algunos de los desafíos más importantes son la validación del cliente (app) y el almacenamiento seguro de la clave privada o el secreto en el dispositivo.

La API de Play Integrity proporciona validación de la integridad de la aplicación y las solicitudes. Esto puede mitigar algunas de las situaciones en las que se puede abusar de este acceso. En cuanto a la administración de claves, en muchos casos, el almacén de claves es la mejor ubicación para el almacenamiento seguro de claves privadas.

Algunas aplicaciones para dispositivos móviles usan una fase de registro para verificar la integridad de la aplicación y proporcionar una clave a través de un intercambio seguro. Estos métodos son complejos y están fuera del alcance de este documento. Sin embargo, un servicio de administración de claves en la nube es una posible solución.

Recursos