Come evitare l'uso non autorizzato di un'API?

Hai bisogno di diversi tipi di protezione.

In primo luogo , devi impedire che la chiave di Site A venga utilizzata sul sito B.

In teoria, se la chiave è associata a un dominio, non puoi dipendere dall'intestazione referer , ma poiché il client è incorporando direttamente uno script, puoi fare affidamento su document.location sul lato client. L'invio diretta di tale posizione (o parte di esso) al server non è affidabile; ma puoi usarlo per generare una chiave di sessione:

1. Il client incorpora client_key nella richiesta per la libreria API.
2. Il server determina l'host che ha accesso all'API, se presente.
3. Il server seleziona "sale" per una chiave di sessione e lo invia al client con la libreria [o come parte di un altro scambio di pre-autorizzazione].
4. Il client calcola un session_key utilizzando hash(document.location.host + session_salt) .
5. Il client utilizza session_key + client_key per una chiamata API.
6. Il server convalida la chiamata controllando l'host client_key e "salt" nella sessione, calcolando l'hash e confrontando il client_key fornito.

In secondo luogo , devi impedire a Hacker Hank di aprire la console di debug o utilizzare un client modificato sul sito A per fare quello che vuoi con la tua API.

Nota comunque, che è molto difficile, se non impossibile, impedire a completamente Hacker Hank di abusare dell'API. Ma puoi renderlo più difficile. E il modo più ragionevole per impedire Hank, di cui sono a conoscenza, è la limitazione dei tassi.

• Limita il numero di richieste / secondo / sessione e richieste / ora / sessione. (I picchi di attività sono probabilmente ragionevoli, ma non il sostenuto traffico superiore alla media da un singolo client.)
• Limita il numero di sessioni / IP / ora.
• Limita il numero di richieste / IP / ora. Consenti picchi, ma non sostenuto da un traffico intenso da un singolo IP.

Terzo , come probabilmente stai già facendo: crittografare il traffico. Certo, l'NSA lo vedrà; ma Hacker Hank è meno probabile.

Sembra che tu stia facendo qui rendendo i tuoi file javascript in risorse protette. E raggruppandolo con una sorta di generazione di token allo stesso tempo. È interessante.

I tipi di sicurezza con cui lavoro di solito ignorano l'indirizzo IP perché l'IP è spoofabile. Ma se stai usando una restrizione IP combinata con SSL, questo di solito fa il trucco.

Ma devi "autorizzare" gli indirizzi IP, altrimenti qualsiasi hacker può semplicemente entrare dalla porta principale.

Ero scettico, ma in realtà sto pensando che il tuo schema funzioni abbastanza bene. Se 1) il file .js e le successive chiamate API vengono eseguite con TLS (ad esempio SSL o https) e 2) gli IP sono autorizzati nella whitelist. Poi farò una dichiarazione audace e dirò che penso che avresti passato una revisione della sicurezza, anche per le interazioni PCI (carta di credito).

IMHO ... Ma se stai solo cercando di proteggere le informazioni proprietarie della società invece della carta di credito (PCI) o delle informazioni personali / private (PII), probabilmente questo è anche buono anche senza SSL, a seconda di quanto sei disposto a rischiare di esporre il tuo catalogo.

O mettilo in questo modo: con SSL, un hacker dedicato non potrebbe ottenere il tuo catalogo. (A meno che non infrangono il protocollo SSL, ma potrebbero anche distruggere Amazon). Senza SSL, un hacker dedicato potrebbe annusare le tue chiamate, spoofare IP e abbattere il tuo catalogo. Quindi è una sorta di giudizio sul rischio.

Sto cercando di pensare a un modo per fare a meno della whitelist IP perché di solito è un problema da gestire;) senza andare a OAuth in piena regola. Lo farò su questo.