2010-04-05 20 views
6

ho http://example.com/index.html, che dall'interno del HTML utilizza JavaScript (XmlHttpRequest) per chiamare un web service in http://example.com/json/?a=...&b=...Come limitare l'accesso al mio servizio web?

restituisce il servizio Web per index.html una matrice JSON di informazioni che devono essere poi visualizzato sul index.html.

poiché chiunque può visualizzare il codice sorgente per index.html e vedere come sto chiamando il servizio web JSON (http://example.com/json/), Come posso evitare di persone da chiamare direttamente il mio servizio web JSON?

Dal momento che il servizio Web è essenzialmente un open leggere nel mio database, io non voglio che la gente di abusare del servizio web e iniziare il recupero dei dati direttamente dal servizio web, avviare DoS mio server, il recupero più informazioni rispetto dovrebbero, ecc ..

UPDATE:

non c'è un modo per limitare le richieste di http://example.com/json/ a venire solo dallo stesso server (IP) e richiesta di URL di http://example.com/index.html?

Significato, impossibile http://example.com/json/ rilevare che il Richiedente è ($_SERVER['REQUEST_URI'] == http://example.com/index.html) e consentire solo quello?

+2

Umm, ciao? Questa è esattamente la tua domanda che stiamo già rispondendo qui: http://stackoverflow.com/questions/2576734/how-to-prevent-direct-access-to-my-json-service – Matchu

+0

@Matchu, è simile ma non lo stesso (come notato anche dal commento di Joshua Smith sul post di StackOverflow collegato) – Hank

+0

"Come impedire l'accesso diretto al mio servizio JSON" == "come impedire che le persone possano chiamare direttamente il mio servizio JSON?". Ho notato che questa volta hai dato la motivazione, il che significa che possiamo effettivamente fornirti soluzioni alternative ragionevoli, ma è sempre la stessa domanda. – Matchu

risposta

0

Ci sono una vasta gamma di cose che puoi fare per aggiungere sicurezza al tuo servizio. Verifica questo out

0

Non è possibile proteggere correttamente un servizio Web richiamabile da javascript sul lato client.

È possibile provare la sicurezza attraverso tecniche di oscurità come l'obsolescenza di JavaScript, ma non fermerà qualcuno motivato.

4

Non esiste un modo semplice per impedire che. Se il tuo servizio non è estremamente popolare e quindi è probabile che sia l'obiettivo di attacchi denial of service, non mi preoccuperei.

Una cosa che mi è venuta in mente è l'uso di token usa e getta (valido per 10 o 100 richieste).

Altro approccio (ingenuo) sta verificando che l'intestazione X-Requested-With esiste nella richiesta, ma naturalmente può essere facilmente falsificata. Quindi, il mio consiglio è: non fare nulla se il problema non è reale.

Un'ultima idea: hash calc. L'idea è di richiedere al cliente un calcolo piuttosto costoso per ogni richiesta, mentre la convalida del calcolo sul lato server è economica. Per una singola richiesta il sovraccarico è molto piccolo, ma per le 1000 richieste potrebbe richiedere una quantità significativa di tempo della CPU. Non ho idea se hashcalc è stato utilizzato per prevenire i servizi web di DoS'ing. Alcuni anni fa è stato proposto come misura antispam, ma non è mai diventato popolare.

+0

In che modo un token usa e getta può essere generato da un file index.html? – Hank

+0

Bene, l'utente malintenzionato potrebbe comunque recuperare index.html per ottenere un nuovo token, quindi non è nemmeno una contromisura molto efficiente, a meno che non si limiti il ​​numero di token generati al minuto per ip, ecc. – jholster

+0

correlati a HTTP_X_REQUESTED_WITH, non credo è disponibile in tutte le lingue ... ad es PHP – Hank

1

La risposta è davvero semplice, utilizzare la protezione CSRF. http://en.wikipedia.org/wiki/Cross-site_request_forgery

Semplicemente, quando l'utente accede al sito (index.php), messo in sessione: CSRF = (RANDOM_HASH)

Chiedi per la richiesta JSON, example.com/json.php?hash=$_SESSION['CSRF']

E in JSON.php controlla se $_GET['hash'] corrisponde a $_SESSION['CSRF']

Semplice come quello ... È la soluzione lato server!

+5

L'idea è di impedire a un utente malintenzionato di accedere direttamente ai servizi. Il tuo approccio non lo risolverà. L'utente malintenzionato accederà semplicemente index.html, ottiene il token e successivamente effettua la chiamata direttamente al servizio per ottenere qualsiasi informazione desideri. –

+0

Suppongo che questo sarebbe un token una tantum. Come posso farlo senza bisogno di index.php, posso farlo solo con index.html? – Hank

+0

Il suffisso del file non ha importanza, ma CSRF richiede pagine "dinamiche", ovvero non può essere eseguito con file statici. – jholster

1

Vorrei tenere traccia degli indirizzi IP che effettuano le richieste. Se hai mai visto un gran numero di richieste provenienti dallo stesso IP, puoi bloccarlo o offrire un CAPTCHA.

Problemi correlati