2010-04-05 5 views
6

je http://example.com/index.html, qui à partir du HTML utilise JavaScript (XMLHttpRequest) pour appeler un service Web à http://example.com/json/?a=...&b=...Comment limiter l'accès à mon service Web?

Les retours de service Web pour index.html un tableau JSON d'informations pour être ensuite affichées sur index.html.

Comme tout le monde peut voir le code source pour index.html et voir comment j'appelle le service Web JSON (http://example.com/json/), comment empêcher les gens d'appeler mon JSON service Web directement?

Depuis le service Web est essentiellement un ouvert lire dans ma base de données, je ne veux pas que les gens abusent du service Web et de commencer la récupération des données directement à partir du service Web, commencez DoS mon serveur, aller chercher plus d'informations que ils devraient, etc ..

MISE à JOUR:

Yat-il aucun moyen de limiter les demandes de http://example.com/json/ à ne proviennent du même serveur (IP) et demande d'URL de http://example.com/index.html? Cela signifie que http://example.com/json/ ne peut pas détecter que le demandeur est ($_SERVER['REQUEST_URI'] == http://example.com/index.html) et ne le permet que?

+2

Euh, bonjour? C'est exactement votre question que nous répondons déjà ici: http://stackoverflow.com/questions/2576734/how-to-prevent-direct-access-to-my-json-service – Matchu

+0

@Matchu, c'est similaire mais pas le même (comme même noté par le commentaire de Joshua Smith sur l'article StackOverflow lié) – Hank

+0

"Comment empêcher l'accès direct à mon service JSON" == "comment empêcher les gens d'appeler mon service Web JSON directement?". J'ai noté que cette fois vous avez donné la justification, ce qui signifie que nous pouvons réellement vous donner des solutions alternatives raisonnables, mais c'est toujours la même question. – Matchu

Répondre

0

Il y a un large éventail de choses que vous pouvez faire pour ajouter de la sécurité à votre service. Cochez cette case out

0

Vous ne pouvez pas sécuriser correctement un service Web pouvant être appelé depuis le javascript côté client.

Vous pouvez essayer la sécurité grâce à des techniques d'obscurité telles que l'obscurcissement javascript, mais cela n'empêchera pas quelqu'un de motivé.

4

Il n'y a pas de moyen facile d'empêcher cela. Si votre service n'est pas extrêmement populaire et cible donc probablement des attaques par déni de service, je ne m'en soucierais pas. Une des choses qui me vient à l'esprit est l'utilisation de jetons jetables (valable pour 10 ou 100 demandes).

Une autre approche (naïve) consiste à vérifier que l'en-tête X-Requested-With existe dans la requête, mais bien sûr cela peut être facilement falsifié. Donc, mon conseil est: ne rien faire à moins que le problème est réel.

Une idée de plus: hash calc. L'idée est d'exiger que le client effectue un calcul plutôt cher pour chaque requête, alors que la validation du calcul côté serveur est bon marché. Pour une seule requête, le surcoût est très faible, mais disons que pour 1000 requêtes, cela peut prendre beaucoup de temps CPU. Je n'ai aucune idée si hashcalc a été utilisé pour empêcher les services Web DoS. Il y a quelques années, il a été proposé comme mesure antispam, mais il n'est jamais devenu populaire.

+0

Comment un jeton jetable fonctionnerait-il et serait-il généré à partir d'un fichier index.html? – Hank

+0

Eh bien, l'attaquant pourrait de toute façon relancer index.html pour obtenir un nouveau jeton, donc ce n'est pas non plus une contre-mesure très efficace, sauf si vous limitez le nombre de jetons générés par minute par ip. – jholster

+0

Relatif à HTTP_X_REQUESTED_WITH, je ne crois pas c'est disponible dans toutes les langues ... par exemple PHP – Hank

1

La réponse est vraiment simple, utilisez la protection CSRF. http://en.wikipedia.org/wiki/Cross-site_request_forgery

Simplement, lorsque l'utilisateur vient sur votre site (index.php), mis en séance: CSRF = (RANDOM_HASH)

Demandez demande JSON, example.com/json.php?hash=$_SESSION['CSRF']

Et en JSON.php vérifier si $_GET['hash'] correspond à $_SESSION['CSRF']

Simple comme ça ... C'est la solution côté serveur!

+5

L'idée est d'empêcher un attaquant d'accéder directement aux services. Votre approche ne résoudra pas cela. L'attaquant accédera simplement à index.html, obtiendra le jeton et fera ensuite l'appel directement au service pour obtenir toutes les informations qu'il souhaite. –

+0

Je suppose que ce serait un jeton unique. Comment puis-je faire cela sans index.php, puis-je le faire avec index.html? – Hank

+0

Le suffixe de fichier n'a pas d'importance, mais CSRF requiert des pages "dynamiques", c'est-à-dire ne peut pas être fait avec des fichiers statiques. – jholster

1

Je garderais une trace des adresses IP faisant les demandes. Si vous avez déjà vu un grand nombre de demandes provenant de la même adresse IP, vous pouvez le bloquer ou offrir un CAPTCHA.

Questions connexes