Sécuriser une API pour l'accès mobile

Question

J'ai construit une API Nice REST/JSON qui est utilisée par d'autres sociétés (nos clients) en tant que service B2B. Chacun de nos clients a une paire nom d'utilisateur/mot de passe, et nous faisons également HTTPS et validons l'IP source des demandes de service. L'utilisation du service coûte de l'argent et le client est facturé mensuellement pour son utilisation du service.

Aujourd'hui, certains clients créent des applications mobiles qu'ils remettent à leurs utilisateurs (utilisateurs finaux B2C). Tous ces utilisateurs finaux de notre service n'ont pas de serveurs et ils souhaitent utiliser le service directement depuis le smartphone (ce qui n'est techniquement pas un gros problème étant JSON/REST).

Le problème est que je ne sais pas comment protéger le service contre la fraude. Qu'est-ce qui empêchera un développeur tiers de démonter l'une des applications mobiles du client et de copier son nom d'utilisateur/mot de passe/quelles que soient les informations d'identification de sécurité et de les utiliser dans son application? Cela lui permettrait de consommer le service et de facturer l'utilisation à l'un de nos clients légitimes!

Je suis presque sûr qu'il n'y a pas de solution cryptographique parfaite à ce problème à moins que les utilisateurs finaux ne soient mandatés pour s'authentifier sur un serveur. Mais ce n'est pas toujours le cas.

En dernier recours, je suppose que je peux distribuer une bibliothèque obscurcie pour Android/IPhone, ce qui donnerait au moins l'illusion de la sécurité ...

EDIT (clarification):

Permettez-moi d'essayer de simplifier le scénario.

