Come posso prevenire gli attacchi di replay?

Question

Questo è correlato a un'altra domanda che ho posto.In sintesi, ho un caso speciale di un URL in cui, quando viene pubblicato un modulo, non posso fare affidamento sui cookie per l'autenticazione o per mantenere la sessione dell'utente, ma in qualche modo ho bisogno di sapere chi sono e ho bisogno per sapere che hanno effettuato l'accesso!

Penso di aver trovato una soluzione al mio problema, ma necessita di essere approfondita.Ecco cosa sto pensando.Creo un campo modulo nascosto chiamato "nome utente" e inserisco al suo interno il nome utente dell'utente, crittografato.Quindi, quando il modulo viene pubblicato, anche se non ricevo alcun cookie dal browser, so che hanno effettuato l'accesso perché posso decrittografare il campo del modulo nascosto e ottenere il nome utente.

Il principale difetto di sicurezza che vedo sono gli attacchi di riproduzione.Come posso impedire a qualcuno di entrare in possesso di quella stringa crittografata e di eseguire il POST come utente?So che posso usare SSL per rendere più difficile il furto di quella stringa e forse posso ruotare la chiave di crittografia regolarmente per limitare il tempo di validità della stringa, ma mi piacerebbe davvero trovare un metodo a prova di proiettile soluzione.Qualcuno ha qualche idea?ASP.Net ViewState impedisce la riproduzione?Se sì, come lo fanno?

Modificare:Spero in una soluzione che non richieda nulla archiviato in un database.Lo stato dell'applicazione andrebbe bene, tranne per il fatto che non sopravviverà a un riavvio di IIS o non funzionerà affatto in uno scenario web farm o garden.Per ora accetto la risposta di Chris, perché non sono convinto che sia possibile proteggerlo senza un database.Ma se qualcuno mi dà una risposta che non coinvolge il database, lo accetto!

Answer 1

Se inserisci un timestamp insieme al nome utente e alla password, puoi chiudere la finestra per gli attacchi di riproduzione entro un paio di secondi.Non so se questo soddisfa le tue esigenze, ma è almeno una soluzione parziale.

Answer 2

Se davvero non vuoi memorizzare alcuno stato, penso che la cosa migliore che puoi fare sia limitare gli attacchi di replay utilizzando timestamp e un tempo di scadenza breve.Ad esempio, il server invia:

{Ts, U, HMAC({Ts, U}, Ks)}

Dove Ts è il timestamp, U è il nome utente e Ks è la chiave segreta del server.L'utente lo rimanda al server e il server lo convalida ricalcolando l'HMAC sui valori forniti.Se è valido, sai quando è stato emesso e puoi scegliere di ignorarlo se è più vecchio, ad esempio, di 5 minuti.

Una buona risorsa per questo tipo di sviluppo è Le cose da fare e da non fare durante l'autenticazione del client sul Web

Answer 3

Ci sono molte buone risposte qui e metterle tutte insieme è dove alla fine si trova la risposta:

1. La crittografia a blocchi esegue la crittografia (con AES-256+) e l'hash (con SHA-2+) di tutte le informazioni relative allo stato/nonce inviate a un client.Altrimenti gli hacker si limitano a manipolare i dati, visualizzarli per apprendere i modelli e aggirare tutto il resto.Ricordare ...basta una sola finestra aperta.

2. Genera un nonce casuale e univoco una tantum per richiesta che viene rispedito con la richiesta POST.Questo fa due cose:Garantisce che la risposta POST sia accompagnata da QUELLA richiesta.Consente inoltre di tenere traccia dell'utilizzo una tantum di un determinato set di coppie get/POST (impedendo la riproduzione).

3. Utilizzare i timestamp per rendere gestibile il pool nonce.Memorizza il timestamp in un cookie crittografato come indicato al punto 1 sopra.Eliminare eventuali richieste più vecchie del tempo massimo di risposta o della sessione per l'applicazione (ad esempio, un'ora).

