10
votes

Comment empêcher un accès direct à mon service JSON?

J'ai un service Web JSON pour renvoyer des marqueurs à la maison pour être affiché sur ma carte Google.

essentiellement, http://example.com appelle le service Web pour connaître l'emplacement de l'emplacement de tous les marqueurs de carte à afficher comme si: xxx

et il renvoie une chaîne JSON telle que: xxx

donc sur mon index.html page, je prends cette chaîne JSON et placez les marqueurs de carte.

Cependant, ce que je ne veux pas avoir lieu, c'est que les gens appellent à mon service Web JSON directement .

i seulement je veux http://example.com/index.html pour pouvoir appeler mon http: // Exemples.com/json / Service Web ... et pas un mec aléatoire appelant le / json /

Quesiton : Comment puis-je empêcher l'appel direct / accès à mon http://example.com/json/ service Web?


Mise à jour: < / p>

donner plus de clarté, http://example.com/index.html appel http://example.com/json/?zipcode=12345 ... et le service JSON
- renvoie des données semi-sensibles,
- retourne un tableau JSON,
- répond aux demandes d'obtenir,
- Le navigateur apportant la demande est activé

à nouveau, ce que je ne veux pas avoir se produire est des gens simplement regarder mon index.html code source, puis Appelez directement le service JSON.


0 commentaires

6 Réponses :


3
votes

Si vous utilisez Apache, vous pouvez définir Autoriser / nier sur des emplacements.

http://www.apachesecurity.net/

ou voici un lien vers les documents Apache sur la directive de Refa

http://httpd.apache.org/docs/2.0 /mod/mod_access.html#deny

Edits (répondant à la nouvelle information).

La directive Deny fonctionne également avec des variables d'environnement. Vous pouvez limiter l'accès en fonction de la chaîne de navigateur (pas vraiment en sécurité, mais décourage la navigation occasionnelle) qui permettrait toujours des appels XHR.

Je suggérerais que la meilleure façon d'accomplir est d'avoir un jeton d'une sorte qui valide la demande est une «bonne» demande. Vous pouvez le faire avec un cookie, une session Store de type ou un paramètre (ou une combinaison).

Ce que je suggérerais de quelque chose comme ceci est de générer une URL unique pour le service expire après une courte période de temps. Vous pouvez faire quelque chose comme ça assez facilement avec Memcache. Cette stratégie pourrait également être utilisée pour obscurcir l'URL de service (qui ne fournirait aucune sécurité réelle, mais souleverait la barre de quelqu'un qui souhaite apporter des appels directs).

Enfin, vous pouvez également utiliser la crypto de clé publique pour le faire, mais ce serait très lourd. Vous auriez besoin de générer une nouvelle paire de clés PUB / privé pour chaque requête et de renvoyer le pubkey au client JS (voici un lien vers une implémentation dans JavaScript) http://www.cs.pitt.edu/~kirk/cs1501/notes/rsademo/


5 commentaires

Lorsque les gens disent "JSON" dans le contexte d'une page Web, ils signifient généralement XHR, qui refuse de bloquer s'ils sont utilisés indistinctement.


Je crois que si j'ai utilisé cette méthode, cela refuserait tout le monde accès à mon site Web. ... signification, cela ne fonctionnerait pas


Il ne ferait que refuser à tous l'accès à votre site Web si vous avez spécifié pour nier tout le monde. Vous pouvez ajouter NYY / Autoriser en fonction de l'emplacement.


... et là où les pirates pirates vont-ils venir de Josué?


De sa question initiale (avant les modifications), il me ressemblait comme s'il voulait restreindre l'accès à ce service de manière à ce que seul le serveur puisse appeler le service. Il a ajouté des modifications qui clarifient et maintenant que l'interprétation n'est clairement pas correcte.



1
votes

Acceptez uniquement les demandes de poste à l'URL de céder JSON. Cela n'empêchera pas les personnes déterminées d'y arriver, mais cela empêchera la navigation occasionnelle.


3 commentaires