J'ai un serveur Web non piratable qui sert une API JSON REST.
Les clients mobiles accèdent directement à mon API. Leurs adresses IP ne peuvent pas être validées. Ils exécutent un système d'exploitation standard (Android/IOS).
Aucun autre serveur n'est impliqué.
Je ne peux pas accéder à l'IMEI des téléphones (il est considéré comme privé), et cela ne m'aiderait pas car je ne connais pas les utilisateurs finaux.
Il existe plusieurs de ces applications mobiles légales, développées par différentes sociétés qui accèdent à notre API.
La sécurité actuelle (nom d'utilisateur/mot de passe) est facilement piratable par une entreprise malveillante. Cette société voyou démonte une application mobile légitime et copie le nom d'utilisateur/mot de passe dans son application illégale. Ils distribuent cette application et profitent (l'utilisation de l'API est facturée à la société auprès de laquelle ils ont volé les informations d'identification).

Cela peut-il être arrêté?

Joel L · Answer

Votre question est "Est-ce que cela peut être arrêté?", Mais j'ai l'impression que tout ce qui est significatif sur le système ne peut pas/ne sera pas vraiment changé.

Si je comprends bien, vous demandez (simplifié):

J'ai de nombreux clients partageant le même nom d'utilisateur et le même mot de passe. Puis-je arrêter les abus?

La réponse à cette question est non. Vous devez décider si vous pouvez vous permettre d'ignorer le problème ou mettre en œuvre des solutions correctes.

Si vous voulez vraiment le faire correctement, envisagez d'implémenter quelque chose comme OAuth, afin de pouvoir distribuer correctement des jetons d'authentification distincts pour les utilisateurs finaux, les lier à vos clients pour la facturation, révoquer l'accès, etc.

-

Le moins que vous puissiez faire est de permettre à vos clients (les entreprises) d'opter pour un meilleur système d'authentification. Ainsi, par exemple, vous créez une API pour qu'ils demandent (et révoquent) des jetons d'accès distincts pour leurs utilisateurs finaux.

La société A demande des jetons à ses serveurs (cela est déclenché par leur application leur disant "donnez-moi un jeton")
Vous retournez le jeton N, enregistrez à quelle entreprise il est attaché
Si l'application Company A-s se connecte à votre service, elle envoie le jeton N, et non le nom d'utilisateur/mot de passe
La société A peut indiquer à votre service "révoquer le jeton N", et les demandes ultérieures avec ce jeton ne seront pas traitées par votre service. Mais, si un jeton est révoqué, il ne rendra pas toutes les applications client inutilisables.

Si une entreprise ne souhaite pas le faire, elle peut toujours continuer à se connecter en utilisant son nom d'utilisateur/mot de passe, mais elle serait entièrement responsable de toute utilisation qui en résulterait.

Le fait est que vous ne pouvez pas vraiment tenir vos clients responsables des fuites d'informations d'identification (ce qui est impossible à faire dans un scénario d'application mobile) s'ils n'ont pas d'autre moyen d'utiliser le service.

Kurt · Answer

J'espère donc avoir ce correct. Vous souhaitez un moyen sécurisé de confirmer l'identité d'un client à l'aide d'une clé API valide? Je pense que le stockage sécurisé de la clé API est en grande partie responsable de l'entreprise qui a développé l'application et non de votre entreprise.

Vous devrez crypter et obscurcir la clé pour la protéger du pirate occasionnel, mais je ne pense pas que vous pourrez jamais empêcher un pirate déterminé. Vous pouvez faire un peu de piratage pour rendre le binaire plus difficile à déboguer, ce qui peut réduire les chances que votre application flotte sur Internet. Cependant, ce n'est pas une sécurité absolue et à moins que votre entreprise ne développe les applications en interne, comment pouvez-vous appliquer ces mesures?

Donc, en réponse à votre scénario, non, je ne pense pas qu'il puisse être arrêté efficacement sans nuire à l'expérience des utilisateurs. Vous pouvez éduquer les entreprises utilisant votre API - rédigez un petit manuel pour elles et assurez-vous qu'il est clair qu'il est leur de garder leur clé api sécurisée.

De votre côté, vous pouvez également implémenter certaines fonctionnalités d'atténuation. Par exemple:

Permettre aux entreprises de définir leurs propres limites strictes. Supposons que la société A sait que le mois dernier, elle avait N téléchargements d'applications et qu'elle souhaite donc limiter son accès à votre API à X requêtes par jour ou par heure.
Surveillez les pics de demandes par entreprise et par période.
Définissez une étape des procédures qui se produirait en cas d'activités frauduleuses potentielles.
Re-clé, re-clé et re-clé.

Le but de l'échec (cela arrive au mieux) est de minimiser les dégâts.

Bonne chance.

D.W. · Answer

Vous avez raison d'être sceptique quant à l'intégration de leur nom d'utilisateur/mot de passe dans une application mobile qu'ils remettent à tous leurs utilisateurs. Comme vous l'avez correctement identifié, il serait facile pour un attaquant de démonter cette application mobile, de retirer le nom d'utilisateur/mot de passe de l'application mobile et de l'utiliser dans sa propre application. Malheureusement, c'est votre client qui décide de le faire, mais le coût vous est imposé. Il s'agit donc d'une externalité, et vous aurez besoin d'un moyen de mieux aligner les coûts, les risques et les incitations. J'ai quelques suggestions ci-dessous sur la façon de procéder.

D'une manière générale, je vois deux solutions plausibles à cela:

Transfert des risques. Pour chaque client, imposez une limite au nombre de demandes que vous accepterez de ce client. Dites aux clients qu'il est de leur responsabilité de garder leur nom d'utilisateur/mot de passe sécurisé, que toutes les demandes qui arrivent en utilisant ce nom d'utilisateur/mot de passe seront prises en compte dans leur limite, et si trop de demandes arrivent, leur compte peut être désactivé. Dites-leur que s'ils intègrent leur nom d'utilisateur/mot de passe dans une application mobile, il y a un risque que quelqu'un d'infâme vole le nom d'utilisateur/mot de passe et l'utilise pour faire de nombreuses demandes, entraînant la désactivation de leur compte et l'arrêt de leur application mobile. . Laissez-les décider s'ils veulent prendre le risque ou non.
Exigences contractuelles. Informez vos clients qu'il leur est interdit de partager leur nom d'utilisateur/mot de passe avec d'autres personnes, et il ne leur est pas permis d'intégrer leur nom d'utilisateur/mot de passe dans des applications téléchargeables par d'autres. Dites-leur que si vous détectez des violations de cette politique, leur compte peut être désactivé et ils peuvent être facturés pour tous les frais que cela impose à vos serveurs.

Si vos clients souhaitent créer une application mobile, dites à vos clients qu'au lieu d'incorporer leur propre nom d'utilisateur/mot de passe dans l'application mobile, ils doivent proxy ces demandes sur leur propre serveur. En d'autres termes, le client doit configurer un serveur qui connaît le nom d'utilisateur/mot de passe du client, mais ce nom d'utilisateur/mot de passe ne doit pas être intégré dans l'application mobile. L'application mobile du client doit s'authentifier auprès du serveur du client, envoyer une demande au serveur, puis le serveur doit vous transmettre la demande et renvoyer la réponse à l'application mobile. Leur serveur doit authentifier l'utilisateur final (par exemple, exiger que chaque utilisateur final de l'application mobile crée un compte sur son serveur, avec son propre nom d'utilisateur/mot de passe). Leur serveur doit imposer des limites de bande passante pour chaque utilisateur et désactiver le compte de tout utilisateur final qui dépasse ces limites.

Vous pouvez également permettre aux clients de choisir entre ces deux options: par exemple, entre un compte à bande passante limitée (avec transfert de risque) ou un compte à bande passante illimitée (avec une exigence de ne pas intégrer le nom d'utilisateur/mot de passe dans des applications accessibles aux autres). ).

J'espère que cela a du sens. Cela peut être un peu déroutant, car il y a trois parties - vous, votre client et l'utilisateur final de votre client - chacun ayant ses propres intérêts et préoccupations. J'espère avoir fait une distinction adéquate entre les trois.

mojo · Answer

La sécurisation de vos données en transmission avec SSL a déjà couvert l'attaque de l'homme au milieu. Les mots de passe codés en dur dans le code source ne sont de toute façon pas une pratique sûre. Vous ne devez pas vous soucier de l'adresse IP des utilisateurs ou de l'IMEI. Ne parlons pas de suivi et essayons de réparer les choses en premier lieu.

Comme vous l'avez dit, vous utilisez REST. Peu de choses devraient vous aider, j'espère.

Authentifiez les utilisateurs côté serveur. Maintenez une gestion de session stricte afin qu'elle ne puisse pas être falsifiée. Consultez OWASP pour cela.
Faites un test fuzz pour votre API. ReST est connu pour quelques vulnérabilités. Veuillez les explorer sur Internet et découvrir la plupart des bogues connus de ReST. Corrigez ces problèmes pour votre API.
Votre truc SSL est bien qu'il protège vos données au milieu.

Ne vous inquiétez pas de votre code source. Il peut être arraché de toute façon, mais ça va. Vos fonctions principales doivent être exécutées sur le serveur et transmettre simplement les réponses aux clients. Gardez toutes les bonnes choses côté serveur.

Mohit Sethi · Answer

Je pense que l'un des problèmes auxquels vous serez confronté sur le front mobile est la validation de l'adresse IP. En règle générale, les adresses IP mobiles attribuées par l'opérateur de télécommunications seront supprimées. L'IP en réseau rendra le mécanisme de validation IP adopté du côté serveur inutile.

Pour implémenter la solution sur Android et Iphone's; je pense que l'approche devrait être:

Faites également en sorte que l'authentification du serveur client en mode SSL soit étendue à la validation du certificat client. Je veux dire que le client et le serveur utilisent tous deux des certificats pour établir une session SSL sécurisée.
Livrez le PFX/P12 contenant le certificat client (mobile) de telle manière qu'il nécessite un PIN et une combinaison de numéros IMEI et IMSI. De cette façon, il deviendra difficile pour un attaquant de répudier le même session.
Avoir une IA implémentée sur le serveur qui détecte deux sessions simultanées ou plus lancées à l'aide du même certificat client, ce qui vous permettra de savoir qu'un compromis s'est produit et le serveur peut immédiatement mettre sur liste noire ou révoquer le certificat pour une utilisation ultérieure.

Je pense que nous parlions d'un environnement mobile; autres que la validation IP, les risques sont également présents dans l'environnement PC. À l'avenir, vous pouvez également adopter ou migrer vers une implémentation basée sur les signatures et les certificats clients sur l'environnement PC si vous rencontrez des problèmes de facturation erronés soulevés par les clients.

John Santos · Answer

La fraude est très répandue et ne peut être combattue par une simple implémentation technique, mais si vous avez implémenté une validation et un verrouillage IP intensifiés, alors ne vous inquiétez pas. Vous ne devez pas non plus donner les informations d'identification réelles à vos clients (B2B). Permettez-moi d'expliquer pourquoi et comment.

D'après ma compréhension de ce que vous avez écrit, les concepts et implémentations de sécurité de base à moyens ont déjà été appliqués concernant le côté B2B (YOURCOMPANY - YOURCLIENT). C'est bon. Validation IP, SSL/TLS, utilisateur/passe, etc. Maintenant, vous craignez que les informations d'identification de l'API utilisées par vos clients pour fournir des applications mobiles aux utilisateurs finaux puissent être faussées d'une manière dont un utilisateur final tiers tirerait parti ces informations d'identification si l'application mobile de votre client a été exploitée d'une manière ou d'une autre.

Fondamentalement, cela se résume à une série de couches de sécurité. La question est de savoir comment votre entreprise a conçu et implémenté ces couches?

Votre JSON/REST API SERVER doit contenir vos informations d'identification réelles. Si vous fournissez un service et que vous avez besoin d'une connexion à un fournisseur/opérateur réseau, ces informations d'identification peuvent également être trouvées ici. Tu sais ce que je veux dire.
Ne donnez pas à YOURCLIENT un accès direct au JSON/REST API SERVER. Au lieu de cela, vous avez besoin d'un hôte de saut qui servira d'hôte pour l'environnement de confiance, le serveur API à partir duquel réside votre application JSON/REST doit s'authentifier UNIQUEMENT auprès de ce serveur à l'aide de la validation/du verrouillage de l'adresse IP. Authentification de serveur à serveur à l'aide d'IP ou de paires de clés publiques/privées. C'est votre discrétion quoi utiliser.

Ce serveur doit également agir comme un service Web contenant un ensemble de nom d'utilisateur/mots de passe qui se mappe ensuite sur un fichier de configuration et transmet la demande au JSON/REST API SERVER. Maintenant, YOURCLIENTS devrait également avoir accès à ce serveur sur la base de la validation/du verrouillage IP et protégé par HTTPS. Le concept est qu'aucun identifiant utilisateur/passe réel ne peut être trouvé ici, à l'exception de la clé/secret qui est mappé au SERVEUR API.

YOURCLIENT peut avoir une implémentation de sécurité de son côté pour les utilisateurs finaux. Il peut s'agir d'une forme de paire de clés publique/privée PKI pour les développeurs ou d'un 2FA pour les utilisateurs ordinaires. YOURCLIENT devrait mettre en œuvre ces étapes, pas votre entreprise.

Maintenant, par exemple, un développeur tiers (utilisateur final) avait exploité une faille sur une application mobile créée par l'un de YOURCLIENT et avait obtenu ses informations d'identification:

Inutile. Concernant que pour utiliser les identifiants, votre IP sera validée.
Invalide. Concernant le fait que vous devez avoir été authentifié via une paire de clés publique/privée.
La technique d'escalade de privilèges l'obligera à exploiter le serveur réel pour être fiable.
L'exploitation du serveur réel nécessite des techniques spécialement conçues pour ralentir la motivation d'un attaquant.
Il n'y a pas d'attaque réussie dont la motivation est terminée.

L'obfuscation est bonne et ralentit une attaque mais c'est la moindre forme de sécurité. Vous devriez mieux vous fier à la cryptographie qui utilise des clés.

N'oubliez pas qu'il n'y a pas de solution de sécurité absolue en dehors de vos efforts continus pour lutter contre la fraude dans une perspective de sécurité technique et opérationnelle.