Comment sécuriser un service Web sans connexion

Question

J'ai une application mobile (actuellement IOS et bientôt Android) qui parle à un service web. Il n'y a pas de connexion et les données ne sont pas privés. Fondamentalement, l'application affiche un marqueur (lon, lat) et Obtient le plus proche de 25 marqueurs pour afficher sur une carte.

C'est un très trivial application et je ne peux pas imaginer que quelqu'un de mettre un grand effort en abusant du service web. Cependant, je peux le voir il est amusant pour quelqu'un dans la diffusion de nombreux marqueurs. Ce que la plupart des préoccupations moi est quelqu'un exécutant un script qui pousse de nombreuses demandes (à l'aide d'coûteux en bande passante et en faisant des bêtises de mes données d'application).

Je suis en train de parvenir à une conclusion cela ne peut pas être sécurisé. La meilleure réponse est "ne faites pas cela". Ne pas fournir un service web sans authentification. Pas beaucoup de services sont donc ouvertes. Google you Tube API est ouverte, mais la plupart ne le sont pas. Malheureusement, je n'ai pas le choix. Donc, après des jours de recherche sur ce, voici ma façon de penser. Sachez que je suis très loin d'être un expert en sécurité et je suis convaincu que mon approche pourrait être améliorée. Mais il peut vous diriger dans la bonne direction. Heureusement, quelqu'un de plus expérimenté pourrait carillon et corriger/améliorer sur ce point. J'ai trouvé cet article et les commentaires particulièrement utile.

Message De Sécurité Au Niveau De L'

Je vais sécuriser les msgs avec un hachage de chiffrement. Les clients de service web et conservent une copie d'un secret partagé qui est utilisé comme sel de créer un hash de l'URL et tous les arguments. Le hachage est passé comme un argument supplémentaire et la valeur de hachage est reconstruite et par rapport à l'autre bout (à l'aide de la clé partagée sous forme de sel). C'est assez bien jusqu'à ce que vous comprenez que tout client mobile code peut être à l'ingénierie inverse de minutes. À quel point cette ligne de défense est tout à fait inutile.

Client De Mesures

Le client comprend la limitation de fréquence des messages comme une mesure visant à limiter le nombre de messages envoyés par les honnêtes utilisateurs. Encore une fois c'est inutile contre un attaquant qui jailbreaks l'appareil mobile.

Côté Serveur De Sécurité

Donc, le serveur doit disposer d'autant de mesures de sécurité supplémentaires que possible, de rester seul sur l'hypothèse que votre client (et secret partagé) est compromise. Voici ce que j'ai:

Un msg arg est un temps UTC, qui est utilisé pour limiter les attaques de relecture. Cela devrait empêcher un attaquant de tirer le même msg sur le serveur à plusieurs reprises.

Le serveur effectue la limitation par IP. Oui, IPs sont facilement usurpée et proxy de commutation est un jeu d'enfant, mais tout ce qui est utile lorsque vous avez si peu.

Bien sûr, le serveur strictement valide tous les arguments, utilise parametised requêtes et ne retourne pas les exceptions.

Le Transport Au Niveau De La Sécurité

