Prevenire la reinvio e la replica dell'attacco utilizzando il client nonce nell'API REST

Question

Prevenire la reinvio e la replica dell'attacco utilizzando il client nonce nell'API REST

#1 da (5 voti)
#2 da (-1 voti)

5

Ho un backend API REST che ha HTTPS (e HTTP bloccato) e utilizzo JWT come meccanismo di autenticazione. Il lato client è l'app iOS / Android. Voglio aggiungere un livello di protezione sull'API critica utilizzando il client nonce per impedire (principalmente) la reinvio (chiamata inavvertitamente due volte la stessa API a causa di una rete / interfaccia utente errata) e (forse) un attacco di riproduzione. I dettagli attuali stanno seguendo.

(Tutte le chiamate REST sono comunque HTTPS)

effettua una chiamata API utilizzando nome utente e password per scambiare un JWT dal lato server
utilizza il JWT ottenuto (intestazione HTTP) e effettua una chiamata API di sottosequenza al server
server di backend controlla il JWT ed esegue la richiesta

Il problema attuale è chiunque possa intercettare il pacchetto HTTP in grado di riprodurre la chiamata API. Inoltre, in caso di rete non valida, il cliente può premere due volte il pulsante Invia / conferma e inviare nuovamente la richiesta.

Quello che propongo è il seguente:

effettua una chiamata API utilizzando nome utente e password per scambiare un JWT dal lato server
utilizza il JWT ottenuto + un nonce generato dal client e effettua una chiamata API di sottosequenza al server di back-end.
server di back-end controlla prima il JWT e poi il nonce. Supponiamo di avere un negozio k-v con TTL come Redis.
Se il blocco esiste in Redis, rifiutiamo la richiesta. In caso contrario, accettiamo la richiesta e impostiamo la notifica in Redis con un TTL predefinito (ad esempio 1 ora?) In modo che una riproduzione venga rifiutata.

Devo ammettere che ho pochissime conoscenze sulla sicurezza. Voglio sapere se questa proposta è legittima? O mi manca qualcosa di importante? Se la mia idea è ok, qual è il miglior algoritmo per generare il nonce? Il lato server deve in qualche modo "decodificare" il nonce per vedere se si adatta al protocollo prima di confrontarlo con Redis?

api rest nonce

posta mingchuno 03.08.2016 - 05:02

fonte

2 risposte

-1

(Tutte le chiamate REST sono comunque HTTPS)

Allora sei già protetto dagli attacchi di replay.

risposta data 27.02.2017 - 09:43

fonte

Leggi altre domande sui tag api rest nonce

Snort regole per rilevare le sessioni Meterpreter È sicuro archiviare le password nella memoria propria dell'app Android / iOS?

score 5 · Accepted Answer

Un nonce sul lato client presenta tre difficoltà:

come fa il cliente a sapere quando generare un nuovo nonce? (Quali azioni costituiscono una nuova richiesta tale che dovrebbe essere generata una nuova nonce?)
come fa il server a sapere cos'è un nonce valido? Un blob di 4 gb ipotetico fornito da un aggressore può essere un nonce?
come fa il server a sapere quanti punti si devono conservare e per quanto tempo?

Un nonce fornito dal server offre due vantaggi:

meno per il client da fare
il server sa cosa aspettarsi dopo

Il server non deve tenere un record di tutti i nonces, solo quello corrente, e può essere cancellato quando arriva la prima richiesta valida con esso. Un nuovo nonce può essere inviato con la risposta.

Questo modello applica un modello di interazione con una richiesta in volo. Se ci fosse il desiderio di più richieste simultanee, il server può produrre un blocco di nonce, ma la sfida è che il cliente ha bisogno di un modello per differenziare tra richieste univoche, assicurandosi che ogni azione dell'utente non porti a tirare fuori un nuovo nonce da la piscina locale. Questa difficoltà dovrebbe suggerire di strutturare l'app in modo tale che solo una richiesta non richiesta sia in volo alla volta.