Comment faire de l'article XMLHTTPQUEST? Je pensais que vous ne pouviez que faire des demandes.


XMLHTTPQUEST peut faire n'importe quelle méthode, y compris les méthodes que vous maquillez. Le premier paramètre lorsque vous ouvrez une demande est la méthode, qui est une chaîne arbitraire.


J'utilise quelque chose comme JQuery qui sait poster xhr. API.JQUERY.com/JQUERY.POST



-1
votes

Vous devrez probablement avoir une authentification basée sur les cookies. De plus, Ignacio a un bon point sur l'utilisation de l'article. Cela peut aider à prévenir JSON Dijacking si vous avez des scripts non carrés en cours d'exécution sur votre domaine. Cependant, je ne pense pas que l'utilisation de l'article soit strictement nécessaire à moins que le type JSON le plus externe soit un tableau. Dans votre exemple, c'est un objet.


3 commentaires

La raison de l'utilisation de l'article n'est pas une sécurité. C'est due au fait que les navigateurs de méthode par défaut utilisent lorsque vous tracez une URL dans la barre de localisation. Si vous obtenez n'est pas autorisé sur le serveur, ils ne voient pas le JSON.


Ignacio, jetez un coup d'œil à mon lien. La poste peut aider à vaincre une attaque de détournement de JSON particulière.


Sûr. Mais ce n'est pas pourquoi je l'ai suggéré.



10
votes

Il y a quelques bonnes façons d'authentifier les clients.

  • par adresse IP. Dans Apache, utilisez les directives Autoriser / Refuser.
  • Par HTTP Auth: Basic ou Digest. C'est bien et normalisé et utilise des noms d'utilisateur / des mots de passe pour s'authentifier.
  • par cookie. Vous devrez trouver le cookie.
  • par une en-tête HTTP personnalisée que vous inventez.

    EDIT:

    Je n'ai pas saisi d'abord que votre service Web est appelé par code côté client. Il n'est littéralement pas possible d'empêcher les personnes d'appeler directement votre service Web, si vous laissez le côté du client JavaScript le faire. Quelqu'un pourrait simplement lire le code source.


4 commentaires

Ne serait pas autorisé / nier pas travailler parce que cela refuserait tout le monde à index.html qui appelle la demande JSON.


Dietrich, exactement - Les personnes qui lisent mon code source sont la préoccupation. Donc aucun moyen de prévenir?


Correct, aucun moyen de prévenir. C'est comme remettre quelqu'un un ensemble de clés et leur dire qu'à ouvrir la porte le jeudi.


Accepté, aucun moyen de prévenir. Les autres threads ont également discuté de cela - stackoverflow.com/questions/2561999/... et Stackoverflow.com/questions/2576509/...



5
votes

Quelques réponses plus spécifiques ici, mais j'aimerais faire le point général suivant:

Tout ce qui est fait sur Ajax est chargé par le navigateur de l'utilisateur. Vous pouvez faire la vie de la pirate hardère si vous le souhaitez, mais, finalement, Il n'y a aucun moyen de m'empêcher d'obtenir des données que vous mettez déjà librement à votre disposition . Tout service disponible au public est public, simple et simple.


0 commentaires

2
votes

Vous pouvez ajouter un numéro aléatoire sous forme de drapeau pour déterminer si la demande provenait de la page vient d'envoyer:

1) Lorsque génère index.html , ajoutez un numéro aléatoire à l'URL de la demande JSON:

Old: http://example.com/json/?zipcode=12345

Nouveau: http://example.com/json/?zipcode=12345&f=234234234234234234

Ajouter ce numéro au contexte de la session aussi.

2) Le navigateur client rend le index.html et demandez des données JSON par la nouvelle URL.

3) Votre serveur obtient la requête JSON et vérifie le numéro d'indicateur avec Session Contexte . Si correspondance, des données de réponse. Sinon, renvoyez un message d'erreur.

4) Effacer Contexte de la session à la fin de la réponse ou à un délai déclenché.


0 commentaires