Application iPhone sécurisée, communication avec le serveur

Quelle serait la meilleure approche pour établir une communication privée entre mon application iOS et son composant serveur? Le fait d'avoir une seule «clé secrète» immuable dans la source de l'application est-il suffisant, ou dois-je configurer des générations de telles clés de «poignée de main» de manière dynamique d'une manière ou d'une autre?

Le serveur en lui-même n'a accès à aucune donnée sensible, donc même si l'utilisateur atteint certains points de terminaison privés, il ne les obtiendra nulle part, mais je veux juste que ceux-ci soient cachés au public. Fondamentalement, je veux ignorer toutes les demandes atteignant des itinéraires particuliers, sauf si elles proviennent de mon application iOS.

Le composant serveur s'exécute sur RoR, si cela est important.

Vous ne pouvez pas rejeter efficacement les connexions à moins de fournir à chaque client une clé privée que vous pouvez révoquer individuellement. Mais c'est probablement exagéré. Vous n'avez pas besoin d'une solution pare-balles si la plupart des gens ne prennent pas la peine de tirer une balle.

C'est une question de sécurité, alors décrivons un modèle de menace et des stratégies d'atténuation.

Supposons que vous ayez une URL qui peut vous coûter cher (par exemple, le coût du traitement) et que vous souhaitez la protéger à la fois d'une simple attaque DoS et des applications de copie.

Utilisez SSL pour cacher la connexion d'être facilement analysée. Utilisez un numéro de port non-obviuos, une séquence de redirection, un échange de cookies pour compliquer légèrement la connexion avant de faire la partie coûteuse de la demande. Utilisez du code secret intégré à votre application pour informer le serveur qu'il doit accepter la connexion.

Maintenant, quelqu'un ne peut pas apprendre l'URL coûteuse à atteindre simplement en exécutant un renifleur de paquets ou en regardant des chaînes de type URL dans votre code. Un attaquant potentiel doit décompiler votre application.

Vous ne pouvez pas vraiment protéger votre code contre la décompilation et / ou l'exécution sous un débogueur. L'attaquant finit par apprendre la clé secrète et la séquence de connexion.

Vous remarquez que vous commencez à recevoir des demandes de rouge à votre URL coûteuse: soit sous la forme d'une attaque, soit sous la forme d'une application de copie qui doit accéder à votre service pour fonctionner, ou peut-être qu'un code d'exploitation est publié publiquement. Cependant, vous ne pouvez pas distinguer une demande frauduleuse d'une demande légitime.

Créez une mise à jour mineure gratuite de votre application, avec une clé secrète différente. Il doit frapper une URL coûteuse différente qui fournit les mêmes données que l'URL coûteuse compromise. Pendant un certain temps, rendez les deux URL accessibles.

Regardez votre base d'utilisateurs passer à la version mise à jour. Limitez l'URL coûteuse compromise et éventuellement 404. Vous venez d'atténuer une faille de sécurité, j'espère sans trop en perdre. Retour à la case départ.

Avertissement: je ne suis pas un expert en sécurité.

Vous avez un problème classique qui ne peut vraiment pas être résolu.

Pour garantir une confidentialité simple (c'est-à-dire pour vous assurer que vos données ne peuvent pas être espionnées ou modifiées en transit), vous pouvez tout faire via SSL et donner à votre serveur un certificat correctement émis par une autorité de certification reconnue par iPhone.

Pour l'autorisation, cependant, il n'y a pas de bonne solution qui garantisse à 100% que personne d'autre que votre application ne peut accéder à l'API. Votre solution proposée ne fonctionne, à l' exception:

• toute personne qui a téléchargé votre application a nécessairement en sa possession la clé privée
• s'ils parviennent d'une manière ou d'une autre à décompresser votre application et à la décompiler, ils auront la clé privée en texte brut
• une fois qu'ils ont la clé privée en texte brut, ils peuvent l'utiliser pour signer leurs propres demandes malveillantes.

Il n'y a aucun moyen de contourner cela. Cela ne veut pas dire que vous ne pouvez pas adopter cette approche, mais comprenez que ce n'est pas infaillible. C'est ce problème qui rend DRM complètement inefficace .

C'est à cela que servent TLS et SSL . L'un ou l'autre peut créer une connexion sécurisée sans avoir besoin d'une clé secrète fixe. Lisez la section Description sur la page liée pour savoir comment procéder.

Un moyen efficace pour bénéficier de TLS / SSL sans avoir à faire beaucoup (n'importe quel) travail est de faire en sorte que votre serveur implémente un service Web auquel le client accède en utilisant le protocole HTTPS. HTTPS est simplement HTTP sur une connexion sécurisée, et le système de chargement d'URL dans iOS le met en œuvre pour vous.