Pourquoi les clés API doivent-elles rester privées?
J'ai travaillé avec des API publiques dans un seul petit projet, mais j'ai récemment appris que si l'on devait distribuer un projet avec des clés d'API à l'intérieur, c'est un risque pour la sécurité.
J'ai donc deux questions:
- Que contient une clé API qui poserait un risque pour la sécurité?
- Comment créer une application qui utilise des API publiques et distribuer cette application sans poser de risque pour la sécurité?
Sûrement, si quelqu'un peut inverser l'ingénierie de l'application, il pourrait extraire toutes les clés d'API présentes.
Cela dépend de ce que fait la clé API. Cependant, si la clé API vous donne accès à quelque chose ou contrôle votre accès à quelque chose, pourquoi voudriez-vous que d'autres personnes se superposent aux ressources auxquelles vous avez accès? Tu ne le ferais pas.
Pensez-y de cette façon. Je possède un service et vous en êtes un utilisateur, peut-être même un client payant. Je vous donne une clé API basée sur un niveau de service convenu (peut-être des appels API par unité de temps). Si cette clé d'API était publique, d'autres personnes pourraient l'utiliser pour prétendre être vous et utiliser vos appels d'API limités.
C'est probablement la situation la moins préoccupante. Le partage des clés API devient plus préoccupant si la clé API authentifie quelqu'un pour accéder à un sous-ensemble de données.
Les méthodes de protection des clés API dépendent de la technologie que vous utilisez. Lors du développement d'applications Web ou mobiles, par exemple, vous pouvez aider à protéger vos clés API en vous assurant qu'elles ne se retrouvent pas sur le client (le navigateur Web ou l'appareil mobile). Au lieu de cela, ils peuvent rester sur les serveurs utilisés par le client. Le client peut s'authentifier auprès des services qui peuvent alors effectuer les appels appropriés. Selon l'environnement, les clés API peuvent même être chiffrées car elles sont stockées dans des environnements différents.
Il existe différents types de clés API. Certaines clés API sont conçues pour être rendues publiques, elles sont généralement appelées quelque chose comme des clés publiables et sont conçues pour être envoyées aux utilisateurs dans des pages Web ou des ensembles d'applications. Ce type de clés API n'est pas destiné à l'authentification, mais plutôt à une identification simple. Il y a peu de cas d'utilisation où cela est raisonnable, mais généralement cela peut être bien pour une application à faible sécurité ou si vous avez votre sécurité ailleurs.
Cependant, la plupart des clés API sont un secret d'authentification. La valeur de la ressource qu'elle protège varie. Même si l'API elle-même n'affiche que des données accessibles au public et qu'il n'y a pas de ressources privées, le fournisseur d'API exige parfois que vous utilisiez une clé d'API pour pouvoir appliquer une limitation de débit, le risque pour vous si votre clé d'API a fui et que quelqu'un a utilisé votre API. La clé est que votre demande peut effectivement se voir refuser le service parce que vous avez atteint votre limite désignée. S'il s'agit d'une API payante, vous pourriez encourir des frais inutiles si d'autres utilisaient votre clé API.
D'autres fois, la clé API est conçue comme un jeton pour votre autorisation que la demande soit effectuée par le fournisseur de services. Si vous perdez votre clé API, vous ne contrôlerez plus la ressource protégée car votre utilisateur pourra directement informer le fournisseur d'archives, en contournant la logique métier que vous souhaitez.
Pensez-y de cette façon, la plupart des gens n'ont pas l'habitude de distribuer les clés de leur propriété privée (maison, voitures, etc.). Pourquoi? Parce que ces clés protègent les actifs critiques et empêchent les gens que vous ne connaissez pas de voler des choses. Vous pouvez penser à la clé API comme mot de passe API. Tout ce que votre application est autorisée à faire avec l'API, quelqu'un d'autre peut le faire s'il vole vos informations d'identification.
Le concept n'est pas différent pour les clés numériques, le seul défi est qu'il est plus difficile de les sécuriser ou de manipuler les clés en toute sécurité. Il est également plus courant de fournir des clés distinctes pour chaque client de l'API. Cela permet non seulement d'administrer différents niveaux d'abonnement ou ensembles d'autorisations pour chaque client, mais également des journaux d'audit faisant autorité où le détenteur des clés d'API ne peut pas répudier les actions enregistrées .
Si nous parlons OAuth 2, le mécanisme de contrôle d'accès API le plus courant, alors il y a deux clés à se soucier:
- La clé client: identifie votre application auprès du fournisseur d'API
- La clé secrète: vous authentifie pour que personne ne puisse vous usurper l'identité
La combinaison de clés est critique, c'est pourquoi OAuth oblige TLS à échanger les clés. La clé client en elle-même est moins critique vis-à-vis d'une ressource à protéger, mais ce n'est pas quelque chose que vous devez annoncer. Le la clé secrète est celle que vous devez suivre pour prendre des mesures supplémentaires.
L'essentiel est que toute clé doit être soigneusement protégée. Il y a suffisamment de gens qui cherchent à abuser des faiblesses de la sécurité pour obtenir ce qu'ils veulent. Même les petits sites insignifiants sont de bonnes cibles s'ils peuvent y trouver quelque chose qu'ils peuvent utiliser pour usurper l'identité d'un utilisateur ailleurs.
Quant à votre deuxième question, il y a une raison pour laquelle OAuth 2 est devenu un standard de l'industrie. Il est bien défini, et il existe des bibliothèques de support dans à peu près tous les langages de programmation pour travailler avec. Il est préférable de ne pas réinventer la roue sans une très bonne raison, surtout quand il y a tant de support pour la norme existante.
Remarque: la rétro-ingénierie de la logique de l'application n'accorde pas automatiquement l'accès aux données qu'elle gère. Si vous concevez correctement votre application, vous n'aurez pas nécessairement les informations nécessaires pour voler les clés d'autres personnes.
J'ai travaillé avec des API publiques dans un seul petit projet, mais j'ai récemment appris que si l'on devait distribuer un projet avec des clés d'API à l'intérieur, c'est un risque pour la sécurité.
Sérieusement, je tiens à vous féliciter pour le savoir déjà si tôt dans votre carrière, car croyez-vous ou non, de nombreux développeurs seniors sont encore mal informés ou ignorent les implications en matière de sécurité pour la distribution d'une clé API.
L'une des principales causes de cette confusion à propos des clés API, que beaucoup ne réalisent même pas, est qu'un développeur doit être conscient de la différence entre [~ # ~] ce [~ # ~] et [~ # ~] qui [~ # ~] accède au serveur API.
La différence entre QUI et QUOI est l'accès au serveur API
Pour mieux comprendre les différences entre les [~ # ~] qui [~ # ~] et les [~ # ~] ce que [~ # ~] accède à 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 intention malveillante, utilisant une version non altéré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 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 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 que vous avez peut-être déjà une idée de la raison pour laquelle les [~ # ~] qui [~ # ~] et les [~ # ~] ce que [~ # ~] ne sont pas les mêmes, mais sinon 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 en 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 ressource. Il spécifie un processus permettant aux propriétaires de ressources d'autoriser l'accès tiers à leurs ressources de serveur sans partage Conçus spécifiquement pour fonctionner avec Hypertext Transfer Protocol (HTTP), 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 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 en fonction de l'authentification effectuée par un serveur d'autorisation, ainsi que pour obtenir des informations de profil de base sur l'utilisateur final de manière interopérable et de type REST.
Bien que l'authentification des utilisateurs puisse faire savoir au serveur d'API [~ # ~] qui [~ # ~] utilise l'API, il ne peut garantir que les demandes 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 API, et ici les choses deviennent plus délicates que la plupart les développeurs peuvent penser. Le [~ # ~] ce que [~ # ~] est la chose qui fait la demande au serveur API. Est-ce vraiment une véritable instance de l'application mobile, ou est-ce un bot, un script automatisé ou un attaquant qui 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 d'un des utilisateurs légitimes utilisant une version reconditionnée de l'application mobile ou un script automatisé qui essaie de gamifier et de profiter du service fourni par l'application.
Eh bien, pour identifier les [~ # ~] ce que [~ # ~] , les développeurs ont tendance à recourir à une clé API dans laquelle ils codent généralement en dur 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, ce qui en fait un secret d'exécution par opposition à l'ancienne approche lorsqu'un secret statique est incorporé dans le code.
L'écriture ci-dessus a été extraite d'un article que j'ai écrit, intitulé POURQUOI VOTRE APPLICATION MOBILE A-T-ELLE BESOIN D'UNE CLÉ D'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.
Ingénierie inverse
Sûrement, si quelqu'un peut inverser l'ingénierie de l'application, il pourrait extraire toutes les clés d'API présentes.
Tout secret stocké dans une application Web sera facile à extraire, appuyez simplement sur F12 dans le navigateur ou view page source, puis recherchez-le.
Pour une application mobile, certains peuvent penser que c'est beaucoup plus difficile, mais en fait, c'est aussi facile, et vous pouvez prendre la voie du reverse engineering de l'apk mobile, comme je le montre dans cet article Comment extraire un Clé API d'une application mobile avec analyse binaire statique:
L'utilisation de MobSF pour inverser l'ingénierie d'un APK pour une application mobile nous permet d'extraire rapidement une clé API et nous donne également une énorme quantité d'informations que nous pouvons utiliser pour effectuer une analyse plus approfondie qui peut révéler plus de vecteurs d'attaque dans l'application mobile et le serveur d'API. Il n'est pas rare de trouver également des secrets pour accéder à des services tiers parmi ces informations ou dans le code source décompilé disponible en téléchargement aux formats smali et Java Java.
Mais ma méthode préférée pour extraire une clé API va pour une attaque MitM, où j'aime proxy le trafic entre l'application mobile et le serveur API via l'outil open source mitmproxy , et vous pouvez apprendre à faites-le dans une application mobile sur cet article, j'ai écrit Voler cette clé API avec un homme dans l'attaque du milie:
Bien que nous puissions utiliser des techniques avancées, comme 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.
VOS QUESTIONS
Question 1
Que contient une clé API qui poserait un risque pour la sécurité?
Le plus souvent, ce n'est pas ce qu'il contient, mais ce qu'il représente, et vous pouvez déjà comprendre qu'il devrait être utilisé pour identifier [~ # ~] ce que [~ # ~] se connecte à votre serveur API.
Dans les cas où une clé API est un jeton JWT , elle peut ou non contenir en elle-même des informations sensibles.
JSON Web Token (JWT) est une norme ouverte (RFC 7519) qui définit une manière compacte et autonome de transmettre en toute sécurité des informations entre les parties en tant qu'objet JSON. Ces informations peuvent être vérifiées et fiables car elles sont signées numériquement. Les JWT peuvent être signés à l'aide d'un secret (avec l'algorithme HMAC) ou d'une paire de clés publique/privée à l'aide de RSA ou ECDSA.
Ainsi, même si les clés API ne contiennent aucune donnée sensible, elles constituent un risque pour la sécurité dès qu'elles sont utilisées pour protéger l'accès aux ressources, car il est facile de les extraire des applications clientes et de les réutiliser pour effectuer des attaques automatisées, où le L'attaquant peut usurper l'identité du serveur API comme étant l'application authentique (QUOI) et l'utilisateur authentique (OMS).
Question 2
Comment créer une application qui utilise des API publiques et distribuer cette application sans poser de risque pour la sécurité?
La vraie vérité ... Vous ne pouvez pas le faire dans une application Web, car une fois que vous la publiez, toute date sensible sur elle devient partie du domaine public, une fois qu'elle peut être consultée par quiconque inspecte l'application Web avec le construit -dans les outils de développement de navigateur.
Maintenant, dans une application mobile, vous pouvez avoir une solution possible, qui est connue par l'attestation d'application mobile.
Attestation de l'application mobile expliquée
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, ne s'exécute pas dans un appareil enraciné, n'est pas instrumentée par un cadre comme xPosed ou Frida, n'est pas attaquée par MitM, et cela est obtenu en exécutant un SDK en arrière-plan. Le service exécuté dans le cloud mettra à l'épreuve l'application et, sur la base des réponses, il attestera de l'intégrité de l'application mobile et de l'appareil, le SDK ne sera donc jamais responsable des décisions.
Injectez vos propres scripts dans des processus de boîte noire. Accrochez n'importe quelle fonction, espionnez les API de chiffrement 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.
Xposed est un cadre pour les modules qui peut changer le comportement du système et des applications sans toucher à aucun 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 d'origine n'a pas été trop modifié). Il est également facile de l'annuler.
Un proxy HTTP interactif compatible TLS pour les testeurs de pénétration et les développeurs de logiciels.
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 API et le service d'attestation d'application mobile dans le cloud connaissent. En cas d'échec de l'attestation de l'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 d'API le jeton JWT dans les en-têtes de la demande. Cela permettra au serveur API de ne servir les demandes que s'il peut vérifier la signature et le délai 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 de l'application mobile, il n'est pas possible de procéder à une rétro-ingénierie lors de l'exécution, même lorsque l'application est falsifiée, exécutée sur un appareil enraciné ou communiquant via une connexion en cours de connexion. cible d'un homme dans l'attaque du milieu.
Le service Mobile App Attestation existe déjà en tant que solution SAAS chez Approov (je travaille ici) qui fournit des SDK pour plusieurs plates-formes, y compris iOS, Android, React Native et autres. L'intégration aura également besoin d'un petite vérification dans le 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 API puisse décider quelles demandes à traiter et lesquelles refuser.
CONCLUSION
Je suis un nouveau diplômé en informatique, donc une explication serait très appréciée.
J'espère que j'ai pu répondre à vos questions de manière simple et que vous comprenez maintenant clairement la différence entre [~ # ~] ce que [~ # ~] et [~ # ~] qui [~ # ~] accède à votre serveur API, car garder cette notion vivante dans votre mémoire vous aidera vous permet d'écrire un code beaucoup plus sûr, qu'il s'agisse de code côté serveur ou côté client.
Ainsi, pour les applications Web, vous ne pouvez pas les distribuer dans un format qui protège la clé API, vous devrez donc concentrer vos efforts de sécurité sur le serveur API.
Pour les applications mobiles, l'espoir existe toujours sous la forme d'une solution d'attestation d'application mobile, qui sécurisera à la fois l'application mobile et le serveur d'API, et sans avoir à gérer les faux positifs.
Au final, la solution à utiliser pour protéger votre application et 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 PLUS LOIN?
Projet de sécurité mobile OWASP - 10 principaux 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 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.