Existe-t-il un moyen d'empêcher quelqu'un de créer sa propre application client pour mon service Web?
Disons que j'ai un service Web RESTful et une application commerciale Android sur le frontal qui est utilisée pour interagir avec lui. Je peux utiliser SSL pour que les points de terminaison ne soient pas visibles, mais quelqu'un pourrait toujours le faire une certaine ingénierie inverse pour les trouver.
Je pourrais également utiliser SOAP à la place, pour que l'appel au service Web soit un peu plus compliqué. Mais, je ne sais toujours pas si cela me donne un réel avantage sur le service basé sur RESTful.
Je pensais à coder en dur la clé dans mon application client, afin que seule mon application client puisse utiliser le service. De plus, un brouillage du code peut être utile. Mais, combien cela aide-t-il vraiment?
MISE À JOUR: Comme l'a souligné JOW Fiddler
pourrait être utilisé pour déchiffrer https et voir la demande complète. Cependant, si j'utilise Android app uniquement, cela peut être résolu par un certificat de serveur de codage en dur dans Android application cliente. Et aussi, il y a SOAP WS-Security, mais je suppose qu'un outil peut être fait pour fonctionner de la même manière que fidler pour contourner cela.
Ce serait impossible. Il est fondamental que votre application contienne toutes les instructions nécessaires pour utiliser votre API. Quiconque possédant suffisamment de compétences et de temps pourra extraire ces secrets et créer son propre client.
Il est assez facile et simple de créer son propre client, que REST ou SOAP soit utilisé, tant que votre client existant est disponible pour tout le monde dans le jeu). Enregistrez simplement le trafic HTTP à partir d'un appareil Android en utilisant Fiddler , et créez votre propre client en fonction du trafic capturé.
Même le trafic HTTPS peut être facilement décrypté à l'aide de Fiddler . Les méthodes HTTP, les URL, les en-têtes, les cookies, le corps et votre clé sont tous visibles. Je ne pense pas que ce soit sûr du tout. (Il existe d'autres procurations inverses qui peuvent faire la même chose que Fiddler.)
Du point de vue de la sécurité, non, il n'y a aucun moyen de le faire. Quel que soit le niveau d'obscurcissement que vous mettez sur le code et les protocoles, le fait est que le code pour accéder à l'API et le trafic réseau généré lorsque l'API est accessible est entre les mains de vos utilisateurs, et ils peuvent utiliser tous les outils de rétro-ingénierie ils veulent dessus.
D'un point de vue commercial, vous devez évaluer le coût pour vous si quelqu'un produit un client alternatif par rapport au coût supplémentaire pour mettre en œuvre des mesures pour empêcher que cela se produise. Par exemple, vous pouvez utiliser entièrement une API propriétaire fortement obscurcie (en évitant REST, SOAP et d'autres protocoles standardisés), mais cela sera plus difficile à mettre en œuvre et coûtera donc plus cher. D'un autre côté, cela compliquerait considérablement la tâche de la rétro-ingénierie. Vous devez déterminer si de telles mesures (ou d'autres mesures appropriées) en valent la peine pour votre entreprise.
D'un point de vue juridique, de nombreux endroits ont des conditions de service qui interdisent la production ou l'utilisation de clients tiers. C'est à vous de faire respecter cela en surveillant le trafic vers votre serveur pour déterminer si l'un est susceptible d'utiliser un client tiers ou en surveillant l'apparition de clients tiers sur les boutiques d'applications. C'est également à vous de décider si vous avez les ressources nécessaires pour intenter une action en justice et si cela vaut la peine de prendre une telle mesure.
Du point de vue des relations avec les utilisateurs, vous souhaiterez peut-être reconsidérer l'idée d'interdire tous les clients tiers en tant que règle générale. Évidemment, personne ne veut qu'un développeur produise un horrible client avec sa propre publicité, mais de nombreux services permettent aujourd'hui aux développeurs tiers d'enregistrer leurs applications et de recevoir une clé API. Le processus d'enregistrement peut être aussi simple ou aussi complexe que vous le souhaitez, allant d'une simple condition d'utilisation (par exemple "ne mettez pas vos propres publicités dans l'application") à une évaluation de leur interface ou à un examen complet de leur source code (bien sûr, plus c'est simple, plus les développeurs seront disposés à s'inscrire). Permettre aux développeurs tiers d'utiliser votre API n'est pas nécessairement une mauvaise chose non plus - ils pourraient vouloir produire une application qui utilise votre service comme source de données mais qui ne leur est en aucun cas liée, et dans ce cas, ils pourraient vous apportent réellement plus d'affaires s'ils mettent une accréditation appropriée dans leur application, ou s'ils veulent remplir un marché dans lequel votre entreprise n'a pas l'intention de pénétrer, ou ils peuvent vraiment avoir une meilleure idée d'une application cliente pour votre service, qui est quelque chose que vous pouvez apprendre pour améliorer votre propre application.
Vous ne pouvez pas rendre impossible l'accès non autorisé à l'API dans le sens de la sécurité, mais vous pouvez le minimiser. Ce n'est pas vraiment une question de sécurité, mais le concept du modèle de menace est assez approprié: qui voulez-vous empêcher d'accéder à votre API et quel genre de dommages voulez-vous éviter?
De nombreux grands sites Web interdisent d'autres moyens d'accéder à leur service, généralement afin qu'ils puissent continuer à diffuser des annonces. Ils le font grâce à une combinaison de mesures à plusieurs niveaux:
- vérification des en-têtes de demande et de l'agent utilisateur (ce qui empêche un grand nombre d'utilisateurs ordinaires occasionnels)
- compliquer l'API en ajoutant un état dynamique, une obfuscation et d'autres mesures (ce qui arrête la rétro-ingénierie occasionnelle, mais pas la détermination)
- l'interdire dans leurs conditions d'utilisation (ce qui empêche d'autres entreprises légitimes et quelques individus consciencieux)
- l'application de la ToS par le biais de la loi (qui peut être nécessaire contre les entreprises contraires à l'éthique, mais fera plus de mal que de bien si elle est déployée contre de petits utilisateurs individuels.)
Aucun de ceux-ci n'est efficace à 100%, mais ils n'ont pas besoin de l'être. L'important, c'est qu'ils réduisent les pertes. Pensez à ce que vous voulez accomplir et choisissez vos contre-mesures en conséquence.
Disons que j'ai un service Web RESTful et une application commerciale Android sur le frontal qui est utilisée pour interagir avec lui. Je peux utiliser SSL pour que les points de terminaison ne soient pas visibles, mais quelqu'un pourrait encore le faire une certaine ingénierie inverse pour les trouver.
SSL ne cache pas l'adresse IP cible, ils n'ont donc même pas besoin de procéder à une rétro-ingénierie. Tout le reste peut être obtenu via le certificat Fiddler + MITM.
Je pourrais également utiliser SOAP à la place, pour que l'appel au service Web soit un peu plus compliqué. Mais, je ne sais toujours pas si cela me donne un réel avantage sur le service basé sur RESTful.
Eh bien, plus vous faites d'efforts, plus un pirate informatique devra faire d'efforts, je suppose.
Cela étant dit, les pirates ont beaucoup plus de temps libre que vous, et ils sont nombreux, et un seul d'entre eux doit publier la solution sur un babillard et la partie est terminée.
Donc, cela ne vaut probablement pas la peine.
Je pensais à coder en dur la clé dans mon application client, afin que seule mon application client puisse utiliser le service. De plus, un brouillage du code peut être utile. Mais, combien cela aide-t-il vraiment?
Les pirates ont maintenant outils de désobfuscation à portée de main, donc cela n'aide plus autant qu'auparavant.
Ne vaut probablement pas la peine.
Fiddler pourrait être utilisé pour déchiffrer https et voir la demande complète. Cependant, si j'utilise Android app uniquement, cela peut être résolu par un certificat de serveur de codage en dur dans Android application cliente. Et aussi, il y a SOAP WS-Security, mais je suppose qu'un outil peut être fait pour fonctionner de la même manière que fidler pour contourner cela.
Le pirate pourrait inverser l'ingénierie beaucoup plus rapidement que vous ne pourriez le construire.
Donc, cela ne vaut probablement pas la peine.
Vous ne pouvez pas empêcher un pirate de procéder à la rétro-ingénierie d'un code qui s'exécute sur le client. Donc, quelles que soient les garanties que vous mettez, le pirate peut les imiter.
Exactement. Ne passez pas de temps là-dessus.
Au lieu de cela, essayez de concevoir votre application de sorte que les fonctionnalités sensibles soient exécutées sur le serveur, où vous pouvez la protéger.
Passez le reste de votre temps à améliorer les fonctionnalités de votre application afin que les clients ne veuillent rien d'autre.