Soluzione HMAC per un'API di riposo

Question

Soluzione HMAC per un'API di riposo

#1 da (6 voti)

8

Sto cercando di imparare alcune cose sugli apis REST e uno degli argomenti su cui sto riscontrando dei problemi è la sicurezza.

Sto usando angularjs per l'interfaccia web e il framework snello per php api. Ho letto alcuni articoli (mi è piaciuto questo ) e ha iniziato a implementare HMAC seguendo questo tutorial (non esattamente gli stessi passaggi). Mi piacerebbe sapere se c'è qualche grave violazione della sicurezza nel mio approccio o se non sto facendo questo nel modo giusto.

Poiché utilizzo AngularJS, so che tutto ciò che immagazzino nel lato client non è sicuro. Suppongo che l'utente abbia una macchina "pulita come nuova" e sappia cosa sta facendo (probabilmente sarò l'utente api principale). La mia più grande preoccupazione è l'uomo-in-the-middle e la replica.

(Sul lato client)

L'utente inserisce il nome utente e la password.
La sua password è crittografata (ad esempio, sha256) e archiviata come globale; (Il suo nome utente è appena memorizzato da qualche parte)
In ogni richiesta che l'interfaccia web invia all'api, viene inviato un hash hmac nell'intestazione in cui il messaggio è formato utilizzando il nome utente, un timestamp, il percorso della risorsa, una stringa casuale (che sia server che il client è consapevole, hardcoded) e la chiave è l'hash della password.

(Sul lato server)

Quando il server riceve la richiesta:

Controlla il timestamp;
Verifica se il nome utente esiste nel DB;
tenta di replicare lo stesso hash hmac utilizzando per il messaggio le variabili (anche ricevute nella richiesta) username, timestamp, path-to-resource e la stringa casuale (questa non è ricevuta nella richiesta, è solo hardcoded) . Per la chiave utilizza il valore memorizzato nel DB che è la password crittografata dell'utente specificato.

Se tutte le convalide vanno bene, l'utente dovrebbe essere un ragazzo di cui fidarsi e non solo un uomo-in-the-middle.

rest hmac man-in-the-middle

posta Bruno Camarneiro 12.03.2014 - 13:58

fonte

1 risposta

Leggi altre domande sui tag rest hmac man-in-the-middle

Libro moderno, attento alla sicurezza, in PHP? Messaggi di posta elettronica falsi tramite l'intestazione Elenco-annullamento sottoscrizione

score 6 · Accepted Answer

Vedo vari problemi con il tuo approccio (in nessun ordine particolare e molto probabilmente non un elenco completo):

Sembra che tu stia distribuendo l'applicazione senza SSL / TLS. In questo caso, non devi fare affidamento sul lato client, in quanto un MITM può sostituire l'implementazione lato client (sicuro) con qualsiasi cosa lui / lei scelga.

Non esiste un modo per creare un'applicazione web sicura senza SSL, in quanto il client carica la tua applicazione attraverso un canale non sicuro. Se la tua applicazione è distribuita attraverso un canale sicuro (non sei sicuro che angularjs supporti la distribuzione offline), ignorala.

Se si utilizza SSL, questo probabilmente mitigherà tutti gli altri scenari di attacco in quanto protegge da MITM e riproduce gli attacchi. L'unica cosa che potrebbe essere un problema è l'autenticazione, dato che non si usano i certificati client. Ma solitamente i token di sessione sono sufficienti per le applicazioni web, in quanto il server è correttamente autenticato (dato che usi un'implementazione corretta).
Desiderate proteggervi dagli attacchi di replay, ma usate solo timestamp per le richieste. Se un utente malintenzionato è in grado di registrare e rispondere a una richiesta abbastanza velocemente, il server considererà valida la richiesta. A seconda dei dati effettivi, questo potrebbe o meno essere un problema.

Per impedire questo attacco, aggiungi un contatore di richieste o memorizza il timestamp dell'ultima richiesta sul server (e richiedi un timestamp più grande di quello memorizzato).
Oltre al tuo HMAC attuale, non sei salting your passwords , in questo modo un utente malintenzionato con accesso al database è fatale per la tua applicazione e le password dell'utente. Ti consiglio vivamente di aggiungere le tue password.

Inoltre, è prassi abituale moltiplicare le password per aumentare il carico di lavoro richiesto per gli attacchi del dizionario contro l'hash.
Da ciò che scrivi non è chiaro che tu includa il messaggio / richiesta contenuto nel tuo HMAC. Ma presumo che tu sia a conoscenza del fatto che un HMAC verifica solo l'integrità dei dati con cui è generato.
Non usi le chiavi veramente casuali per gli HMAC. Data la potenza di calcolo di oggi, è probabile che password deboli conducano a un HMAC crackable, poiché gli hash possibili sono facili da calcolare. L'hashing di più turni potrebbe aiutare un pochino (e salare se l'attacco è contro più utenti), ma è fondamentale installare finalmente una brute force prevention (numero massimo di richieste illegali all'ora o simili, quindi bloccare l'IP sorgente).

Tuttavia, personalmente non mi fiderei mai di nulla solo in base alle password degli utenti.

Quindi, personalmente, ti consiglierei di non caricare la tua crittografia personale e di attaccare con SSL / TLS. Sebbene ciò significhi fondamentalmente che ogni CA fidata dal cliente possa certificare un MITM, ritengo che tale rischio sia di gran lunga inferiore rispetto a un MITM che si auto certificazione consegnando una webapp dannosa all'utente, rigiocando richieste o violando il segreto dell'HMAC.