Utilisation d'API non sécurisées

Catégorie OWASP : MASVS-PLATFORM : interaction avec la plate-forme

Présentation

De nombreuses applications mobiles utilisent une API externe pour fournir des fonctionnalités. Traditionnellement, un jeton ou une clé statique est utilisé pour authentifier l'application qui se connecte au service.

Toutefois, dans le contexte d'un paramètre client-serveur (ou d'une application mobile et d'une API), l'utilisation d'une clé statique n'est généralement pas considérée comme une méthode d'authentification sécurisée pour accéder à des données ou services sensibles. Contrairement à l'infrastructure interne, toute personne ayant accès à cette clé peut accéder à une API externe et abuser du service.

Par exemple, il est possible qu'une clé statique soit rétro-ingéniérée à partir de l'application ou interceptée lorsqu'une application mobile communique avec l'API externe. Il est également plus probable que cette clé statique soit codée en dur dans l'application.

Le risque pour les données et services de l'API se produit lorsque des contrôles d'accès et d'authentification suffisamment sécurisés ne sont pas utilisés.

Lorsqu'une clé statique est utilisée, l'API peut être exploitée en rejouant des requêtes ou en construisant de nouvelles requêtes à l'aide de la clé (interceptée ou rétro-ingéniée) sans aucune restriction de temps.

Impact

Si un développeur paie pour un service d'API d'IA ou de ML, il serait relativement facile pour un pirate informatique de voler cette clé et de s'endetter sur son service ou de l'utiliser pour créer de faux contenus.

Toutes les données utilisateur, tous les fichiers ou toutes les informations permettant d'identifier personnellement l'utilisateur stockés sur l'API seraient librement accessibles, ce qui entraînerait des fuites préjudiciables.

Un pirate informatique peut également utiliser cet accès pour commettre des fraudes, rediriger des services et, dans de rares cas, prendre le contrôle total des serveurs.

Stratégies d'atténuation

API avec état

Si l'application permet aux utilisateurs de se connecter ou de suivre leurs sessions, nous recommandons aux développeurs d'utiliser un service d'API tel que Google Cloud pour une intégration avec état dans leur application.

De plus, utilisez l'authentification sécurisée, la validation du client et les contrôles de session fournis par le service d'API, et envisagez d'utiliser un jeton dynamique au lieu d'une clé statique. Assurez-vous que le jeton expire dans un délai raisonnablement court (une heure est généralement suffisant).

Le jeton dynamique doit ensuite être utilisé pour l'authentification afin de fournir un accès à l'API. Les consignes suivantes montrent comment y parvenir à l'aide d'OAuth 2.0. En plus de ces consignes, vous pouvez renforcer OAuth 2.0 pour réduire les failles de sécurité dans votre application Android en implémentant les fonctionnalités suivantes.

Implémentez une gestion et une journalisation des erreurs appropriées :

  • Gérez les erreurs OAuth de manière optimale et visible, et consignez-les à des fins de débogage.
    • Une surface d'attaque réduite vous aidera également à identifier et à résoudre les problèmes qui pourraient survenir.
    • Assurez-vous que tous les messages consignés ou présentés à l'utilisateur sont clairs, mais ne contiennent pas d'informations utiles à un adversaire.

Configurez OAuth de manière sécurisée dans l'application :

  • Envoyez le paramètre redirect_uri aux points de terminaison d'autorisation et de jeton.
  • Si votre application utilise OAuth avec un service tiers, configurez le partage de ressources inter-origines (CORS) pour limiter l'accès aux ressources de votre application.
    • Cela permet d'éviter les attaques de script intersites (XSS) non autorisées.
  • Utilisez le paramètre "state" pour éviter les attaques CSRF.

Utilisez une bibliothèque de sécurité :

  • Envisagez d'utiliser une bibliothèque de sécurité comme AppAuth pour simplifier l'implémentation de flux OAuth sécurisés.
    • Ces bibliothèques Android peuvent vous aider à automatiser de nombreuses bonnes pratiques de sécurité mentionnées précédemment.

D'autres méthodes d'authentification, y compris les jetons d'identité Firebase et Google, sont décrites dans la documentation OpenAPI.

API sans état

Si le service d'API n'offre aucune des protections recommandées précédemment et qu'il est nécessaire d'avoir des sessions sans état sans connexion utilisateur, les développeurs devront peut-être fournir leurs propres solutions middleware.

Cela impliquerait de "faire transiter" les requêtes entre l'application et le point de terminaison de l'API. Pour ce faire, vous pouvez utiliser des jetons Web JSON (JWT) et des signatures Web JSON (JWS), ou fournir un service entièrement authentifié, comme recommandé précédemment. Cela permet de stocker la clé statique vulnérable côté serveur plutôt que dans l'application (client).

Il existe des problèmes inhérents à la fourniture d'une solution de bout en bout sans état dans les applications mobiles. La validation du client (application) et le stockage sécurisé de la clé privée ou du secret sur l'appareil font partie des défis les plus importants.

L'API Play Integrity permet de valider l'intégrité de l'application et des requêtes. Cela peut atténuer certains scénarios dans lesquels cet accès peut être utilisé de manière abusive. En ce qui concerne la gestion des clés, le keystore est souvent le meilleur emplacement pour stocker les clés privées de manière sécurisée.

Certaines applications mobiles utilisent une phase d'enregistrement pour vérifier l'intégrité de l'application et fournir une clé à l'aide d'un échange sécurisé. Ces méthodes sont complexes et ne sont pas abordées dans ce document. Toutefois, un service de gestion de clés cloud peut être une solution.

Ressources