Malheureusement, je suis assez confiant que la délivrance de la client SSL cert n'est pas possible sans un processus d'enregistrement. Et parce que je suis en utilisant le msg vérifier le hash (et mes données n'est pas privé) je ne suis pas entièrement sûr de ce que SSL apporte à la table. Cependant, je vais probablement l'utiliser SSL (avec une seule application à l'échelle cert), car il ajoute un autre niveau de sécurité qui est facilement et à moindre coût de déploiement (mais à un coût supplémentaire de temps de connexion pour chaque msg).

Le Béante Gros Trou Dans Mon Approche

Je suis averti que si l'app devenu populaire que quelqu'un va compromettre le secret partagé sur le client. Tout simplement parce qu'ils peuvent et ils seront probablement de le publier sur internet. Si vraiment tout se résume à côté serveur. Malheureusement, je n'ai aucun moyen d'identifier et de bloquer un attaquant. Ce que j'aimerais beaucoup.

Un Dernier Moyen,

Après des jours de recherche, c'est tout ce que j'ai. Mais j'en veux plus. Je voudrais tout particulièrement apprécier toutes les idées pour renforcer le côté serveur. Donc, j'ai mis tous mes points comme un bounty. Oui, monsieur, tous les 97 points!

Answer 1

Effectivement, dans votre cas particulier, puisqu'il est actuellement seulement sur iOS app, il y a une solution.

1. Après que l'utilisateur télécharge et exécute l'application pour la première fois, l'application atteint un /access_token/create API qui arrive avec un GUID et le transmet à l'Application via Apple Push Notifications.

2. App store cette access_token, et l'utilise sur toutes les demandes ultérieures. Votre API peut limite de taux sur la base de l'access_token.

Fondamentalement, vous laisser Apple faire tout le travail difficile de s'assurer que la demande initiale est venu à un appareil iOS.

Une extension pour les clients de Bureau est possible, mais un peu ruines de l'UX. Il suffit de changer l'étape 1 pour autoriser /access_token/create à accepter l'arbitraire des demandes, et si la demande n'est pas à partir d'un appareil iOS, puis forcer l'utilisateur à vérifier leur adresse e-mail/résoudre un captcha, etc avant de délivrer un access_token.

Les appareils Android (pas vraiment familier avec eux), peuvent avoir le même Pousser le mécanisme de Notification, auquel cas vous pouvez l'utiliser, ou peut ne pas avoir une Notification Push mécanisme, auquel cas vous pouvez soumettre vos utilisateurs d'Android pour les inconvénients énumérés ci-dessus.

Answer 2

J'ai entendu parler de cette idée, une fois, quand on parle de trouver une solution globale au problème du SPAM: la force de votre client pour effectuer certaines de prise de temps de calcul.

Pour être précis: trouver une algorithme de calcul, qui peuvent calculer certains z pour une paire de x et y en un clin d'œil, mais ça prend énormément de temps de calcul z , étant donné que x. Je ne peux pas fournir de l'algorithme réel, mais je suis sûr qu'il ya beaucoup d'entre eux qui aurait beaucoup de ces critères.

Maintenant, l'ensemble de la procédure devrait se présenter comme suit:

1. Lors de la première demande du client à générer de la session_id et, pour cela, session_id une paire de x et y.
2. Fournir à votre clientèle, session_id et x.
3. Client peut commencer les calculs dès qu'il reçoit les données (dans certains thread d'arrière-plan ne sont pas liées aux interactions de l'utilisateur).
4. À la demande des marqueurs, le client doit fournir session_id et calculé z.
5. Vous pouvez rapidement vérifier si le client est z est tout à droite, vous avez déjà x et y qui vous permettent de le faire facilement.
6. (option 1) Pour chaque session_id magasin comment beaucoup de/il est souvent demandé. Le moment où vous croyez qu'il est victime de violence, de force de régénération x et y.
7. (option 2) la Force de nouveaux x et y sur chaque consécutives demande d' session_id.

Le choix entre le 6 et le 7 est en fait de peaufinage qui dépend de la complexité de l'algorithme vs attend juste l'utilisation de marqueur de la base de données. Si vos calculs sont bons les mauvais client ne devrait jamais obtenir trop de données ou une surcharge de votre serveur.

Espérons que cela aide.

Answer 3

Il n'y a vraiment rien que vous pouvez faire sur le côté client. Vous devez donner à l'ensemble de l'application (y compris les clés ou tout autre mécanisme de protection) à votre utilisateur. Si un utilisateur malveillant veut jouer de malice avec votre service web, il va devoir faire un peu de reverse engineering pour obtenir à votre service web. Vous pouvez la rendre plus difficile, mais vous ne pouvez pas éviter cela, n'importe comment dur vous essayez.

Je venais de mettre en œuvre certaines de serveur-côté limitation de débit (par adresse IP) et de ne pas s'inquiéter à ce sujet. C'est une bataille que vous ne pouvez pas gagner. Si quelqu'un veut vraiment faire du mal à votre serveur, il pourrait juste DDOS sans rien savoir à propos de votre protocole de service web.

Aussi, la génération d'une clé unique ou du certificat par l'utilisateur automatiquement sur la première connexion ne permet pas à tous. Après un attaquant de la rétro-ingénierie de votre protocole, il sait comment gérer tout cela, et n'a pas à jouer selon vos règles. Rien ne l'arrête de demander une nouvelle clé de votre serveur à chaque fois qu'il s'exécute en limitant la vitesse.

L'approche Kuba Wyrostek décrite pourrait travailler - faire au client de faire quelques consommatrice de temps de calcul, vous pouvez rapidement vérifier avant d'autoriser la demande soit traitée. Mais cela ne peut pas prendre trop de temps ou vos utilisateurs se plaignent de la réduction de la vie de la batterie. Aussi un attaquant va probablement utiliser plus puissants ordinateurs de bureau, matériel plutôt qu'un autre iPhone.

Et un dernier point - pensez-vous vraiment que cela est nécessaire? Vous ne voulez pas que vos utilisateurs disposent de registre, de sorte que vos données ou d'un service ne peut pas être trop important. Donc, ce que les gens ont à gagner de reverse-engineering de votre application et inonder votre serveur avec des requêtes?

Answer 4

En fait, j'ai été à la recherche d'une raison de mettre en œuvre quelques-unes de ces idées. Excellente question et de réponses.

Je suis d'accord avec @Kuba Wyrostek concernant le traitant comme un problème de spam est une partie de la solution. Surtout si votre application dispose les messages textuels (ajout d'un magasin, d'un service, ou d'un message), vous pouvez trouver une raison commune pour le spam de votre application serait de faire de la publicité quelque chose. Qui mènerait à ma première recommandation:

1) Traiter chaque message de la validité en tant que pourcentage de 0% à 100% valide. Élaborer un processus sur le côté serveur avec heurestics pour marquer le message comme plus ou moins valables. Cela vous permettra de cibler certaines des méthodes supplémentaires (comme par exemple forcer un client à calculer une valeur complexe) pour que les demandes pour lesquelles il est nécessaire. Vous pouvez aussi plus facilement enregistrer et examiner d'éventuels abus (et plus facile à nettoyer que les abus après c'est ciblée).

