Comment les applications populaires authentifient-elles les demandes des utilisateurs de leur application mobile sur leur serveur?
Disons que j’ai une application Android qui se connecte à une API .Net pour la réception/la configuration des données. La confusion que j’ai concerne la façon d’inscrire/connecter l’utilisateur pour la première fois et de l’authentifier à chaque temps ils font une demande à l'API.
- Si je viens d'utiliser une authentification basée sur un nom d'utilisateur/mot de passe, ils ne seront pas assez sûrs?
- 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?
- Devrais-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?
Quels sont les autres modèles disponibles et ceux qui sont les plus efficaces et sécurisés? J'ai juste besoin d'un flux de processus pour cela. Quelqu'un peut-il me dire quelle méthode Android telles que Facebook, FourSquare ou Twitter utilisent pour authentifier toutes les demandes provenant de leur application mobile sur leur serveur?
Désolé d'avance si ce n'est pas une information publique.
J'imagine qu'ils utilisent un système de sécurité basé sur un "jeton", de sorte que le mot de passe n'est en réalité jamais stocké nulle part, mais simplement utilisé la première fois pour s'authentifier. Ainsi, l’application affiche initialement le nom d’utilisateur/mot de passe (via ssl) et le serveur renvoie un jeton que l’application stocke. Pour les tentatives de synchronisation suivantes, le jeton est envoyé en premier, le serveur vérifie sa validité, puis autorise la publication d'autres données.
Le jeton doit avoir une date d'expiration pour que le serveur puisse demander à nouveau une tentative d'authentification.
Si vous vous connectez à l’adaptateur de synchronisation à partir du cadre Android), vous aurez la possibilité de tout synchroniser et de vous authentifier.
http://developer.Android.com/training/sync-adapters/creating-sync-adapter.html
Si vous vérifiez les comptes sous Paramètres sur votre appareil, vous verrez ce que je veux dire.
Fondamentalement, ces célèbres utilisent OAuth protocole (1)/framework (2). Même s'il doit s'agir d'un standard, chacun d'entre eux avait des implémentations différentes de ce protocole/framework. Nous devons donc être très prudent en matière d'intégration.
Exemple: Dropbox utilise toujours OAuth 1 et a récemment fourni le support OAuth 2.
De retour à la réponse, comme l'a dit peterpan, il s'agit d'une méthode d'authentification basée sur des jetons. Une fois et l'équation sont exclues. Ces jetons sont expirés ou le développeur dispose parfois du pouvoir.
La chose intéressante derrière cela est que la portée de l'accès aux ressources peut être définie plutôt que de permettre à l'application cliente de conserver les noms d'utilisateur, mots de passe dangereux.
Ceci est l'illustration de base de la façon dont cela fonctionne.
Je mettrai à jour la réponse après avoir obtenu plus de détails à ce sujet, car je travaille dans ce domaine ces jours-ci :)
Je cherchais exactement la même chose et trouvais google, comme l'a dit peterpan, mais via les API Google. Essayez ce lien et recherchez votre chemin sur Google, je commence aussi! Je posterai de nouvelles informations tant que j'y serai!
Je suis novice, mais je vais essayer de donner une solution logique à la question donnée.
Il y aura deux options, [1] Pour chaque URI, une authentification http sera effectuée là où les informations d'identification entrées par l'utilisateur seront vérifiées et où l'utilisateur devra accéder aux ressources.
[2] Une autre approche pourrait consister à authentifier un utilisateur et à générer à chaque authentification un jeton unique. À l'aide du jeton généré, l'utilisateur doit accéder aux ressources.
Bien que je ne sache pas quelle approche conviendrait le mieux pour une application mobile.
Exemple d’authentification est un bon point de départ. Android stocke les informations d'identification dans le gestionnaire de compte, vous pouvez afficher les comptes dans les paramètres d'Android. Cela stockera automatiquement les jetons, demandera à l'utilisateur des informations d'identification si expiré ou manquant, actualise les jetons, etc. Je trouve la partie http L’extension de AccountAuthenticatorActivity d’Android est une aide précieuse pour l’analyse de données sérialisées dans la présentation et le retour sur Internet.
Si je viens d'utiliser une authentification basée sur un nom d'utilisateur/mot de passe, ils ne seront pas assez sûrs?
Non, car vous identifiez uniquement le [~ # ~] qui [~ # ~] accède au serveur de l'API, mais pas le [~ # ~] ce que [~ # ~] y accède.
La différence entre WHO et WHAT consiste à accéder au serveur API
Pour mieux comprendre les différences entre le [~ # ~] qui [~ # ~] et le [~ # ~] [~ # ~] accèdent à un serveur API, utilisons cette image:
Le canal de communication prévu représente l'application mobile utilisée comme vous le souhaitez, par un utilisateur légitime, sans aucune intention malveillante, utilisant une version non modifiée de l'application mobile et communiquant directement avec le serveur API sans être attaqué.
Le canal réel peut représenter plusieurs scénarios différents, comme un utilisateur légitime aux intentions malveillantes utilisant éventuellement une version reconditionnée de l'application mobile, un pirate informatique utilisant la version authentique de l'application mobile, tandis que l'homme du milieu l'attaque pour comprendre comment la communication entre l'application mobile et le serveur d'API est en cours 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 qu'à présent, vous aurez peut-être déjà la moindre idée pourquoi le [~ # ~] qui [~ # ~] et le [~ # ~] ce que [~ # ~] ne sont pas identiques, mais si ce n'est pas le cas, cela deviendra clair dans un instant.
Le [~ # ~] qui [~ # ~] est l'utilisateur de l'application mobile que nous pouvons authentifier, autoriser et identifier de plusieurs manières, comme utilisant des flux OpenID Connect ou OAUTH2.
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 ressources. Il définit un processus permettant aux propriétaires de ressources d'autoriser l'accès de tiers à leurs ressources de serveur sans partage. Conçu spécifiquement pour fonctionner avec HTTP (Hypertext Transfer Protocol), OAuth permet essentiellement aux jetons d’accès d’être émis vers 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 1.0 est une couche d’identité simple superposée au protocole OAuth 2.0). Elle permet aux clients de vérifier l’identité de l’utilisateur final en fonction de l’authentification effectuée par un serveur d’autorisations, ainsi que pour obtenir des informations de base sur le profil de l'utilisateur final de manière interopérable et de type REST.
Bien que l’authentification de l’utilisateur permette au serveur de l’API de savoir [~ # ~] qui [~ # ~] utilise l’API, cela ne garantit pas que les requêtes ont provient de [~ # ~] ce que [~ # ~] vous attendez, la version originale de l'application mobile.
Nous avons maintenant besoin d’un moyen d’identifier [~ # ~] ce que [~ # ~] appelle le serveur d’API, et ici les choses deviennent plus délicates que la plupart des autres. les développeurs peuvent penser. Le [~ # ~] que [~ # ~] est la chose qui fait la demande au serveur d'API. S'agit-il vraiment d'une instance authentique de l'application mobile ou s'agit-il d'un robot, d'un script automatisé ou d'un attaquant qui fouille manuellement avec le serveur API, à l'aide d'un outil tel que Postman?
À votre grande surprise, vous pourriez 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 d'un script automatisé qui tente de se jouer et de tirer parti du service fourni par l'application.
Eh bien, pour identifier le [~ # ~] en quoi [~ # ~] , les développeurs ont tendance à recourir à une clé API dans laquelle ils codent habituellement en dur le code de leur application mobile. Certains développeurs vont encore plus loin et calculent la clé au moment de l'exécution dans l'application mobile. Cela devient donc un secret d'exécution, par opposition à l'approche précédente lorsqu'un secret statique est incorporé dans le code.
La description ci-dessus a été extraite d'un article que j'ai écrit et intitulé POURQUOI VOTRE APP MOBILE A-T-ELLE BESOIN D'UNE CLÉ D'API?, et que vous pouvez lire intégralement ici , c'est le premier article d'une série d'articles sur les clés d'API.
Stockage des données sensibles sur le périphérique 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? Devrais-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 le périphérique, même s'il est crypté, peut être soumis à une ingénierie inverse au cours de l'exécution à l'aide d'outils tels que Frida ou Xposed.
Injectez vos propres scripts dans les processus de la boîte noire. Accrochez n'importe quelle fonction, espionnez les API de chiffrement ou tracez le code d'une application privée, aucun code source n'est nécessaire. Modifier, cliquez sur Enregistrer et voyez instantanément les résultats. Le tout sans étapes de compilation ni redémarrage du programme.
Xposed est un framework de modules permettant de modifier le comportement du système et des applications sans toucher les fichiers APK. C’est génial car cela signifie que les modules peuvent fonctionner pour différentes versions et même des ROM sans aucune modification (tant que le code original est utilisé).
Dans un appareil que l’attaquant contrôle, il peut également utiliser un proxy pour effectuer une attaque en homme au milieu afin d’extraire tout secret permettant d’identifier le [~ # ~] que [~ # ~] ou le [~ # ~] qui [~ # ~] 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é d'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é d'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 quoi ... Suis-je condamné au point que je ne peux pas protéger mon serveur API contre les abus ??? Pas de calme alors ... l'espoir existe toujours !!!
Solutions possibles
Quelqu'un peut-il me dire quelle méthode Android) applications telles que Facebook, FourSquare ou Twitter utilisent pour authentifier toutes les demandes provenant de leur application mobile sur leur serveur?
Désolé, mais je ne connais pas suffisamment cette application pour pouvoir vous élucider, mais je peux vous indiquer d'autres approches.
Quels sont les autres modèles disponibles et ceux qui sont les plus efficaces et les plus sûrs? Il me faut simplement un flux de processus pour cela.
Ainsi, tout ce qui fonctionne côté client et nécessite un secret pour accéder à une API peut être utilisé de différentes manières et vous pouvez en apprendre plus sur cette série d'articles sur les techniques de sécurité des API mobiles. Ces articles vous apprendront comment utiliser les clés d'API, les jetons d'accès utilisateur, HMAC et TLS Pinning pour protéger l'API et comment les contourner.
Pour résoudre le problème de [~ # ~] à quoi [~ # ~] accède à votre application mobile, vous devez utiliser l'une ou toutes les solutions mentionnées dans la série d'articles sur les techniques de sécurité de l'API mobile que j'ai mentionnées ci-dessus et acceptait qu'ils ne pouvaient que rendre l'accès non autorisé à votre serveur d'API plus difficile à contourner, 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 application mobile authentique.
Attestation d'application mobile
L’utilisation d’une solution Mobile App Attestation permettra au serveur d’API de savoir [~ # ~] quel [~ # ~] envoie les demandes, donc permettant de répondre uniquement aux demandes d'une application mobile authentique 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 cadre tel que xPosed ou Frida, qu'elle n'a pas été attaquée par MitM et que est obtenu en exécutant un SDK en arrière-plan. Le service exécuté dans le cloud conteste l'application et, en fonction des réponses fournies, attestera de l'intégrité de l'application mobile et du périphérique en cours d'exécution. Le SDK ne sera donc jamais responsable de la décision.
En cas d'attestation de l'intégrité de l'application mobile, un jeton JWT à vie courte est émis et signé avec le secret que seuls le serveur d'API et le service Attestation d'application mobile du cloud sont conscients. En cas d'échec sur l'attestation de l'application mobile, le jeton JWT est signé avec un secret que le serveur d'API ne sait pas.
Maintenant, l'application doit envoyer avec chaque API le jeton JWT dans les en-têtes de la demande. Cela permettra au serveur d'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 Attestation d’application mobile n’est pas connu par l’application mobile, il n’est plus possible de l’ingénierie inverse au moment de l’exécution, même si l’application est falsifiée, s'exécute sur un appareil root ou communique via une connexion en cours. cible d'un homme dans l'attaque du milieu.
Le service Attestation d’application mobile existe déjà sous forme de solution SAAS chez Approov (je travaille ici), qui fournit des kits de développement logiciel (SDK) pour plusieurs plates-formes, notamment iOS, Android, React Native et d’autres. L’intégration nécessite également une petite vérification dans le code du serveur d'API pour vérifier le jeton JWT émis par le service de cloud Cette vérification est nécessaire pour que le serveur d'API puisse décider des demandes à servir et de celles à refuser.
Conclusion
En fin de compte, 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 les réglementations GDPR en Europe.
VOULEZ-VOUS ALLER EXTRA MILE?
Projet OWASP Mobile Security - Top 10 des risques
Le projet OWASP Mobile Security est une ressource centralisée destinée à fournir aux développeurs et aux équipes de sécurité les ressources dont ils ont besoin pour créer et gérer des applications mobiles sécurisées. Dans le cadre de ce projet, notre objectif est de classer les risques liés à la sécurité des mobiles et de mettre en place des contrôles de développement permettant de réduire leur impact ou leur probabilité d’exploitation.