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

Devo progettare un "widget", uno script che i partner inseriranno nei loro siti Web per visualizzare alcune UI ed effettuare chiamate alla nostra API.

Fondamentalmente mostrerà i nostri dati su questi siti in base ad alcuni ID che forniscono nelle nostre chiamate API. Quello che vorremmo evitare è qualcuno che abusa dell'API e lo utilizza per raschiare l'intero catalogo.

A ciascun partner che incorpora il nostro script verrà fornita una chiave pubblica che deve essere fornita quando si chiama l'API. Un'idea sarebbe quella di chiedere loro di aggiungere questa chiave durante il caricamento dello script, ad esempio:

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

In questo modo la richiesta per lo script può essere utilizzata per registrare la coppia IP chiave / sorgente e rispondere alle successive chiamate API solo se la coppia chiave / IP corrisponde a una registrata (con una durata limitata e un limite di richieste al giorno).

Non sono sicuro che sia una buona idea poiché è ovviamente sicurezza attraverso l'offuscamento (qualcuno che ricarica la sceneggiatura la ignorerà completamente); ma non vedo nessun altro modo per limitare l'accesso. Non posso fornire una chiave univoca per ogni utente, solo per i partner. Non riesco a usare un sistema a chiave privata poiché tutto il codice sarà disponibile per chiunque. Fondamentalmente sta limitando l'accesso a un'API pubblica, cioè contraddittoria nella sua definizione.

Cosa ne pensi di questa soluzione e cosa faresti con questi vincoli?

Hai bisogno di diversi tipi di protezione.

Innanzitutto , è necessario impedire che la chiave del sito A venga utilizzata sul sito B.

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

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

In secondo luogo , è necessario impedire a Hacker Hank di aprire la console di debug o di utilizzare un client modificato sul sito A per fare ciò che desidera con l'API.

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

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

In terzo luogo , come probabilmente già stai facendo: crittografare il traffico. Certo, l'NSA lo vedrà; ma Hacker Hank ha meno probabilità di farlo.

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

I ragazzi della sicurezza con cui lavoro di solito ignorano l'indirizzo IP perché l'IP è falsificabile. 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 effettuate con TLS (ovvero SSL o https) e 2) gli IP vengono inseriti nella whitelist. Quindi farò una dichiarazione in grassetto e dirò che penso che passeresti una revisione della sicurezza, anche per le interazioni PCI (carta di credito).

IMHO ... Ma se stai solo cercando di proteggere le informazioni di proprietà dell'azienda anziché le carte di credito (PCI) o le informazioni personali / private (PII), allora questo è probabilmente buono anche anche senza SSL, a seconda di quanto stai disposto a rischiare di esporre il tuo catalogo.

O così: con SSL, un hacker dedicato non è riuscito a ottenere il tuo catalogo. (A meno che non rompano SSL, ma potrebbero anche rompere Amazon). Senza SSL, un hacker dedicato potrebbe sniffare le tue chiamate, falsificare l'IP e abbattere il tuo catalogo. Quindi è una specie di giudizio sul rischio.

Sto cercando di pensare a un modo per rinunciare alla whitelist IP perché di solito è un problema da gestire;) senza andare a OAuth in piena regola. Lo taglierò.