Si j'utilise simplement l'authentification basée sur le nom d'utilisateur / mot de passe, ils ne seront pas assez sûrs?
Non, car vous identifiez uniquement l' OMS qui accède au serveur API, mais pas le QUOI y accède.
La différence entre QUI et QUOI accède au serveur API
Pour mieux comprendre les différences entre l' OMS et le WHAT accèdent à un serveur API, utilisons cette image:
Le canal de communication prévu représente l'application mobile utilisée comme prévu, par un utilisateur légitime sans aucune intention malveillante, utilisant une version non testée de l'application mobile et communiquant directement avec le serveur API sans être attaqué par l'homme du milieu.
Le canal réel peut représenter plusieurs scénarios différents, comme un utilisateur légitime avec des intentions malveillantes qui peut utiliser une version reconditionnée de l'application mobile, un pirate informatique utilisant la version authentique de l'application mobile, tandis qu'un homme au milieu l'attaque, pour comprendre comment la communication entre l'application mobile et le serveur d'API se fait afin de pouvoir automatiser les attaques contre votre API. De nombreux autres scénarios sont possibles, mais nous ne les énumérerons pas ici.
J'espère que vous savez peut-être déjà pourquoi l' OMS et le QUOI ne sont pas les mêmes, mais sinon, cela deviendra clair dans un instant.
L' OMS est l'utilisateur de l'application mobile que nous pouvons authentifier, autoriser et identifier de plusieurs manières, comme en utilisant les flux OpenID Connect ou OAUTH2.
OAUTH
Généralement, OAuth fournit aux clients un «accès délégué sécurisé» aux ressources du serveur pour le compte d'un propriétaire de ressource. Il spécifie un processus permettant aux propriétaires de ressources d'autoriser l'accès de tiers à leurs ressources de serveur sans partager leurs informations d'identification. Conçu spécifiquement pour fonctionner avec le protocole HTTP (Hypertext Transfer Protocol), OAuth permet essentiellement d'émettre des jetons d'accès à des clients tiers par un serveur d'autorisation, avec l'approbation du propriétaire de la ressource. Le tiers utilise ensuite le jeton d'accès pour accéder aux ressources protégées hébergées par le serveur de ressources.
OpenID Connect
OpenID Connect 1.0 est une simple couche d'identité au-dessus du protocole OAuth 2.0. Il permet aux clients de vérifier l'identité de l'utilisateur final sur la base de l'authentification effectuée par un serveur d'autorisation, ainsi que d'obtenir des informations de profil de base sur l'utilisateur final d'une manière interopérable et similaire à REST.
Bien que l'authentification de l'utilisateur puisse informer le serveur API que l' OMS utilise l'API, elle ne peut garantir que les demandes proviennent de CE QUE vous attendez, la version d'origine de l'application mobile.
Maintenant , nous devons trouver un moyen d'identifier QU'EST - CE appelle le serveur API, et ici les choses deviennent plus difficiles que la plupart des développeurs peuvent penser. Le WHAT est la chose qui fait la demande au serveur API. Est-ce vraiment une véritable instance de l'application mobile, ou est-ce qu'un bot, un script automatisé ou un attaquant fouille manuellement avec le serveur API, en utilisant un outil comme Postman?
Pour votre surprise, vous pouvez finir par découvrir qu'il peut s'agir de l'un des utilisateurs légitimes utilisant une version reconditionnée de l'application mobile ou un script automatisé qui tente de gamifier et de profiter du service fourni par l'application.
Eh bien, pour identifier le QUOI , les développeurs ont tendance à recourir à une clé API qu'ils codent généralement en dur dans le code de leur application mobile. Certains développeurs font un effort supplémentaire et calculent la clé au moment de l'exécution dans l'application mobile, elle devient donc un secret d'exécution par opposition à l'ancienne approche lorsqu'un secret statique est intégré dans le code.
La description ci-dessus a été extraite d'un article que j'ai écrit, intitulé POURQUOI VOTRE APPLICATION MOBILE A-T-ELLE BESOIN D'UNE CLÉ API? , et que vous pouvez lire en entier ici , c'est le premier article d'une série d'articles sur les clés API.
Stockage des données sensibles dans l'appareil client
Et je ne peux pas enregistrer ce nom d'utilisateur / mot de passe dans l'appareil pour des raisons de sécurité bien sûr? Dois-je émettre un GUID pour chaque utilisateur lors de l'inscription, l'enregistrer sur son appareil et le récupérer à chaque fois lors d'une demande d'API?
Tout ce que vous enregistrez dans l'appareil, même crypté, peut être rétro-conçu pendant l'exécution avec des outils tels que Frida ou Xposed.
Frida
Injectez vos propres scripts dans des processus de boîte noire. Accrochez n'importe quelle fonction, espionnez les API cryptographiques ou tracez le code d'application privée, aucun code source n'est nécessaire. Modifiez, appuyez sur Enregistrer et voyez instantanément les résultats. Le tout sans étapes de compilation ni redémarrage du programme.
xPosé
Xposed est un cadre pour les modules qui peuvent changer le comportement du système et des applications sans toucher aux APK. C'est génial car cela signifie que les modules peuvent fonctionner pour différentes versions et même des ROM sans aucun changement (tant que le code d'origine
Dans un appareil que l'attaquant contrôle, il peut également utiliser un proxy pour effectuer une attaque de l'homme au milieu afin d'extraire tout secret que vous pouvez utiliser pour identifier le QUOI ou l' OMS comme je le montre dans l'article Voler cette clé API avec un homme dans l'attaque :
Bien que nous puissions utiliser des techniques avancées, telles que JNI / NDK, pour masquer la clé API dans le code de l'application mobile, cela n'empêchera pas quelqu'un d'effectuer une attaque MitM afin de voler la clé API. En fait, une attaque MitM est facile au point qu'elle peut même être réalisée par des non-développeurs.
Alors maintenant que ... Suis-je condamné au point de ne pas pouvoir protéger mon serveur API contre les abus ??? Pas de calme donc ... l'espoir existe toujours !!!
Solutions possibles
Quelqu'un peut-il me dire quelle méthode les applications Android célèbres comme Facebook, FourSquare ou Twitter utilisent pour authentifier chaque demande provenant de leur application mobile sur leur serveur?
Désolé mais je n'ai pas assez de connaissances sur ces applications pour pouvoir vous élucider, mais je peux vous indiquer d'autres approches.
Quels autres modèles sont disponibles et lesquels sont les plus efficaces et sécurisés, j'ai juste besoin d'un flux de processus pour cela.
Ainsi, tout ce qui fonctionne du côté client et a besoin d'un secret pour accéder à une API peut être abusé de différentes manières et vous pouvez en savoir plus sur cette série d'articles sur les techniques de sécurité des API mobiles. Cet article vous apprendra comment les clés API, les jetons d'accès utilisateur, l'épinglage HMAC et TLS peuvent être utilisés pour protéger l'API et comment ils peuvent être contournés.
Pour résoudre le problème de QUOI accède à votre application mobile, vous devez utiliser une ou toutes les solutions mentionnées dans la série d'articles sur les techniques de sécurité des API mobiles que j'ai mentionnées ci-dessus et accepté qu'elles ne peuvent que rendre plus difficile l'accès non autorisé à votre serveur API. bypass mais pas impossible.
Une meilleure solution peut être utilisée en utilisant une solution d'attestation d'application mobile qui permettra au serveur d'API de savoir qu'il ne reçoit que les demandes d'une véritable application mobile.
Attestation d'application mobile
L'utilisation d'une solution d'attestation d'application mobile permettra au serveur API de savoir QUOI envoie les demandes, permettant ainsi de ne répondre qu'aux demandes d'une véritable application mobile tout en rejetant toutes les autres demandes provenant de sources non sécurisées.
Le rôle d'une solution d'attestation d'application mobile est de garantir au moment de l'exécution que votre application mobile n'a pas été falsifiée, qu'elle ne s'exécute pas dans un appareil enraciné, qu'elle n'est pas instrumentée par un framework comme xPosed ou Frida, qu'elle n'est pas attaquée par MitM, et ce est réalisé en exécutant un SDK en arrière-plan. Le service qui s'exécute dans le cloud mettra l'application au défi et, en fonction des réponses, il attestera l'intégrité de l'application mobile et de l'appareil sur lequel s'exécute, le SDK ne sera donc jamais responsable des décisions.
En cas d'attestation réussie de l'intégrité de l'application mobile, un jeton JWT de courte durée est émis et signé avec un secret que seuls le serveur d'API et le service d'attestation d'application mobile dans le cloud connaissent. En cas d'échec de l'attestation d'application mobile, le jeton JWT est signé avec un secret que le serveur API ne connaît pas.
Maintenant, l'application doit envoyer avec chaque appel API le jeton JWT dans les en-têtes de la demande. Cela permettra au serveur API de ne traiter les demandes que lorsqu'il peut vérifier la signature et l'heure d'expiration dans le jeton JWT et de les refuser en cas d'échec de la vérification.
Une fois que le secret utilisé par le service d'attestation d'application mobile n'est pas connu par l'application mobile, il n'est pas possible de le désosser au moment de l'exécution, même lorsque l'application est falsifiée, s'exécute dans un appareil enraciné ou communique via une connexion qui est le cible d'un homme au milieu de l'attaque.
Le service d'attestation d'application mobile existe déjà en tant que solution SAAS chez Approov (je travaille ici) qui fournit des SDK pour plusieurs plates-formes, notamment iOS, Android, React Native et autres. L'intégration nécessitera également une petite vérification du code du serveur API pour vérifier le jeton JWT émis par le service cloud. Cette vérification est nécessaire pour que le serveur d'API puisse décider des demandes à traiter et de celles à refuser.
Conclusion
Au final, la solution à utiliser pour protéger votre serveur API doit être choisie en fonction de la valeur de ce que vous essayez de protéger et des exigences légales pour ce type de données, comme la réglementation GDPR en Europe.
VOULEZ-VOUS ALLER EXTRA MILE?
Projet de sécurité mobile OWASP - Top 10 des risques
Le projet OWASP Mobile Security est une ressource centralisée destinée à donner aux développeurs et aux équipes de sécurité les ressources dont ils ont besoin pour créer et maintenir des applications mobiles sécurisées. À travers le projet, notre objectif est de classer les risques de sécurité mobile et de fournir des contrôles de développement pour réduire leur impact ou leur probabilité d'exploitation.