Vos applications ont un fort avantage sur les serveurs de messagerie dans la guerre du spam, cependant - vous contrôler les deux côtés de la conversation. Cette situation me fait penser à deux autres situations que vous pourriez trouver utiles: le satellite de TÉLÉVISION à péage, les "guerres" et de messagerie Instantanée d'un clone wars". (Référence Jeff Atwoods post sur le Noir du dimanche de hack, par exemple). Voici quelques idées à partir de ces espaceurs qui pourraient vous aider à obtenir un peu en avance sur le jeu du chat et de la souris:

2) demander au client d'envoyer des données supplémentaires - plus de données à propos de la demande comme du sens. Sur iOS, envoyer les mesures de précision de la localisation. Sur Android, vous pouvez réellement obtenir des premières données de GPS tels que des éphémérides de l'information. Vous pouvez ensuite (peut-être pas tout de suite, mais plus tard), commencer à vérifier ces données pour la validité. Cette force quelqu'un d'ingénierie inverse de la demande de travail beaucoup plus difficile. Si l'on envoie des satellites GPS en vue, par exemple, vous pouvez vérifier que contre publiquement connue de données pour confirmer.

3) la Force de votre adversaire sur le périphérique mobile - @Sven notes, l'attaquant peut utiliser un ordinateur de bureau, ce qui signifie un "gourmand en ressources" demande pourrait devenir trivial. Ne les laissez pas faire cela (ou au moins de les faire travailler plus dur). Vous pouvez, par exemple, demander au client de calculer certaines fonctions mathématiques (envoyé par le serveur), et de voir, basé sur le modèle de téléphone, si elle a le bon nombre de millisecondes pour terminer. Ou faire un petit rendu 3D de la tâche avec les données à partir du serveur, qui s'appuie sur du matériel d'écrêtage comportement. Hacher le résultat et l'envoyer de nouveau. L'ensemble de ces serait dans une fourchette - c'est un OS multitâche. Mais cela aiderait énormément.

4) Allez dynamique sur eux - Envoyer les bits de l'algorithme qui doivent être calculées dans le contexte du client. Apple devient un peu drôle au sujet de code à distance pour être interprétés, mais quelque chose comme l'envoi d'un peu de javascript qui n'a pas rendu à l'utilisateur. Ce code pourrait poser toutes sortes de questions (résolution d'écran, la version du navigateur, WebKit bizarreries) qu'il serait difficile de prévoir à l'avant. Comme ils se rattraper, vous pouvez obtenir plus de créativité avec ces.

5) CAPTCHA - Si votre heuristiques commencer à voir soupçonner de données, de les forcer à s'authentifier. Si vous avez une application multilingue, il pourrait être aussi simple que la contrepartie d'une image ou de caractères unicode en une autre. L'afficher dans une manière que vous pouvez mettre à jour plus tard.

De toute façon - quelques idées supplémentaires. Bonne chance!

Answer 5

La façon la plus simple à mettre en œuvre la limitation du débit sur le côté serveur est de simplement utiliser un serveur web plugin/module. Par exemple, si votre service est en cours d'exécution sur un serveur apache, d'installer et de configurer mod_evasive. Cela vous permettra de taux limite en fonction de l'adresse IP, le service/l'URL, etc. Mod Évasif sera plus efficace que ce que vous pouvez appliquer sur votre propre.

Si vous utilisez des clés, vous devez avoir une sorte de captcha base moyen pour le client à la remise des clés au moment de l'inscription. Vous pourriez avoir déposer des comptes pour les utilisateurs abusifs. Droit, bien sûr un paramètre serait l'horodatage qui serait vérifiée récent et, dans le passé, sur le côté serveur. La clé serait de chiffrer l'ensemble de la charge utile ainsi que le timestamp, et être ajouté comme un paramètre supplémentaire. Le stockage de la fréquence des requêtes sur une base clés en finit exigeant une sorte de round-robin de la base de données, à moins que vous ne vérifiez la validité de la dernière demande.

Pas purement côté client, le taux limite qui fera toute la différence. Quelqu'un pourrait découvrir votre API sur le web sans même avoir vu votre client. Je doute qu'un secret partagé serait efficace pour longtemps.

Vous y trouverez de nombreux services web qui ne nécessitent pas un mot de passe et sont simplement limitée par la vitesse de... par exemple, l'API twitter offre de nombreuses limitée dans le taux d'accès non authentifié de l'API de services.