Devi considerare diversi fattori qui. Spero che la tua chiave API abbia una scadenza? Anche se lo fa, è vulnerabile a un attacco di riproduzione se un avversario entra in possesso della tua richiesta HTTPS. Come rimedio, puoi introdurre un timestamp o un contatore alla tua richiesta.
Attacchi replica contro il contrappasso
Un timestamp può essere aggiunto al messaggio e crittografato insieme al resto del contenuto del messaggio. Il servizio può
recuperare il timestamp dopo la decrittografia del messaggio e fallire la richiesta se il timestamp è troppo vecchio per la soglia
questo è già stato concordato. Ciò riduce la finestra di opportunità per riprodurre una richiesta. Il lato negativo di questo approccio è che sia il server che il client devono essere sincronizzati con il tempo.
Un'alternativa a un timestamp è un contatore. Con
un contatore, non è necessario essere preoccupati per l'inclinazione tra gli orologi. Tuttavia, i clienti devono implementare a
contatore per garantire che il conteggio inviato in una richiesta sia maggiore del conteggio nella richiesta precedente almeno di uno e il numero
il server deve conservare una registrazione dell'ultimo contatore ricevuto. Naturalmente, il messaggio deve essere firmato in modo che un utente malintenzionato
non incrementa il contatore e riproduce il resto della richiesta.
Codice di autenticazione dei messaggi basato su hash per contrastare l'attacco MITM
Il meccanismo principale
per garantire l'integrità dei dati dei messaggi è un codice di autenticazione dei messaggi basato su hash (HMAC). HMAC è solo un pezzo
di dati creati tramite un algoritmo di hashing crittografico e una chiave segreta condivisa. Tuttavia, se il messaggio deve essere crittografato per riservatezza, è possibile aggiungere facilmente tale funzionalità
utilizzando la stessa chiave privata che utilizziamo per HMAC o puoi introdurre una nuova chiave specifica per la crittografia.
Quando un utente invia una richiesta, devi preoccuparti di seguire tre parametri importanti.
- La chiave pubblica, che è la chiave associata all'utente
- Il contatore
- Il Timestamp
Oltre ai parametri, la richiesta include una firma che garantisce che nessuno dei parametri sia
manomesso È possibile creare la firma basata non solo sui tre parametri ma anche sull'intero corpo
della richiesta se l'obiettivo è quello di assicurarsi che nulla nella richiesta venga modificato.
Per assicurarsi che nessuno manchi i parametri, possiamo includere un HMAC-SHA256 di tutti e tre i valori più il
richiesta metodo URI e HTTP.
Puoi inserire i seguenti 4 attributi nella tua intestazione.
X-KEY
Questa è la tua chiave API
X-Firma
Se il valore inviato dall'applicazione client in X-Signature corrisponde a HMAC-SHA256 del file
i valori di X-KEY, X-Counter, X-Stamp, URI di richiesta e il metodo HTTP, possiamo tranquillamente concludere
che nulla è stato alterato durante il trasporto.
X-Stamp
Vengono confrontati il valore inviato dal client e l'ora UNIX dell'ora corrente. Se la
l'inclinazione tra questi due è entro il limite di tolleranza consentito, la richiesta non è un replay.
Il tempo UNIX è il numero di secondi trascorsi dalla mezzanotte del 1 gennaio 1970 Coordinato
Universal Time (UTC).
X-Counter
Se il valore inviato dal client è maggiore dell'ultimo contatore ricevuto nel record tenuto da
il server, la richiesta non è un replay. Anche se io uso sia il timestamp che il contatore in
esempio di implementazione in questo capitolo, uno in genere è abbastanza buono, a seconda del tuo
esigenze. Se i tempi di clock sono ragionevolmente sincronizzati, un timestamp è l'approccio migliore perché non c'è
sovraccarico in termini di memorizzazione del contatore nel lato dell'API Web o incremento nel lato client.
conclusione
È meglio utilizzare già framework collaudati come OAuth per soddisfare le tue necessità. Ma se pensi che sia troppo complesso, devi considerare le cose che vengono spiegate in questa risposta.