4. Memorizzare un'impronta digitale "ragionevolmente unica" della macchina che effettua la richiesta con i dati di marca temporale crittografati.Ciò impedirà un altro trucco in cui l'aggressore ruba i cookie del client per eseguire il dirottamento della sessione.Ciò garantirà che la richiesta ritorni non solo una volta ma dalla macchina (o abbastanza vicina da rendere praticamente impossibile per l'aggressore la copia) a cui è stato inviato il modulo.

Esistono applicazioni basate su filtri di sicurezza ASPNET e Java/J2EE che eseguono tutto quanto sopra senza codifica.Gestire il pool nonce per sistemi di grandi dimensioni (come una società di compravendita di azioni, una banca o un sito sicuro ad alto volume) non è un'impresa banale se le prestazioni sono fondamentali.Consiglierei di guardare questi prodotti invece di provare a programmarli per ciascuna applicazione web.

Answer 4

Potresti utilizzare una sorta di stringa di sfida casuale utilizzata insieme al nome utente per creare l'hash.Se memorizzi la stringa di sfida sul server in un database puoi assicurarti che venga utilizzata solo una volta e solo per un particolare utente.

Answer 5

In una delle mie app per fermare gli attacchi di "replay" ho inserito le informazioni IP nel mio oggetto di sessione.Ogni volta che accedo all'oggetto sessione nel codice, mi assicuro di passare Request.UserHostAddress con esso e poi lo confronto per assicurarmi che gli IP corrispondano.In caso contrario, ovviamente qualcuno diverso dalla persona ha fatto questa richiesta, quindi restituisco null.Non è la soluzione migliore ma rappresenta almeno un'ulteriore barriera per fermare gli attacchi di replay.

Answer 6

È possibile utilizzare la memoria o un database per la manutenzione Qualunque informazioni sull'utente o richiedere del tutto?

Se è così, su richiesta del modulo, includerei un campo modulo nascosto il cui contenuto è un numero generato casualmente.Salvare questo token nel contesto dell'applicazione o in una sorta di archivio (un database, un file flat e così via) quando viene eseguito il rendering della richiesta.Quando il modulo viene inviato, controlla il contesto dell'applicazione o il database per vedere se il numero generato casualmente è ancora valido (comunque lo definisci valido, forse può scadere dopo X minuti).In tal caso, rimuovi questo token dall'elenco dei "token consentiti".

Pertanto qualsiasi richiesta riprodotta includerebbe lo stesso token che non è più considerato valido sul server.

Answer 7

Sono nuovo in alcuni aspetti della programmazione web, ma ne stavo leggendo l'altro giorno.Credo che tu debba usare a Nonce.

Answer 8

(Gli attacchi di riproduzione possono facilmente riguardare uno spoofing IP/MAC, inoltre sei sfidato su IP dinamici)

Non è solo la riproduzione che stai cercando qui, da sola non ha senso.Usa semplicemente SSL ed evita di creare qualsiasi cosa manualmente.

ASP.Net ViewState è un disastro, evitalo.Sebbene la PKI sia pesante e gonfia, almeno funziona senza inventare i propri "schemi" di sicurezza.Quindi, se potessi, lo userei e opterei sempre per l'autenticazione reciproca.L'autenticazione solo del server è abbastanza inutile.

Answer 9

ViewState include funzionalità di sicurezza.Vedere Questo articolo su alcune delle funzionalità di sicurezza integrate in ASP.NET .Esegue la convalida rispetto al server machineKey nel file machine.config sul server, garantendo che ogni postback sia valido.

Più in basso nell'articolo, vedi anche che se desideri memorizzare valori nei tuoi campi nascosti, puoi utilizzare il file LosFormatter classe per codificare il valore nello stesso modo utilizzato da ViewState per la crittografia.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Answer 10

Se accetti ogni chiave solo una volta (ad esempio, rendi la chiave un GUID e poi controlla quando ritorna), ciò impedirebbe le riproduzioni.Naturalmente, se l'aggressore risponde Primo, allora hai un nuovo problema...

Answer 11

Si tratta di WebForms o MVC?Se è MVC potresti utilizzare il token AntiForgery.Sembra che sia simile all'approccio che menzioni, tranne che utilizza fondamentalmente un GUID e imposta un cookie con il valore guid per quel post.Per ulteriori informazioni consultare il blog di Steve Sanderson: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Un'altra cosa, hai considerato di controllare il referrer sul postback?Questo non è a prova di proiettile ma può aiutare.

Answer 12

Usa https...ha la protezione dalla riproduzione integrata.