In che modo Google Maps protegge la chiave API? Come fare qualcosa di simile?

Question

Attualmente Google richiede la creazione di una chiave API specifica per il dominio da cui verrà servita la mappa. In che modo Google applica questo? Voglio fare la stessa cosa

Espongo un'API per il mio servizio ma voglio consentire ai client di incorporare le chiamate all'API tramite javascript e non solo dal server. Potrei proteggerlo con un semplice token casuale, ma ovviamente questo potrebbe essere facilmente falsificato da chiunque guardi il codice sul computer client.

Ho sempre capito che questo concetto non è possibile ma in qualche modo Google fa un buon lavoro nel rafforzarlo.

Modifica - Sembra che Google non abbia davvero fatto niente di straordinario dopo tutto. La loro API è molto probabilmente solo per il monitoraggio e non per garantire realmente che la loro API sia utilizzata dalla persona con la chiave.

Answer 1

Sono abbastanza sicuro che utilizzano l'URL REFERER per determinare da dove proviene la chiamata. Se il dominio non corrisponde a ciò che viene assegnato alla chiave, si tratta di una richiesta non valida.

Per un esempio pratico, utilizzando PHP è possibile controllare il dominio utilizzando $_SERVER['HTTP_REFERER'] per controllare il referente. Se il dominio corrisponde, restituire una risposta valida. In caso contrario, è possibile restituire una risposta non autorizzata 401 o altra.

Answer 2

Il motivo per cui funziona è che non è possibile effettuare chiamate API con javascript. La sicurezza del browser impedisce a javascript di effettuare richieste ovunque tranne che nel dominio da cui proviene il javascript. Per questo motivo, tutte le chiamate API da javascript devono essere rimbalzate sul server in cui è memorizzata la chiave API (la chiave API non viene mai vista da javascript).

Answer 3

Come il mio commento dice:

il referer è spoofing, quindi probabilmente è improbabile che Google utilizzerà come mezzo di verifica. Vedi this wikipedia entry.

La mia ipotesi è che Google utilizzi probabilmente l'indirizzo IP del chiamante insieme a una ricerca DNS. Il DNS non è realmente falsificabile, dal momento che le tue voci DNS devono essere corrette affinché il sito web possa arrivare anche a te.

Ma, anche questo ha i suoi problemi, perché se un server utilizza una configurazione Indirizzo DNS Round-Robin IP, Google verrà reindirizzato a un indirizzo IP diverso quando si fa una ricerca DNS.

Dalla FAQ

Si noti che una chiave per http://www.mygooglemapssite.com/ sarà accettata solo se il sito è accessibile tramite questo indirizzo. Non sarà accettato se si accede al sito tramite l'indirizzo IP (ad esempio http://10.1.2.3/) o tramite un nome host che è sottoposto a alias su www.mygooglemapssite.com utilizzando un record CNAME DNS.

La mia ipotesi è che potrebbero utilizzare il Host intestazione che viene inviata al momento della richiesta della pagina, che avrebbe funzionato come normalmente Google chiede di includere è API script direttamente nella pagina. Quindi quello script ha accesso alle intestazioni per la pagina corrente e può usarlo per controllare.

La mia ipotesi è supportata dal fatto che non funziona per gli indirizzi IP o gli alias, il che significa che non sta facendo un controllo DNS.

Questo metodo non può essere falsificato, in quanto deve essere l'intestazione corretta per accedere alla pagina. Tuttavia, questo significa che qualsiasi alias del dominio non funzionerà.

Tuttavia, questo significa anche che è necessario fornire una libreria Javascript per accedere al codice, poiché non è possibile controllare questo lato server, credo.

Answer 4

La chiave API stessa è molto probabilmente un hash unidirezionale del dominio a cui è associata la chiave e un segreto di cui solo il server API di Google è a conoscenza. Può contenere altri pezzi di informazioni ben note (a Google ovviamente). Quando si effettua una richiesta da tale dominio, il server API accetta il dominio da cui proviene la richiesta e esegue lo stesso calcolo hash unidirezionale e confronta i due valori.

Per le chiamate Ajax, molto probabilmente usano il referrer per ottenere il dominio dell'host del documento. Mentre il referrer può essere falsificato, in ultima analisi, al fine di utilizzare l'API, è necessario ottenere il javascript di Google per l'esecuzione nel documento. A questo punto, questo javascript può verificare che il documento che ha invocato la chiamata all'API Ajax sia stato originato dal server di destinazione. Naturalmente è anche possibile effettuare lo spoofing, a condizione che tu abbia la tua implementazione DOM o modifica al volo della sceneggiatura. Tuttavia, questo spoofing deve avvenire sul lato client e le probabilità che il sito Web che vuole utilizzare l'API di Google sia in grado di falsificare il software del client sono piuttosto piccoli.

Si noti che poiché l'API è essenzialmente gratuita, potrebbe offrire anche l'accesso anonimo alle proprie API. Apparentemente l'intento di Google non è quello di proteggere l'accesso non autorizzato ad esso, ma di garantire che possano raccogliere quanti più dati possibili sull'utilizzo di tali dati e di poter associare tale utilizzo con altri dati raccolti sul dominio di destinazione. Pertanto, non mi aspetto che la verifica delle chiavi API sia molto più complessa di quanto ho descritto sopra: il ROI su un approccio più avanzato è troppo basso.

E ovviamente c'è anche la preoccupazione di possibili attacchi XSS attraverso la loro API. Ma non credo che la loro chiave API sia troppo legata a qualsiasi codice anti-XSS che hanno.

Answer 5

Sono d'accordo con tutti i punti elencati da Franci Penov. Mi piacerebbe elaborare un po 'sull'utilizzo della chiave API di qualcun altro. Supponiamo di registrare la chiave 1 con http://mysite.com.

1) Primo tentativo - Se anothersite.com ha script src = http://www.google.com/jsapi?key=key1, google potrebbe controllare il referrer (schema di hash menzionato) e in questo caso c'è una mancata corrispondenza. Come fa l'aggressore malvagio a superarlo - molte persone hanno detto che i referenti possono essere falsificati. Questo non si applica davvero qui. Certo, potresti inviare intestazioni arbitrarie se fai la richiesta, ma come fa l'hacker malvagio a falsificare il referrer per gli utenti su anothersite.com - questo in generale non è facile. Ci sono state vecchie versioni di flash su IE 6 che consentivano a un attaccante di impostare intestazioni arbitrarie durante le richieste di domini incrociati, ma in generale non è fattibile per lo script src. Non sono sicuro se il js incluso fa alcuna convalida di document.location per prevenire questo (probabilmente no).

2) Secondo tentativo - l'autore malintenzionato copia google javascript per la chiave API dall'origine della pagina mysite.com e quindi incorpora il javascript modificato su anothersite.com. Ora google non può controllare nulla (l'IP remoto sarà il computer dell'utente e non c'è molto che tu o Google possa fare).

Quindi, se si desidera mantenere la chiave API segreta (un motivo, la persona malintenzionata può ottenere la chiave nella blacklist/bloccata), non inserire la chiave nelle richieste client e proxy tramite il server (l'applicazione il codice ora ha la chiave).