Comment communiquer en toute sécurité avec le serveur?

Question

Je construis une solution composée d'une application et d'un serveur. Le serveur fournit certaines méthodes (json) et l'application les utilise. Mon but est de rendre ces méthodes d'API inaccessibles aux autres clients. Quelle est la meilleure façon de le faire? Dois-je regarder les certificats (pour signer chaque demande sortante)? Si oui, où dois-je commencer et quel est l'impact sur les performances de le faire? Quelles sont les alternatives?

Answer 1

En d'autres termes, vous avez besoin d'un moyen de distinguer la demande d'un client valide de la demande d'un client invalide. Cela signifie que le client doit présenter des informations d'identification démontrant que la requête provient d'une source valide.

Les certificats SSL sont un excellent moyen d'affirmer une identité qui peut être validée. La validité d'un certificat SSL peut être confirmée si le certificat contient une signature valide créée par un autre certificat connu comme sécurisé, un certificat racine.Comme indiqué dans les autres réponses, un certificat intégré ne fera pas l'affaire car ce certificat peut être compromis en disséquant l'application. Une fois qu'il est compromis, vous ne pouvez pas accepter les demandes qui le présentent et verrouiller tous vos utilisateurs. Au lieu d'un certificat d'application intégrée, vous devez émettre un certificat distinct pour chaque utilisateur valide. Pour ce faire, vous devez configurer (ou externaliser) une autorité de certification et émettre des certificats individuels et signés à des clients valides. Certains de ces certificats seront compromis par l'utilisateur - soit parce qu'ils ont été piratés, négligents ou intentionnellement essayer de frauder votre service. Vous devrez surveiller ces certificats volés, les placer sur une liste de révocation de certificats (CRL) et refuser le service sur ces certificats compromis. Tout serveur Web peut refuser une connexion basée sur une liste de révocation de certificats.

Cela ne résout pas les problèmes de sécurité, il suffit de les sortir de l'application. Il est toujours possible pour quelqu'un de créer ce qui semble être un certificat valide via l'ingénierie sociale ou en volant votre certificat racine et en fabriquant de nouveaux certificats signés. (Ce sont des problèmes auxquels sont confrontés tous les fournisseurs PKI.)

Il y aura une atteinte des performances. Le nombre de réponses dépend du nombre de demandes de l'application. La classe iPhone NSURLConnection prend en charge les certificats client SSL et les certificats client peuvent être installés sur le téléphone à partir d'un courrier électronique ou d'une requête Web authentifiée. La gestion de l'infrastructure pour prendre en charge les certificats clients nécessitera plus d'efforts que le codage dans l'application. Incidemment, voter pour une réponse que vous n'aimez pas crée un effet dissuasif dans la communauté. Vous n'avez pas autant de chance d'obtenir des conseils, bons ou mauvais, si vous voulez vous méfier du score de réputation de tout le monde.

Answer 2

Je vais maintenant admettre que c'est une question intéressante, mais je n'ai aucune idée de comment cela pourrait être fait.

réponse originale:

question intéressante. En supposant que les gens ne peuvent pas désosser l'application iPhone, la seule solution qui vient à l'esprit serait de signer des demandes avec une clé publique, ou un autre secret connu uniquement de l'application. Par cela, je veux dire ajouter un argument supplémentaire à chaque appel API qui est un hachage de l'URL de destination et d'autres arguments combinés avec un secret connu uniquement de votre serveur et de votre application. Pour développer sur ceci: supposons que votre appel API a des arguments foo, bar et qux. J'ajouterais un argument signature, dont la valeur pourrait être quelque chose d'aussi simple que de trier les autres arguments par leur nom, de les concaténer avec leurs valeurs, d'ajouter un secret et de hacher le lot. Ensuite, du côté serveur, je ferais la même chose (à l'exception de l'argument signature) et vérifierais que le hachage correspond à celui qui nous a été donné dans la requête.

Answer 3

Considérez HTTP authentifié.

Pour une alternative moins chère, il existe un schéma secret/hachage partagé. Le client et le serveur ont une chaîne secrète partagée de texte. Sur demande, le client hash ensemble (en utilisant MD5, ou SHA1, ou SHA quelque chose d'autre - vous choisissez) les champs de requête et le secret. La valeur de hachage est attachée à la demande - disons, comme un autre champ POST.

Le serveur effectue la même opération avec la requête et avec sa copie du secret, puis compare les valeurs de hachage. Si elles ne correspondent pas - service refusé. Pour plus de sécurité, vous pouvez chiffrer le hachage avec une clé publique RSA. Le client a la clé publique, le serveur conserve la clé privée. Le serveur déchiffre le hachage avec la clé privée, puis la même chose. Je l'ai fait avec un client C++ WinMobile et un service basé sur PHP - fonctionne comme un charme. Aucune expérience avec crypto sur iPhone, cependant.

MISE À JOUR: maintenant que je pense, si l'on suppose que l'attaquant a un contrôle complet sur le client (ahem iPhone jailbreaké et un débogueur), le problème, tel qu'il est formulé ci-dessus, ne sont pas résoluble en théorie. Après tout, l'attaquant pourrait utiliser vos bits pour accéder au service. Inversez l'exécutable, trouvez les fonctions appropriées et appelez-les avec les données souhaitées. Construire un état global, si nécessaire. Alternativement, ils peuvent automatiser votre interface utilisateur, style scraper d'écran. Tel est le triste état des choses.