1. Accueil
  2. Question et réponse
  3. Ordonnateur REST Demandes

Ordonnateur REST Demandes

2008-10-27 7 views
12

Je travaille sur un service REST qui a quelques exigences:Ordonnateur REST Demandes

  1. Il doit être sécurisé.
  2. Les utilisateurs ne devraient pas être en mesure de forger des demandes.

Ma solution actuelle proposée est d'avoir un en-tête d'autorisation personnalisé qui ressemble à ceci (ce qui est de la même façon que le travail de services Web amazon):

Authorization: MYAPI username:signature

Ma question est de savoir comment former la signature . Lorsque l'utilisateur se connecte au service, il reçoit une clé secrète qu'il devrait pouvoir utiliser pour signer des demandes. Cela empêchera les autres utilisateurs de soumettre des demandes en leur nom, mais ne les empêchera pas de falsifier des demandes.

L'application qui utilisera ce service est une application iPhone, donc je pensais que nous pouvions avoir une clé publique intégrée dans l'application avec laquelle nous pouvons faire une signature supplémentaire, mais cela signifie-t-il que nous devrons avoir deux signatures, une pour la clé utilisateur et une pour la clé de l'application?

Tout conseil serait grandement apprécié, j'aimerais bien le comprendre dès la première fois.

Source

2008-10-27 jonnii

+0

Définir "demandes de forgeage". Quelle entité crée des demandes non falsifiées? Est-ce le logiciel côté client? – Alexander

Répondre

1

Je pense que la façon la plus simple d'y parvenir serait d'utiliser l'authentification client HTTPS. Le site d'Apple a un thread sur ce même sujet. Edit: pour gérer l'autorisation, je créerais une ressource distincte (URI) sur le serveur pour chaque utilisateur, et autoriserais seulement cet utilisateur (authentifié) à manipuler cette ressource.

Modifier (2014): Apple a changé son logiciel de forum au cours des six dernières années; le fil est maintenant à https://discussions.apple.com/thread/1643618

Source

2008-10-27 15:27:34

+0

Comment cela empêche-t-il les utilisateurs de falsifier des demandes? – jonnii

+0

L'authentification client HTTPS nécessite que le client dispose d'un certificat de clé publique valide. A moins que vous n'entendiez par "forger des requêtes" qu'un utilisateur authentifié fasse des demandes non autorisées, ce qui est un problème d'autorisation et non un problème d'authentification. –

+0

C'est le problème que j'essaie d'aborder, j'ai mis à jour le sujet pour refléter cela. Comment suggéreriez-vous d'autoriser des demandes valides? – jonnii

2

Quel est le problème avec HTTP Digest Authentication?

Source

2008-10-27 15:29:21

+0

Tout d'abord je vais devoir utiliser SSL pour les requêtes (ce qui est bien), mais cela n'empêche pas un utilisateur de se connecter à l'API à partir d'un appareil non iPhone et de soumettre des requêtes falsifiées. – jonnii

+0

Comment peuvent-ils forger une requête via l'authentification Digest? Comment ont-ils obtenu la valeur de nonce actuelle et créé une réponse de résumé acceptable? –

+0

Ils peuvent falsifier une requête car ils peuvent créer une application client tierce qui se connecte à l'API, à quel point ils peuvent soumettre leurs propres demandes. Je dois vérifier la source de la demande d'api. – jonnii

8

La réponse est simple: Il ne peut pas être fait. Dès que vous envoyez une solution à l'utilisateur final, il peut toujours attaquer le serveur avec lequel il communique. La version la plus courante de ce problème consiste à tricher avec des listes de scores élevés dans les jeux Flash. Vous pouvez rendre plus difficile en embarquant une sorte de cryptage dans le client et en obscurantant le code ... Mais tout le code compilé et obfusqué peut toujours être décompilé et non-brouillé. C'est juste une question de temps et d'argent que vous êtes prêt à dépenser et de même pour l'attaquant potentiel.

Donc, votre préoccupation est pas comment essayer d'empêcher l'utilisateur d'envoyer des données défectueuses à votre système. C'est comment empêcher l'utilisateur de endommager votre système. Vous devez concevoir vos interfaces de sorte que tous les dommages causés par des données défectueuses n'affectent que l'utilisateur qui les envoie.

Source

2009-05-01 09:04:32

+0

Dans ce cas, nous allons nous déployer sur l'iPhone, il y a donc un risque que quelqu'un décompose le code. Vous soulignez des points très valables dans votre message sur la limitation de la capacité à endommager uniquement les données des utilisateurs, dans ce cas, ils seraient en mesure de tricher dans un jeu, nous devons donc être en mesure d'identifier les tricheurs et de les traiter efficacement. Pas de tâche facile. – jonnii

+0

La seule façon de sécuriser le jeu av est de l'exécuter entièrement sur le serveur et d'envoyer uniquement les actions des utilisateurs sur le réseau. Ce que je fais habituellement est: 1. Rendre la tricherie difficile 2. Enregistrer autant d'informations que possible. Tricher est généralement assez facile à repérer, vous pouvez donc supprimer toutes les entrées pour cet utilisateur par la suite. –

+0

Si vous développez un JEU et que c'est un problème de CHEATING, alors vous avez toute une gamme d'outils à votre disposition - selon qu'il s'agisse d'un jeu d'adresse ou de jeu de hasard. D'une manière générale, les performances des joueurs peuvent être mesurées statistiquement et d'étranges modèles peuvent être repérés - c'est ainsi que de nombreux systèmes de détection de fraude fonctionnent dans l'industrie du divertissement. Une autre chose qui vient immédiatement à l'esprit est la conception algorithmique qui introduit certaines propriétés mesurables dans le jeu - par exemple, l'accumulation d'erreurs dans les nombres à virgule flottante. – mst

Questions connexes

 Questions connexes